Redakcja
Podkreślam, że pisząc „automatyzacja” mam na myśli pisanie skryptów automatyzujących wykonywanie operacji na interfejsie graficznym aplikacji.
Aktualnie rozmowy o automatyzacji często przypominają słynny dialog z „Misia”.
To jest „automatyzacja na skalę naszych możliwości”, „my tą automatyzacją otwieramy oczy niedowiarkom”, „dostajemy za tę automatyzację jako konsultanci 20% ogólnej sumy kosztów…”.
O czym warto pamiętać zanim zdecydujemy się na automatyzację?
1. Automatyzacja musi mieć cel. Mało która organizacja wie dlaczego automatyzuje, a jeśli potrafi to wyartykułować, to tak zdefiniowanego celu nie da się osiągnąć. Do najpopularniejszych należą:
- zwolnić testerów manualnych (patrz punkt 2)
- znaleźć więcej awarii (patrz punkt 3)
- osiągnąć wyższą jakość (patrz punt 3).
2. Napisanie skryptów automatycznych zajmuje od 10 do 50 razy więcej czasu niż napisanie testów manualnych. Uruchomienie testów manualnych często może zajmować tyle samo czasu co uruchomienie testów automatycznych + analiza logów z uruchomienia + określenie, dlaczego test "nie przeszedł" + potwierdzenie, czy pojawił się defekt czy też nie. Utrzymanie skryptów automatycznych jest o około 20 razy droższe od utrzymania testów manualnych. Organizacje, które decydują się na automatyzację często zatrudniają dodatkowych testerów „automatycznych”, którzy będą przez kilka lat pracować równolegle do testerów manualnych. Najogólniej mówiąc automatyzacja, przynajmniej w pierwszym okresie wdrożenia, generuje więcej kosztów niż zysków.
3. Testowanie automatyczne nie jest nastawione na znajdowanie awarii. Podczas pisania skryptów do testów automatycznych przeklikaliście już całe oprogramowanie i najważniejsze problemy zostały znalezione. Teraz nasze automaty służą tylko temu, by potwierdzić, że nie nastąpił regres jakości.
4. Nie da się automatyzować bez kodowania. Narzędzia nagrywająco-odtwarzające nie działają. Szczególnie jeśli nie dają one możliwości modyfikowania i parametryzowania kodu. Ciągle jednak budowanie swojej automatyzacji w oparciu o kod wygenerowany z narzędzia jest jak używanie narzędzi WYSIWIG do budowania stron WWW.
5. Dobre narzędzie to połowa sukcesu. Organizacje, zamiast wdrażać rozwiązania adekwatne do potrzeb, starają się używać rozwiązań „modnych”, czyli popularnych; (teoretycznie) „łatwych”, czyli z drogim wsparciem komercyjnym; czy „dobrze reklamowanych”, czyli nie do końca spełniających ich faktyczne wymagania. W rzeczywistości zrozumienie własnych potrzeb jest pierwszym i najważniejszym elementem strategii wdrożenia automatyzacji. Wiedząc co chcemy osiągnąć możemy poszukać narzędzia, które nasze cele pomoże zrealizować.
6. Piramida testów wskazuje, na co warto zwrócić uwagę.
Pisz dużo testów jednostkowych, napisz średnią ilość testów integracji, ale mało testów na interfejsie. Zadbaj o jakość swojego oprogramowania od podstaw. Na początku niech będzie to stabilny i wysokiej jakości kod źródłowy aplikacji. Potem upewnij się, że zautomatyzowałeś testy integracji komponentów. Działa? Jeśli TAK, to teraz możesz przetestować resztę na interfejsie.
7. Nie da się zautomatyzować 100% testów interfejsu. A właściwie to można, ale jest to nieopłacalne. Dlaczego wszyscy akceptują, że nie da się w skończonym czasie przetestować wszystkich danych, konfiguracji i zdarzeń w aplikacji, ale jakimś cudem dążą do uzyskania 100% pokrycia testami automatycznymi aplikacji na interfejsie?
8. Nie można automatyzować wcześnie. Testy oprogramowania mają największą wartość oraz wykrywają defekty najtaniej jeśli wykonywane są wcześnie w procesie wytwarzania oprogramowania. Automatyzacji weryfikacji interfejsów nie możemy wykonać wcześnie, ponieważ z zasady powinniśmy tworzyć skrypty tylko do obszarów ustabilizowanych i nie podlegających dużym zmianom. Próba takiej automatyzacji sprowadza do zera kluczową metrykę durability testu, czyli liczbę jego uruchomień (na różnych wersjach oprogramowania) bez konieczności wprowadzania do niego zmian.
9. Budowanie automatyzacji jest projektem informatycznym. Nie uda się zbudować dobrego produktu informatycznego, w tym automatyzacji, bez:
- podejścia projektowego i zarządzania zakresem, czasem oraz budżetem,
- wsparcia ekspertów oraz pomocy junior programistów ds. automatyzacji,
- definiowania dobrej specyfikacji albo przynajmniej komentarzy w kodzie i instrukcji posługiwania się frameworkiem,
- przestrzegania dobrych praktyk kodowania i zalecanych wzorców projektowych,
- itd.
10. Automatyzujemy, bo nie radzimy sobie z testowaniem manualnym. Studentów sztuki zmusza się do malowania na początek realistycznych obrazów, a kiedy osiągną w tym perfekcję, pozwala im się na abstrakcję. Nie można być dobrym automatykiem bez dobrego zrozumienia podstaw testowania i zapewnienia jakości oprogramowania.
Automatyzacja to modne teraz słowo, a jej negowanie jest niemile widziane. Będąc automatykiem można sporo zarobić, ale niestety często odbywa się to kosztem nieświadomej organizacji i/lub też odbija się na jakości testowanego produktu. Jeśli ten artykuł odrobinę Was poruszył, to w następnym opiszę co jest tańsze i skuteczniejsze od testów automatycznych na interfejsie.
Autor: Radek Smilgin
Wybrane źródła
- http://searchsoftwarequality.techtarget.com/opinion/Automated-testing-tools-Four-reasons-why-projects-fail
- https://www.testing-whiz.com/blog/why-test-automation-fails-common-myths-busted-with-10-scenarios-for-success
- https://www.slideshare.net/Ranorex/why-test-automation-fails-in-theory-and-in-practice
