Kto powinien napisać plan testu?

10

Jestem w wewnętrznym zespole programistycznym mojej firmy i rozwijamy strony internetowe naszej firmy zgodnie z wymaganiami zespołu marketingowego. Przed udostępnieniem im strony internetowej w celu przetestowania akceptacji poproszono nas o przedstawienie im planu testów.

Jednak zespół programistów uważa, że ​​ponieważ wymagania pochodziły od wnioskodawców, mieliby oni najlepszą wiedzę na temat tego, co testować, na co zwracać uwagę, jak powinno się zachowywać itp., A zatem plan testów nie jest wymagany. Zawsze się o to kłócić, a programiści tracą czas na zapisywanie takich rzeczy jak:

  1. Kliknij w przycisk A .
  2. Klucz w XYZ w przycisk pola formularza i kliknij pensjonatów .
  3. Powinieneś zobaczyć zachowanie C .

które musimy powtórzyć dla każdego wymaganego wymagania / funkcji. Jest to w zasadzie przeformułowanie tego, co jest już w dokumencie wymagań.

Zmierzamy w kierunku zastosowania zwinnego podejścia do zarządzania naszymi projektami i jest to również wymagane na końcu każdej iteracji.

Pomijając testy jednostkowe i integracyjne, kto powinien opracować plan testów akceptacyjnych dla użytkownika końcowego? Czy powinni to być wnioskodawcy, czy programiści?

Z góry bardzo dziękuję.

Pozdrawiam
CK

ckng
źródło
1
Jedynym wkładem w to, co powinni mieć deweloperzy, jest sugerowanie obszarów i ewentualnie niektórych przypadków skrajnych, które należy przetestować (i nie zapomnieć). Nie powinny jednak podawać szczegółowych informacji o tym, jak dokładnie testować.
CaffGeek

Odpowiedzi:

10

Plan testów NIE powinien być pisany przez programistów. Częścią tego, co ma zrobić plan testowy, jest sprawdzenie, czy programista poprawnie zinterpretował to wymaganie. Deweloper nie może skutecznie napisać planu testu na kodzie, który zamierza napisać. Plany testowe powinny być pisane przez osoby, które będą przeprowadzać kontrolę jakości lub przez analityków biznesowych. Jeśli programiści muszą napisać plany, nigdy nie przydzielaj nikomu osoby do napisania planu dla części programu, którą zamierza napisać.

Zauważ, że różni się to od projektowania testów jednostkowych, które musi napisać programista, ponieważ powinien on testować napisany przez siebie kod, aby sprawdzić, czy robi to, czego się spodziewał. Ale plany testów mają na celu sprawdzenie, czy aplikacja działa tak, jak powinna działać, i musi to zrobić ktoś, kto nie wie, w jaki sposób aplikacja została zaprojektowana technicznie do działania, aby była skuteczna.

HLGEM
źródło
Tak mówiłem przez lata w jednej pracy.
David Thornley,
1
Dobrze, aż do ostatniego zdania, ale testowanie nigdy nie powinno polegać wyłącznie na sprawdzeniu, czy aplikacja spełnia oczekiwania (ale powinna również obejmować nieoczekiwane!), A wiedza co najmniej o tym, jak aplikacja została zaprojektowana technicznie ZAWSZE pomaga mi jako testerowi zidentyfikować pęknięcia, w które mogę wpakować mój łom testera, aby szeroko otworzyć przedmiot. ;) Wyobrażanie sobie, że testerzy lepiej nie wiedzą nic o implementacji, jest trochę staromodne.
testerab
1
Dokładnie, @testerab. Brak znajomości elementów wewnętrznych pomaga zaprojektować niektóre typy przypadków testowych, podczas gdy znajomość elementów wewnętrznych pomaga w testowaniu szarych skrzynek, np. Znam obszar ryzyka w kodzie, muszę tylko udowodnić aplikacji, aby osiągnęła ten kod.
dzieciou
7

Zespół kontroli jakości powinien napisać i wykonać plan testów.

Idealnie plan testu powinien być napisany równolegle ze specyfikacją funkcjonalną - to niesamowite, jak myślenie o tym, jak przetestować funkcjonalność, koncentruje umysł i poprawia specyfikację.

Chris Card
źródło
3
Prawdopodobnie z pomocą programistów, ale głównie zespołu QA.
Zachary K,
Co jeśli nie mamy zespołu kontroli jakości? Czy to zadanie powinno zatem spoczywać na wnioskodawcach? Z odpowiedzi tutaj byłoby to najbardziej logiczne.
ckng
Jeśli zmierzasz w kierunku Agile, spróbuj zatrudnić osoby, które specjalizują się w testowaniu, do swojego obecnego zespołu programistów. (Uwaga: poczytaj najpierw o różnych szkołach testowania, niektóre nie są zgodne z podejściem zwinnym - redcanary.mypublicsquare.com/view/hiring-software )
testerab
2
Jeśli nie masz zespołu ds. Kontroli jakości, będziesz musiał spotkać się z wnioskodawcami, aby podjąć tę decyzję. Z jednej strony deweloperzy nie powinni robić planów testowych. Z drugiej strony wielu / większość klientów biznesowych nie zna się na testowaniu, a na początku wydasz MASĘ SZKOLENIA I TRZYMANIA RĘK. Wypróbowaliśmy to raz, a klienci biznesowi walczyli przez długi czas. Zwykłe przypadki nie były niczym wielkim, ale gdy chodziło o szczegółowe przypadki, a zwłaszcza negatywne przypadki testowe, zmagały się. Lepiej byłoby zdobyć / wyznaczyć specjalistę ds. Kontroli jakości lub analityka biznesowego niż przypisać go klientom.
sekek
4

Odpowiedź Scruma: jeśli chcesz zdefiniować „definicję ukończenia”, zauważysz, że posiadanie planu testów szybko staje się jednym z elementów. Jak inaczej możesz opisać historię do zrobienia, jeśli nie została przetestowana.

Kto jest zatem odpowiedzialny za stworzenie planu testów? Drużyna

Kim jest zespół? Każda osoba zaangażowana w realizację produktu powinna być członkiem Zespołu.

Więc w twoim przypadku możesz dołączyć (lub zatrudnić) osobę, która może napisać plany testów do swojego „zespołu programistów”. Jeśli przejdziesz do Agile, zauważysz, że tworzenie planu testowania odbywa się równolegle z rozwojem. Oba zaczynają się od tej samej historii, a poprzez komunikację są zsynchronizowane i dostarczane jednocześnie. Nie powinieneś ogłaszać, że Twoja historia jest „skończona”, zanim przejdziesz testy, które interesariusze uważają za krytyczne.

Rudi
źródło
2

Uważam, że plany testów funkcjonalnych powinny być pisane przez analityków funkcjonalnych / biznesowych. Piszą analizę funkcjonalną (nawet jeśli pracujesz zwinnie, zakładam, że masz jakąś analizę), więc powinni zapisywać, jakie ścieżki w aplikacji należy stosować do celów testowych.

Zależy to całkowicie od tego, jak pracujesz, ale moim zdaniem programiści nie powinni pisać funkcjonalnych dokumentów na temat testowania aplikacji, jakich danych użyć, aby ją przetestować itp.

koenmetsu
źródło
2

Oto pomysł, który może uszczęśliwić obie grupy i dobrze wpasować się w podejście zwinne:

Zautomatyzuj kontrole akceptacji użytkowników i zrzuć je z ekranu.

http://pragprog.com/magazines/2009-12/automating-screencasts

Wydaje się, że częścią twojego problemu jest to, że pisane plany testów są bardzo powtarzalne i mają charakter wyłącznie potwierdzający. Szczerze mówiąc, w ogóle nie nazwałbym tego, co piszesz, testowaniem - jeśli tylko potwierdza wymagania, sprawdza . Zautomatyzowanie tego i screencasting pozwoli ci regularnie spakować fajne demo dla swoich klientów (możesz nawet wysłać je przez krótką dobę) - chętniej klikną demo i obejrzą go, niż otworzą plan testowy i zacznij nad tym pracować, więc mam nadzieję, że otrzymasz szybszą informację zwrotną (bardzo ważne, jeśli zmierzasz w kierunku bardziej zwinnego podejścia). Będziesz mógł ponownie używać komponentów, aby zmniejszyć obciążenie,

Zapewnia również sposób faktycznego spełnienia wymagań - czy natknąłeś się na specyfikację wykonywalną Gojko Adzic? Spójrz tutaj: http://gojko.net/2010/08/04/lets-change-the-tune/ Jeśli myślisz o tym, jako o sposobie wprowadzenia wymagań do postaci wykonywalnej w celu pokazania ich klientom , to nagle wydaje się o wiele mniej bezcelowe.

Teraz, zakładając kapelusz testera, mam zaszczyt wskazać, że jeśli element screencastu wystartuje, uwolni ciebie / twoich interesariuszy do przeprowadzenia odpowiednich testów - tj. Wypróbowania przypadkowych przypadków i testów, które faktycznie rzucają wyzwanie aplikacji , a nie tylko potwierdzanie wymagań. Sugeruję dostarczenie screencastów wraz z krótkimi pytaniami lub sugestiami dotyczącymi obszarów, w których chcesz uzyskać więcej opinii, na przykład:

1) Oto nasz nowy formularz rejestracyjny - obejrzyj screencast, aby zobaczyć, jak to działa!

Czego oczekujemy od nas opinii: Dodaliśmy wiele dodatkowych kontroli w tym formularzu, aby upewnić się, że klienci nie są w stanie wprowadzić niewłaściwych danych - naprawdę chcielibyśmy, abyś spojrzał na komunikaty o błędach, które otrzymują klienci włóż niewłaściwą rzecz i powiedz nam, czy nasi klienci uznają ich za łatwych do zrozumienia.
Chcielibyśmy również wiedzieć, czy w niektórych przypadkach byliśmy zbyt rygorystyczni - jeśli masz jakieś wyjątkowo nietypowe dane klientów (być może naprawdę długie lub bardzo krótkie imię lub ktoś z nietypowymi postaciami w imieniu, lub coś innego, o czym nie pomyśleliśmy, a może ich adres nie ma nazwy ulicy lub czegoś takiego dziwnego?), a może mógłbyś poświęcić kilka minut na ich wypróbowanie?

Oznacza to, że prezentujesz fajny screencast, a następnie pytasz o opinie, kadrując je, nie będąc zbyt konkretnym, spraw, aby zastanowili się nad potencjalnymi problemami, a nie tylko potwierdzili. Pobierz je myślenia , zamiast po prostu klikając na ślepo przez planem badań. Zasadniczo piszesz dla nich kartę testu eksploracyjnego . (Jeśli spojrzysz na zwinne kwadraty testowe , byłyby to testy w kwadrancie 3).

testerab
źródło
Świetna odpowiedź, świetny sposób na wydobycie deweloperów z nudnej monotonii i uzyskanie opinii od klientów. I świetne linki.
Ethel Evans
1

Weźmy za przykład remont domu. Czy zaakceptowałbyś listę kontrolną sporządzoną przez kontrahenta z prośbą o sprawdzenie, co dla ciebie zrobił? A może wymyślisz własną listę kontrolną i sprawdzisz, czy wykonawca zrobił to, co wskazałeś?

Odpowiedź jest jasna: wnioskodawca powinien sprawdzić, czy to, o co prosił, zostało wykonane zgodnie ze specyfikacją. Powinien wyjść z własną listą kontrolną i przetestować aplikację. przeciwko tej liście.

Deweloper powinien jednak mieć własną listę kontrolną i upewnić się, że przeprowadzono odpowiednie testy wewnętrzne i usunięto błędy przed obsługą aplikacji. ponad dla UAT. Idealnie, programista powinien zautomatyzować większość tych testów w formie skryptów testowych. Pamiętasz TDD? Najlepiej byłoby napisać skrypty testowe (w tym przypadku przypadki testów jednostkowych) do testowania komponentów aplikacji. Następnie należy napisać zestaw testów, aby połączyć te przypadki testów jednostkowych w celu przeprowadzenia zintegrowanych, a następnie regresyjnych testów.


źródło
1

Plan testów akceptacyjnych dla użytkownika końcowego jest zwykle pisany przez klientów lub współpracownika w firmie, która reprezentuje klienta. Ma reprezentować funkcje, których chce klient, i stanowi uzupełnienie testów integracyjnych QA. Ani QA, ani Development nie mogą skutecznie zaplanować testów akceptacji użytkownika, ponieważ jednym z głównych celów testów akceptacji użytkownika jest upewnienie się, że to, co QA i Development uważali za pożądane przez klienta, jest rzeczywiście dokładne.

Ethel Evans
źródło
en.wikipedia.org/wiki/... po więcej informacji.
Ethel Evans
+1 za wskazanie, że testy akceptacyjne użytkownika muszą być zaprojektowane przez użytkownika. Chociaż w mojej odpowiedzi zasugerowałem alternatywne podejście (ponieważ nie wydaje się, że faktycznie mają one zasoby QA), testy akceptacji użytkowników nie mogą być skutecznie przeprowadzone przez osoby niebędące użytkownikami. W tej sytuacji wygląda na to, że zarówno deweloperzy, jak i użytkownicy są w impasie, więc myślę, że deweloper musi spróbować jakoś to przełamać.
testerab