Czy deweloperzy, testerzy i użytkownicy biznesowi powinni mieć jeden zunifikowany skrypt testowy?

W fazie rozwoju zwykle posiadałbym własne skrypty testowe, które dokumentowałyby dane, scenariusze i kroki wykonania, które planuję przetestować; to jest mój plan testowy deweloperów. Po wdrożeniu tej funkcji w Test, testerzy testują ją przy użyciu własnego skryptu testowego, który napisali. W UAT użytkownik biznesowy następnie testuje, korzystając z własnego planu testów.

Z perspektywy czasu wygląda na to, że zapewnia to lepszy zasięg, przy czym testy programistyczne obejmują mieszanie testów czarnych i białych skrzynek, podczas gdy testerzy i użytkownicy biznesowi koncentrują się na testach czarnych skrzynek. Ale z drugiej strony, wywołuje to odrębne przypadki testowe, które są wykonywane tylko na etapie (tj. Niektóre przypadki, o których myśleli testerzy, są wykonywane tylko na etapie testowym) i chciałby, aby deweloper pominął to, co powoduje, że jest to błąd .

Czy warto skonsolidować skrypty testowe od samego początku? Tak więc używając jednego zunifikowanego skryptu testowego, czy jest to trudne do zrobienia z góry?

Po pierwsze, kontrola jakości nie jest testem. Jeśli Twój dział kontroli jakości nie jest zaangażowany w cały proces programowania, oznacza to Test, a nie kontrolę jakości. Kontrola jakości podczas wykonywania pracy zapewnia zapewnienie jakości, w najlepszym wypadku Test pokazuje brak jakości, ale nie może udowodnić, że jakość istnieje - tzn. Test pokazuje, że kontrola jakości nie powiodła się, ale nie może wykazać, że się udało, więc Test i kontrola jakości nie powinny być tym samym działem.

Uważam, że najlepszym sposobem jest, aby każda grupa zarządzała własnymi testami, ponieważ zapewnia to lepszy zasięg. Jednak każdy zespół powinien rozpocząć testy jak najszybciej. Oznacza to, że UAT uruchamia się, gdy tylko coś jest w stanie użyć Użytkownicy, Test rozpoczyna się, gdy tylko część, dla której ma test, jest gotowa itp. Zapobiega to późnemu znalezieniu odrębnych przypadków testowych. Może to oznaczać zmianę modelu pracy, ponieważ często UAT i Test oczekują, że będą pracować nad kompletnym produktem i będą potrzebować szkolenia w zakresie testowania częściowo kompletnych wyników. Może być droższy, chyba że zostanie odrzucony przepływ pracy, a programista „Kompletny” oznacza Kompletny.

Kontrola jakości powinna nadzorować to, wraz z innymi miernikami jakości, aby zapewnić, że proces nie tylko zapewnia pożądaną jakość wyjściową, ale także na odpowiednim poziomie wydajności.

Edycja: oryginalne odniesienie do QA zostało usunięte, dlatego ta odpowiedź jest teraz wyświetlana jako OT.

Używamy UAT od samego początku.

Działa jako uniwersalne odniesienie i myślę, że działa dobrze. Chociaż mogą istnieć skrypty testowe, które są używane tylko przez programistów lub testerów dla mniejszych komponentów, kierunek testów jest zawsze wskazywany w kierunku jednego zunifikowanego celu. Pod koniec dnia liczy się tylko UAT, więc równie dobrze możesz skoncentrować się na starcie.

Wykonywanie UAT od samego początku ma również dodatkową zaletę. Naprawdę usuwa wszelkie niejasności między oczekiwaniami klienta a własnymi.

Nie potrzebują zunifikowanego skryptu testowego, ponieważ rzeczy, które testują i sposób, w jaki przeprowadzają testy, często mają się różnić, to, czego potrzebują, to ujednolicony wymóg, od którego wszystkie strony pracują. Jeśli UAT i QA testują rzeczy, o których deweloper nigdy nie pomyślał, nadszedł czas, aby przyjrzeć się wymaganiom.

Zgadzam się, że posiadanie zunifikowanego skryptu testowego dla programistów, testerów i użytkowników biznesowych byłoby miło mieć, ale wierzę, że nie jest to możliwe bez dużego wysiłku, gdy korzyści oburzają koszty.

Powodem trudności jest to, że zawartość bazy danych w każdym systemie jest inna, a testy zwykle w dużej mierze zależą od zawartości bazy danych. nasze podejście do „ujednoliconych testów” polegało na tym, że każdy system otrzymuje także dodatkową bazę danych testów, a od samego początku istnieją skrypty do tworzenia tej bazy danych. skrypty testowe działają na testdb, gdzie treść jest standaryzowana.

W idealnym świecie deweloperzy muszą mieć testy jednostkowe (xUnit), testery - automatyczne testy integracji (Selenium), a użytkownicy biznesowi - testy akceptacyjne (FIT). Mogą mieć dostęp do siebie testów.

To naprawdę zależy od projektu. W niektórych przypadkach ujednolicony zespół ds. Testów, kontroli jakości i UAT, który spotyka się w celu omówienia ustaleń, może być bardzo korzystny. Pozwala to uniknąć powielania wysiłków związanych z testowaniem i zapewnia wszystkim stronom lepsze zrozumienie potrzeb biznesowych za pomocą skryptów UAT. Z drugiej strony, w zależności od złożoności projektu, sensowniejsze może być dokładne sprawdzenie jakości danych wejściowych i wyjściowych przed przetestowaniem przykładów biznesowych. W przypadku rozwoju własnego systemu wstępna kontrola jakości byłaby konieczna przed akceptacją przez użytkownika. W przypadku niestandardowych implementacji najbardziej sensowny byłby zunifikowany zespół testujący.