Kto powinien napisać plan testu?

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

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.

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ę.

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.

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.

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).

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.

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.