Redakcja
Testowanie, jako część inżynierii oprogramowania, cierpi na tę samą przypadłość co cała branża IT - tak zwane mody. Scrum, automatyzacja, zwinne testowanie, ATDD, BDD, TDD - wszyscy to znają, wszyscy o tym mówią i wszyscy to stosują (lub wydaje im się, że to robią). Często jednak wpadamy w pułapkę ślepego podążania za daną "nowinką", czy będzie to model procesu testowego, czy technika testowania, czy specyficzne zadanie z obszaru QA. W rezultacie umyka nam prawdziwa istota modelu, techniki czy zadania. Na podstawie obserwacji z praktyki, a także różnych prezentacji, jakich miałem okazję wysłuchać na różnych konferencjach testerskich, poruszam w swojej prezentacji kilka zagadnień z tym związanych. Po pierwsze, pokazuje przykłady tego, jak nieumiejętne stosowanie idei nowych, ale też uznanych za standard może w rezultacie pogorszyć, a nie polepszyć naszą sytuację. Czy "piramida testów" może się okazać piramidalną bzdurą? Czy raporty z testowania naprawdę mówią prawdę? Czy testy białoskrzynkowe muszą dotyczyć pokrycia kodu? Czy zamiast przeprowadzać żmudny proces rekrutacyjny, aby sprawdzić jakość kandydata na testera możemy to zrobić zadając mu tylko jedno, proste pytanie? Po drugie, zachęcam słuchaczy do refleksji na temat tego, co w takim razie w testowaniu powinno być rzeczą dla testera najważniejszą. Czy jest to znajomość pojęć i definicji ISTQB? Zdolność automatyzacji testów? A może umiejętność tworzenia raportów? To wszystko jest oczywiście ważne, ale są rzeczy ważniejsze, które chyba zbyt często nam umykają. Zastanówmy się więc, czego dotyczy testerski "spór o uniwersalia". Po trzecie, proponuję autorski model testowania, który może pomóc w racjonalnym postępowaniu podczas testowania oprogramowania, zwiększyć efektywność, pobudzić kreatywność testera oraz uniknąć błędów i pułapek opisanych powyżej. Model doskonale nadaje się do wykorzystania jako heurystyka dla testowania eksploracyjnego. Pokazuję jego zastosowanie na konkretnym, rzeczywistym przykładzie. I po czwarte, rozszyfrowuję tytułowy skrót TDT, oznaczający jedynie słuszne i uniwersalne podejście do testów.
Adam Roman
Adam Roman - adiunkt w Instytucie Informatyki i Matematyki Komputerowej Uniwersytetu Jagiellońskiego oraz Lider QA R&D w Rivet Group. Od wielu lat wykłada przedmioty związane m.in. z testowaniem oraz zapewnianiem jakości oprogramowania, jest trenerem kursów przygotowujących do uzyskania certyfikatów ISTQB. Prowadzi projekty naukowo-badawcze, a w Rivet Group odpowiada również za innowacyjność
i merytorykę projektów. Autor podręcznika “Testowanie i jakość oprogramowania – metody, modele
i narzędzia”. Certyfikowany inżynier jakości oprogramowania (ASQ CSQE) oraz tester (ISTQB Full Advanced). Członek Polskiego Komitetu Normalizacyjnego oraz Stowarzyszenia Jakości Systemów Informatycznych.
Prezentacje z konferenji publikowane są na kanale YouTube >>
