Redakcja
Na froncie walki o jakość walczą dwie grupy:
- manualni ułani, którzy szturmują niezliczoną rzeszę defektów oprogramowania,
- automatyczne czołgi, które rozjeżdżają trupy defektów upewniając się, że na pewno nie powstaną.
Są i tacy, którzy bez problemu przełączają się między tymi zadaniami.
Niestety zbyt często pojawiają się "testerzy tylko z nazwy", którzy z testowaniem nie mają i nie chcą mieć za dużo wspólnego.
1. Nie testuje manualnie, bo to poniżej jej/jego kompetencji.
Manualne uruchomienie testów to przecież klikanina i szkoda na nią czasu. Co z tego, że to właśnie ta czynność pozwala znaleźć najwięcej defektów.
2. Nie przygotowuje scenariuszy testowych. Ktoś to ma zrobić za niego.
Projektowanie testów jest proste. Czytasz specyfikację i przepisujesz kroki do wykonania. To mogą robić manuale.
3. Automaty nie muszą przygotowywać i czyścić środowiska.
Warunek początkowy i końcowy jest domeną przypadku testowego, a nie skryptu testowego. Dodawanie tej samej procedury jest bezużyteczne i nudne.
4. Nie musi znać dziedziny aplikacji.
Nie musi wiedzieć jak działa aplikacja, znać użytkowników i rozumieć jaki jest jej cel biznesowy. Programista musi znać kod, a nie co myśli użytkownik.
5. Czas wykonania skryptu nie ma dla niego znaczenia.
Optymalizacją kodu zajmie się na końcu. W trakcie projektu jest czas na uzyskanie maksymalnego pokrycia.
6. Cały kod testów w jednym pliku. Wraz z danymi testowymi.
Robienie dodatkowych plików pogarsza czytelność projektu. Przynajmniej wiadomo, gdzie jest wszystko.
7. Tworzy kod bez komentarzy, a projekty bez dokumentacji.
Przecież ten kod jest taki prosty, że aż zrozumiały sam przez się. Dokumentacja? W świecie Agile? Po co?
8. 100% pokrycia jako minimum.
Trzeba uzyskać pełne pokrycie dla całego interfejsu. Bez względu na koszty.
9. Piramidę testów należy odwrócić.
Im więcej skrytpów na GUI, tym lepiej dla całego projektu.
10. Jest programistą.
Ctrl+C i ctrl+V jest programowaniem.
Wskaż element, wykonaj na nim operację,... zrób weryfikator - to programowanie. Używanie Page Object Pattern jest zaawansowanym programowaniem obiektowym.
11. noMaintenance
Skrypty są tak dobre, że nie trzeba ich utrzymywać. Nie ma czasu poprawiać bez względu na to, czy są fałszywie pozytywne czy fałszywie negatywne.
12. Redukuje koszty projektu przez automaty.
Uważa, że więcej automatyzacji to niższe koszty testowania.
I takie podejście do życia byłoby naszym największy problem, gdyby nie to, że zbyt wielu decyzyjnych managerów ma bardzo podobne poglądy...
