10.02.2020

Jeżeli jeszcze nie masz testów zaimplementowanych w swoim procesie zacznij od MVP, szkieletu od którego rozpoczniesz budowę. Dla przykładu możesz utworzyć pojedynczy test jednostkowy, test akceptacyjny i zautomatyzowany skrypt, który spowoduje utworzenie gotowego środowiska dla testów eksploracyjnych. Następnie przyrostowo zwiększaj poziom pokrycia testami i rozwijaj proces CD.

Jako zespół musicie podążać podejściem TDD lub chociaż mieć pewność, że testy jednostkowe są pisane. Zapewnia to wysoką jakość kodu oraz ułatwia automatyzację na wyższych poziomach, np. pozwala zaślepiać komunikację z zewnętrznymi niezależnymi od nas serwisami na potrzeby przeprowadzenia kontroli jakości w środowisku, które zapewni powtarzalność wyników.

W przypadku kiedy zarządzasz zestawem testów, który jest ciężki do utrzymania i nie możesz ufać jego wynikom, nie bój się usuwać z niego przypadków testowych. Zestaw 10 świetnej jakości testów, na który wszyscy mogą liczyć, jest o wiele lepszy niż zestaw 200 czy 300 testów, którym rezultatom nikt nie ufa, a Ty musisz walczyć o niego z programistami.

W każdym z tych wypadków zapewnij wspólną pracę programistów i testerów od jak najwcześniejszego momentu w procesie wytwarzania oprogramowania jako część jednego całego zespołu deweloperskiego, zamiast zaczynać testowanie, dopiero kiedy praca programistów wygląda na wykonaną. Tyczy się to również zwinnych zespołów, gdzie kolumna Ready for QA na scrum boardzie jest doskonałą wymówką na odwlekanie testowania aż zadanie pojawi się właśnie w tym miejscu. Programiści i testerzy powinni również wspólnie rozbudowywać zestaw testów akceptacyjnych, nie zostawiaj tej pracy jednie dla testerów automatyzujących. Z drugiej zaś strony, kiedy test akceptacyjny z jakiegoś powodu nie zostanie, poprawnie, zaliczony, dopisz test jednostkowy, który pozwoli szybciej wykryć ten sam defekt w przyszłości.

Podsumowanie