Jeśli prowadziłby projekt wykorzystujący BDD ze 100% udziałem historii użytkowników z automatycznymi testami akceptacyjnymi, jaka byłaby rola osoby testującej / zapewniającej jakość?
Myślę, że wyobrażam sobie, że programiści napisaliby testy akceptacyjne we współpracy z właścicielem produktu. Daj mi znać, jeśli wydaje się to niemądrym założeniem.
Odpowiedzi:
Być może jestem zbyt staroświecki, ale nawet najnowocześniejsze techniki opracowywania lub przetwarzania nie mogą zastąpić innego zestawu oczu, świeżych oczu, przed wydaniem produktu klientowi.
Nawet jeśli twój produkt jest po prostu interfejsem API dla innego programisty, możesz użyć kontroli jakości, aby myśleć jak użytkownik interfejsu API, zapewniając scenariusze testowania / użycia, o których ty lub twój klient nie pomyśleliście z góry.
Jeśli Twój produkt jest oparty na interfejsie użytkownika, zdecydowanie chcesz, aby inna osoba (to nie ty ani ktoś z twojego zespołu) szukała ostatecznego wyniku przed wysłaniem go do klienta.
Jak każde inne modne hasło w naszej branży, BDD - nawet przy 100% pokryciu - nie jest srebrną kulą .
100% pokrycia to nie to samo co 100% testowane.
Widziałbym osobę QA w projekcie ATDD jako osobę, która pomogłaby napisać testy i przeprowadzić inne rodzaje testów, które nadal istnieją. Tj. Testy interfejsu użytkownika, testy zniszczenia i testy obciążenia / obciążenia.
Ale nigdy nie opracowałem projektu ATDD.
Zadaniem QA jest zerwanie aplikacji, a zadaniem programisty nie zerwanie jej. Dlatego piszą swoje testy z innej perspektywy. Na przykład deweloperzy piszą testy, aby sprawdzić, czy nastąpi spodziewane zachowanie, QA zapisuje testy, aby zobaczyć, co się stanie, gdy użytkownicy zrobią coś, czego deweloper nigdy by nie pomyślał. Co więcej, programiści często błędnie interpretują wymagania, a testy jakości wychwytują, gdy ich interpretacja różni się od tego, co deweloper uważał, że ma to na myśli, a następnie spotykają się z interesariuszami projektu, aby ustalić, która interpretacja jest poprawna. Testy napisane przez programistów, którzy napisali kod, często mają duże martwe punkty, ponieważ deweloper miał dużą martwą stronę. Na przykład może przetestować, co dzieje się w 97% przypadków, ale nie przypadki skrajne.
U poprzedniego pracodawcy rolą QA było nie testowanie produktu, ale zagwarantowanie, że programiści zasadniczo zrobili to, co zamierzali zrobić w odniesieniu do wcześniej zdefiniowanych testów akceptacyjnych, które zostały zdefiniowane przez QA.
Z drugiej strony właściciel produktu nie miał absolutnie nic wspólnego z testowaniem. Radzenie sobie z testowaniem na dowolnym poziomie IMHO nie jest rolą właściciela produktu.
W pewnym momencie musisz mieć zaufanie do swoich pracowników; kontrole i wyważenia są dobre, ale nie powinieneś zmuszać się do wymuszania rozwiązania w cyklu rozwojowym, które w rzeczywistości dotyczy tylko niewielkiej części etyki pracy pracowników.
W idealnym świecie współpraca z programistami i QA formalizuje się wraz z pisaniem testów akceptacyjnych we wspólny sposób. Kontrola jakości powinna przynieść inny aspekt do stołu, niż powinien mieć zespół programistów. Kontrola jakości powinna mieć rękę na torcie w początkowej fazie rozwoju produktu i pozostać zaangażowana przez cały cykl. Z drugiej strony właściciel produktu powinien następnie zaangażować się w kontrolę jakości w celu zrozumienia obecnego stanu produktu, ryzyka itp. I skoncentrować się na produkcie w sposób całościowy; nie konkretne niuanse, które składają się na produkt.
Z mojego doświadczenia: test jednostkowy obejmował ponad 90% kodu. Były też testy integracyjne i kompilacje godzinowe. jBehave testy dla BDD.
Rola kontroli jakości: - przyjmowanie historii użytkowników do testowania - pisanie kodu za krokami - testowanie eksploracji za pomocą wtyczki RestClient dla IDEA (dlatego znaleźliśmy kilka poważnych błędów)
Część BDD stosuje podejście 3 Amigos, w którym interesariusze współpracują w celu opracowania kryteriów akceptacji. QA / Dev może napisać kod kroku, aby scenariusze były wykonywane jako testy akceptacyjne. Gdzie jest wartość QA, aby ręcznie wykonać te same testy akceptacyjne, które narzędzie BDD wykona automatycznie? Wartość dodana QA polega na sprawdzeniu poprawności tych testów akceptacyjnych i przeprowadzeniu ręcznych badań eksploracyjnych poza skryptowymi testami akceptacyjnymi. Powielanie zwykle daje ten sam wynik.
Programiści nie przepisują wymagań i specyfikacji, QA nie przepisują kodu aplikacji ... możliwe jest, że QA nie będzie musiała wykonywać tych samych skryptowych testów, które programiści wykonują jako testy akceptacyjne. Czas, aby Devs założyli czapkę QA!