Na początek wyobraź sobie, że jesteś programistą. Prosta sprawa, wystarczy pić dużo kawy i ustawić jakąś tapetę w stylu Matrixa.

Teraz jesteś proszony o ciągłe upewnianie się, że każda funkcjonalność przez ciebie opracowana działa zgodnie z planem (Quality Assurance). Załóżmy, że jest to jedna z podstawowych funkcji twojej platformy. A bez tego na pewno biznes na pewno będzie próbował cię zamordować.
1

Uprośćmy to trochę, aby była to funkcja logowania (w bardziej skomplikowanych przypadkach może to być happy path, wprowadzanie danych itp.). Może to być środowisko zamknięte, sieć wewnętrzna. Bułka z masłem, co nie?

2

Co więc robisz?

W większości przypadków stworzyłbyś oddzielne narzędzie, zakodował je, skompilował, może skorzystał z jakiejś zewnętrznej biblioteki, przygotował dokumentację, przekazał do wsparcia i modliłbyś się, aby IT o tym nie zapomniało.. bo co jeśli narzędzie do sprawdzania narzędzia się zepsuje? Czy powinieneś wtedy zaprojektować narzędzie do sprawdzania narzędzia sprawdzającego? A zwykle to musi być narzędzie, ponieważ aplikacje do monitorowania IT sprawdzają tylko procesor i pamięć RAM. Tutaj masz do czynienia z wieloma przeglądarkami i symulacją rzeczywistego użytkownika.

3

Zwykle zdarza się tak, że funkcjonalność prędzej czy później się psuje i nikt tego nie zauważa, ponieważ serwer z narzędziem jest wyłączony, wsparcie jest spóźnione, a ty najprawdopodobniej skończysz ścigany o 3 nad ranem i pytany, dlaczego od tygodnia nie działa.

A teraz wyobraź sobie, że masz magiczne narzędzie. Lub inaczej, FRENDS. Następnie po prostu rysujesz coś takiego.

FRENDS

W rezultacie zaprojektowałeś coś co jest zrozumiałe zarówno dla biznesu jak i dla wsparcia. I zrobiłeś to w 5 minut (właściwie to ja zrobiłem, i było to dosłownie 5 minut). Jest to wyposażone też w dodatkowe funkcje ułatwiające pracę:

  • Jeżeli coś się nie uda lub zepsuje, możesz powiadomić o tym zespół wykorzystując SMS, pocztę elektroniczną lub innej formy kontaktu z której korzystasz. Dzięki temu dział wsparcia będzie świadomy problemu i jest w stanie zareagować w odpowiednim czasie;
  • Następnie możesz połączyć go z Jenkinsem lub innymi automatycznymi narzędziami do produkcji aby były uruchamiane za każdym razem kiedy wdrażasz proces. Nigdy więcej niespodzianek.
  • Chcesz zaktualizować zadania testowe JIRA? Nic prostszego! Użyj JIRA API.
  • Możesz użyć kodu niskiego poziomu w zadaniu. Nie ma nic specyficznego wyłącznie dla FRENDS więc jeśli znasz .NET, znasz FRIENDS;
  • Masz już pakiet testów? Zintegruj je tutaj lub dodaj nowe. Możesz uruchomić wiersz poleceń, a to oznacza że możesz nawet użyć JAVA, nodeJS, C++, Selenium 😉 Cokolwiek ci się wymarzy;
  • Potem możesz uruchomić go w środowisku testowym w kilka sekund, z różnymi zmiennymi środowiskowymi.
  • A jeśli chcesz uruchomić go ręcznie, po prostu kliknij to:

manual

  • Będziesz mógł również zobaczyć pełną historię procesów.

processes

A co z dokumentacją? Nie martw się, zostało to już zrobione automatycznie w fazie projektowania.

I tutaj nasuwa się pytanie: dlaczego ludzie nie robią tego w ten sposób?

Przedstawiony przeze mnie sposób jest bardziej jednoznaczny, oszczędza dużo czasu i dokumentacja odbywa się automatycznie. O wiele lepsza obsługa klienta.

Mówiąc za siebie:

Kiedyś też budowałem procesy tak jak w pierwszym przykładzie. Wierz mi lub nie, nie chcesz iść tą ścieżką w dzisiejszym nowoczesnym świecie :).

Możesz się zastanawiać dlaczego sposób z pierwszego przykładu nadal dominuje. Cóż, myślę, że to wcale nie jest tak, że programiści nie chcieliby tego robić mądrzejszym, drugim sposobem. Z tego co zaobserwowałem, zazwyczaj to wina biznesu, który nie dostarcza odpowiedniego zestawu narzędzi. Może jest to spowodowane brakiem świadomości lub krzywej uczenia (która prawie nie istnieje)?

Zauważ, że ten przykład był tylko scenariuszem testowym. Wyobraź tylko sobie ile jeszcze procesów związanych z twoją firmą możesz zrobić w ten sposób! Na przykład synchronizacja aplikacji biznesowych. Możliwości są nieograniczone.

Podsumowując:

Opcja (1) angażowała osoby z działu wsparcia obserwujące twoje narzędzie do monitorowania. Nie znają oni ani kodu ani procesu, musisz kupić dodatkową maszynę do monitorowania stanu aplikacji, osobno napisać dokumentację. I nadal może się to zepsuć.

Opcja (2) obejmuje narzędzia programistyczne, w ramach których zlecasz na zewnątrz część obowiązków związanych z monitorowaniem. Jest płatna na bieżąco lub oparta na licencji, i zawsze działa: Jedno miejsce. Wiele środowisk. Testy akceptacyjne (UAT). Nieograniczona ilość procesów. Wiele aplikacji. Prawie natychmiastowa umowa o gwarantowanym poziomie świadczenia usług (SLA). Świetne wsparcie. Duża społeczność. Zgodny ze środowiskami wewnętrznymi (zamknięte/hostowane samodzielnie).

I pamiętaj, że tego typu narzędzia w rzeczywistości nie odbierają wcale pracy twoim programistą. Zamiast tego pomagają im odnieść sukces. Ale jeśli naprawdę nie masz czasu, mamy zespół, który pomoże zaprojektować i wdrożyć procesy za ciebie ;).

Chcesz dowiedzieć się więcej? Napisz do nas.

Categories: Ale że IT?