Niezwykle dynamiczny rozwój branży IT spowodował rewolucję na rynku pracy. Pewne zawody odeszły do historii, a na ich miejsce pojawiły się zupełnie nowe, o zaskakujących i zazwyczaj obco brzmiących nazwach: DevOps Engineer, Database Administrator, SAP Cloud Product Owner, Scrum Master i wiele innych. A wśród nich tester oprogramowania.
Nazwa “tester oprogramowania”, w odróżnieniu od wymienionych wcześniej, nie brzmi obco. Wydaje się zrozumiała i kojarzy się oczywiście z testowaniem, czyli sprawdzaniem, próbowaniem – słyszymy o testerach wina, whisky czy nawet … chipsów. Gdy jednak przyjrzeć się zadaniom, jakie w kontekście IT wykonuje tester oraz samemu procesowi testowania, okaże się, że termin ten obejmuje zaledwie część obszarów, za które odpowiadają testerzy i że wcale nie tak łatwo wyjaśnić pokrótce, czym się oni zajmują.
Największy problem tkwi w terminologii. Dosłowne przekładanie z języka angielskiego na polski utrudnia precyzyjny opis zadań związanych z testowaniem, zwłaszcza że te same pojęcia używane są, nawet przez testerów, w różnych znaczeniach.
Spróbujmy więc uporządkować nieco nazewnictwo i, odwołując się do porównań z życia codziennego, wyjaśnić bliżej, na czym polega praca testera.
Zacznijmy od nazwy zawodu – określenie “tester oprogramowania” stosowane jest w Polsce wymiennie z “software tester”. Gdy jednak wpiszemy ten termin w internetową wyszukiwarkę Encyklopedii Britannica lub Collins Dictionary, spotka nas rozczarowanie: wynikiem jest … brak wyników. “Sorry, no results for “software tester” in the English Dictionary.”
Czy to oznacza, że w anglojęzycznym Internecie takie określenie zawodu testera oprogramowania nie funkcjonuje? A przecież wpisując to samo hasło w YouTube otrzymamy niezliczoną ilość filmów powiązanych z tematem testowania oprogramowania (software testing).
Spróbujmy zatem przyjrzeć się innym nazwom występującym w kontekście testowania oprogramowania, jak choćby Quality Assurance Tester, Quality Assurance Engineer, Software Quality Assurance Tester.
Gdy do wspomnianych słowników wpiszemy hasło “quality assurance”, otrzymamy kilka definicji. Jedna z nich brzmi następująco:
“Zapewnienie jakości polega na upewnieniu się, że podczas procesu produkcyjnego nie powstają wadliwe produkty.” – „Quality assurance involves making sure that no defective products are made during the manufacturing process.” (Collins)
Jest to oczywiście bardzo ogólna definicja, ale dobrze oddaje samą istotę i cel działań testera – upewnianie się, że podczas procesu tworzenia/produkcji oprogramowania nie powstaje wadliwy produkt.
W związku z powyższym wydaje się, że opisując ten zawód lepiej stosować nazwy zawierające wyrażanie „zapewnianie jakości”, takie jak QA engineer, czy jego polski odpowiednik – inżynier zapewniania jakości.
Wiemy już zatem, że zadaniem testera jest dopilnowanie, by nie powstał wadliwy produkt, a więc zapewnianie odpowiedniej jakości. Pytanie brzmi: jak się to robi? W jaki sposób można upewnić się, że produkt nie jest wadliwy?
Przede wszystkim należy sprawdzić, czy oprogramowanie spełnia przyjęte kryteria. Nic prostszego – mogłoby się wydawać. Bierzemy listę wymagań i testujemy pod tym kątem nasz produkt. W rzeczywistości nie jest to jednak takie proste – wymagania nie są zazwyczaj sformułowanie w sposób jednoznaczny i ścisły. Poza tym “sprawdzić”, “przetestować” – co to właściwie znaczy?
Niekiedy używa się tych słów wymiennie – np. “sprawdzić wytrzymałość” i “przetestować wytrzymałość”. “Sprawdzanie” nie ma jednak w sobie komponentu “dociskania kogoś lub czegoś do granic wytrzymałości”, “testowanie” ma natomiast taki wydźwięk. Dlatego słowo to pasuje w miarę dobrze do opisu testów wydajnościowych, które polegają między innymi na ustalaniu granicznych wartości dla prawidłowego działania aplikacji, a czasem wręcz na próbie przekroczenia tych granic – trzeba je niekiedy “złamać”, to znaczy przetestować pod kątem nietypowego obciążenia i sprawdzić, przy jakiej ilości zapytań do serwera program przestanie działać prawidłowo.
Pomijając testy wydajnościowe, większa część czynności testera nie polega jednak na samym testowaniu oprogramowania, lecz na analizie, wypracowywaniu jasnych kryteriów oceny, planowaniu, sprawdzaniu działania i opisywaniu wyników, czyli raportowaniu.
Do czego można by to porównać?
Wyobraźmy sobie laboratorium analityczne, w którym badane są próbki krwi. Pracownicy laboratorium sprawdzają, czy odpowiednie składniki pobranego materiału odpowiadają przyjętym wartościom referencyjnym. Podobnie tester oprogramowania bada, czy dane komponenty oprogramowania odpowiadają przyjętym kryteriom. Kluczowe jest tu słowo „badanie”. Nie występuje ono w materiałach opisujących obowiązki testera, tymczasem całkiem dobrze oddaje istotę tego zawodu. Tester bada oprogramowanie, bierze pod lupę różne jego aspekty i sprawdza, jak funkcjonuje w różnych warunkach.
Inną ciekawą analogią jest okresowe badanie techniczne pojazdów, znane każdemu kierowcy. Stacja kontroli pojazdów ma ściśle określone kryteria oceny. Pracownik stacji wie, co ma sprawdzać i w jakiej kolejności, a także jakie wymagania muszą być spełnione, by dopuścić samochód do ruchu. Dzięki ściśle opisanej procedurze prawodawca ma nadzieję (bo pewności nigdy mieć nie może), że każdy pojazd na drodze spełnia te same kryteria bezpieczeństwa.
Idąc dalej tym tropem zobaczymy jednak, że w przypadku oceny jakości oprogramowania sytuacja jest znacznie bardziej skomplikowana. Po pierwsze, oprogramowanie podlega ciągłym modyfikacjom – trochę tak, jakby nasz samochód był nieustannie zmieniany, ulepszany, rozbudowywany. Po drugie, choć niektóre procesy, czy produkty branży IT z czasem się ustandaryzowały – na przykład generalny układ dla przeglądarek, albo menu po lewej stronie ekranu – to wciąż na wielu innych obszarach daleko jeszcze do wypracowania jednolitych rozwiązań. Do każdego programu, systemu, a czasem nawet do nowszej wersji tej samej aplikacji, trzeba na nowo wypracowywać kryteria oceny – naszą check-listę kontroli jakości. To tak, jakby dla każdego modelu samochodu istniała inna, i to wciąż zmieniająca się procedura. Po trzecie, wyobraźmy sobie samochód, który jest poddawany badaniu technicznemu po każdej … wymianie żarówki, modyfikacji reflektora, zmianie fotela czy mechanizmu otwierającego okno… I to kilka razy dziennie… A tak się przecież dzieje w przypadku zwinnych metod wytwarzania oprogramowania, praktyki constant integration – constant deployment (CI/CD), gdzie każdemu „mergowi” do mastera towarzyszy automatyczne wykonywanie się wielu testów regresji.
Biorąc pod uwagę cały kontekst i wszystkie uwarunkowania, w jakich powstaje software można dostrzec, że praca testera wymaga szerokiego spektrum umiejętności. Tester powinien być w jakiejś mierze prawodawcą i zarazem negocjatorem – wypracować z klientem jednoznaczne kryteria oceny. Powinien być po części analitykiem – umieć przeanalizować przedmiot testów – oraz project managerem – zaplanować zestawy testów i przypadki testowe, a także harmonogram działań dla siebie bądź dla zespołu testerów. Bardzo ważne jest, by posiadał pewne umiejętności programisty, takie jak pisanie kodu testów automatycznych, jak również wiedzę architekta, aby zrozumieć działanie aplikacji w szerszym kontekście i wewnętrzne zależności, a także biznes analityka, by określać priorytety biznesowe dla poszczególnych typów i poziomów testów. A wreszcie potrzebne mu są także kompetencje komunikacyjne, by umieć sprawnie i skutecznie porozumieć się zarówno z klientem, jak i z zespołem developerów i testerów.
To właśnie ta różnorodność pól i obszarów sprawia, że bardzo trudno w prosty i szybki sposób odpowiedzieć na pytanie, czym zajmuje się tester oprogramowania.
Na koniec warto wspomnieć o jeszcze jednym aspekcie zapewniania jakości, który często umyka uwadze zarówno deweloperów, jak i klientów, a który w naturalny sposób staje się domeną działania inżynierów QA. Chodzi o jakość przebiegu samego procesu wytwarzania oprogramowania. Powstaje pytanie – czy chaotyczny, zmienny i nieefektywny proces wytwórczy może doprowadzić do powstania produktu o wysokiej jakości? Rozważanie tego zagadnienia to już jednak materiał na zupełnie inny artykuł.
Wojciech Sławiński
Tester Oprogramowania
Wcześniej zawodowy muzyk, aranżer, założyciel i manager zespołu i studia Synaxis. Obecnie certyfikowany tester oprogramowania. Entuzjasta Lean Management. W Soflab od stycznia 2022 roku.
