Czy programiści powinni być zaangażowani w fazy testowania?

10

używamy klasycznego procesu rozwoju w kształcie litery V. Następnie mamy wymagania, architekturę, projekt, implementację, testy integracji, testy systemu i akceptację.
Testerzy przygotowują przypadki testowe podczas pierwszych faz projektu. Problem polega na tym, że z powodu problemów z zasobami (*) fazy testowe są zbyt długie i często są skracane z powodu ograniczeń czasowych (znasz kierowników projektów ...;)). Deweloperzy przeprowadzają testy jednostkowe tak, jak powinni.

Więc moje pytanie jest proste: czy programiści powinni brać udział w fazach testowych i czy nie jest to zbyt „niebezpieczne”. Obawiam się, że da to kierownikom projektu fałszywe poczucie lepszej jakości, ponieważ praca została wykonana, ale czy dodatkowy man.day miałby jakąkolwiek wartość? Nie jestem do końca pewny, czy programiści przeprowadzają testy (tutaj nie ma urazy, ale wszyscy wiemy, że ciężko jest złamać za pomocą kilku kliknięć, co zrobiłeś w kilku dniach).

Dziękujemy za podzielenie się swoimi przemyśleniami.

(*) Z niejasnych powodów zwiększenie liczby testerów nie jest obecnie opcją.

(Z góry, nie jest to duplikat Czy programiści powinni pomagać testerom w projektowaniu testów ?, który mówi o przygotowaniu testów, a nie o wykonywaniu testów, w którym unikamy wpływu programistów)

LudoMC
źródło
Edytowane precyzyjny, że nasi programiści robi swoje testy jednostkowe. martwię się fazami po testach jednostkowych, kiedy faceci QA wchodzą w pętlę.
LudoMC,
Hmmm, nie będzie łatwo wybrać pomiędzy „absolutnie jednoznacznym TAK” a „absolutnie nie”. Pomyślę o tym trochę więcej, czekając na inne odpowiedzi lub komentarze do odpowiedzi, aby uzyskać wyraźniejszy widok.
LudoMC,
Ok, zaakceptowałem jedną odpowiedź, ale także głosowałem za innymi, które dostarczyły dobrych argumentów dla problemu. Dziękuje za wszystko.
LudoMC,

Odpowiedzi:

13

Patrząc na twoje pytanie bardzo dosłownie („zaangażowany w”) Moja jedyna odpowiedź jest absolutnie jednoznaczna

TAK

Twórcy nigdy nie powinni decydować o swoim własnym kodzie.

Ale deweloperzy powinni być zaangażowani w testowanie pracy innych deweloperów. Robi dwie rzeczy:

  1. Daje wgląd dewelopera do testowania. Wynika to zarówno z ogólnego przypadku, gdy tylko wiadomo, które interfejsy API są prawdopodobnie używane w danym momencie, jakie wyjątki mogą wynikać z tych interfejsów API i jak należy z nimi postępować. Pomaga również w konkretnym projekcie, ponieważ deweloperzy są znacznie bardziej narażeni na różne dyskusje na temat tego, dlaczego coś się dzieje, niż zwykle w QA, co oznacza, że ​​mogą wykryć przypadki skrajne, których nie zapewniłaby QA. Błędy wykryte przez dewelopera mogą być również tańsze do naprawienia, ponieważ deweloper zwykle dostarcza więcej informacji i znacznie więcej wglądu, jak to naprawić.
  2. Daje deweloperowi ekspozycję na części aplikacji, na które w innym przypadku nie mogliby zostać narażone. Dzięki temu w dłuższej perspektywie będą lepszymi programistami dla tej aplikacji. Kiedy wiem, w jaki sposób wykorzystywany jest mój interfejs API, jestem znacznie lepszy w przewidywaniu następnej rzeczy, którą powinienem zrobić, niż gdybym tylko odpędzał specyfikację. Co najważniejsze, mogę wiedzieć, kiedy specyfikacja jest nieprawidłowa, zanim zacznę kodować, jeśli znam aplikację i jej użycie.

Wreszcie, dlaczego nie użyłbyś tak wielu oczu, jak to możliwe? Rzadko można sobie pozwolić na przejście przez proces zatrudniania i dołączania, aby zapewnić dodatkowe osoby odpowiedzialne za kontrolę jakości na czas kryzysu. Gdzie więc znajdziesz dodatkowe oczy, których potrzebujesz? A może starasz się przetrwać czas chrupnięcia przy takiej samej liczbie kontroli jakości, jaką miałeś przez cały czas? Nawet jeśli deweloperzy spędzają 20% czasu na testowaniu i 80% na naprawianiu błędów, nadal ma więcej uwagi na aplikację niż wcześniej. Zautomatyzowane testowanie daje tylko pewien poziom pewności i nigdy nie będzie w 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

MIA
źródło
+1, ponieważ programiści powinni być zaangażowani w sprawdzanie kodu innego użytkownika
Gary Rowe
Zaakceptuję ten ze względu na 1 - podany link (bardzo interesujący i ściśle związany z naszą sytuacją) 2 - dobre argumenty w twojej odpowiedzi: fakt, że programiści nie powinni testować własnego kodu, że daje im to dobry widok innych części aplikacji lub systemu.
LudoMC,
11

Do niczego poza testowaniem jednostkowym, absolutnie nie. Programiści po prostu wiedzą za dużo o aplikacji i o tym, jak „powinna” działać jako obiektywny tester.

kirk.burleson
źródło
2
W większości się z tym całkowicie zgadzam. Jednak stanowisko mówi, że zespół QA jest odpowiedzialny za wymyślenie przypadków testowych. Zakładając, że testy są dokładnie omówione, nie widzę ważnego powodu, dla którego programiści nie mogliby przejrzeć przypadków testowych przed wydaniem oprogramowania do kontroli jakości. Może to pomóc wcześnie wykryć błędy i zmniejszyć obciążenie wynikające z wielu wydań poprawek.
Pemdas
2
Nie zgadzam się z tym stanowiskiem, ponieważ posiadanie oka programisty może być niezwykle korzystne podczas testowania funkcjonalnego. Deweloper jest cennym zasobem, dlatego nie powinien przechodzić przez scenariusze testów na odległość, może raczej doradzić testerom, gdzie udać się do wydajniejszego przerwania aplikacji (sprawiając, że życie testerów będzie przyjemniejsze ...)
Gary Rowe
GR ... ogólnie zgadzam się z twoim stwierdzeniem o tym, że programiści cenią sobie zasób, ale tutaj chodzi naprawdę o zmianę zasobów, które już mają, aby zapewnić odpowiedni zasięg testowy. Jeśli to oznacza, że ​​programiści muszą wziąć udział w testach Qaish, niech tak będzie.
Pemdas
8

Podstawowa różnica w testowaniu filozofii między programistami a Qs jest taka: programista zazwyczaj testuje swój program, aby udowodnić, że jego kod działa (testowanie „pozytywne”). Kontrola jakości może to zrobić i robi to, ale dodatkowo koncentruje się na wykryciu tego , co nie działa , próbując złamać oprogramowanie (używając „negatywnych” testów).

W zakresie, w jakim personel kontroli jakości może zostać potencjalnie uszkodzony przez testowanie programistów, które „dowodzi”, że oprogramowanie działa, powinna istnieć izolacja między testowaniem programisty a testowaniem jakości. Deweloper z pewnością może pomóc w testowaniu kontroli jakości, pokazując, co działa, ale do kontroli jakości należy niezależne sprawdzenie, czy oprogramowanie się nie psuje.

Najlepszą rzeczą, jaką programista może zrobić, aby pomóc w testowaniu, jest zapewnienie kompleksowego, wysokiej jakości, weryfikowalnego pakietu testów jednostkowych, zawierającego testy, które są zgodne z indywidualnymi wymaganiami w dokumencie wymagań.

Robert Harvey
źródło
2

Pod względem testowania istnieją 3 typy.

Czarne pudełko, szare pudełko i białe pudełko.

Czarna skrzynka oznacza użytkowników testujących produkt, bez wiedzy na temat jego wewnętrznego działania.

Szare pole odnosi się do zaawansowanych użytkowników, którzy mają wiedzę na temat programowania komputerów, ale nie należą do zespołu programistów. Osoby te sprawdzą, czy w produkcie występują wycieki pamięci, problem z wymaganiami systemowymi i tak dalej.

Oto główna część: Białe pudełko odnosi się do programistów testujących produkt na poziomie kodu. Oznacza to, że mówią, że przeprowadzają testy jednostkowe, debugowanie itp.

Dlatego dobrze, że wszyscy użytkownicy i zespół programistów są zaangażowani w fazę testowania, ale każde z testów wymaga odpowiedniego poziomu zaangażowania ze strony użytkowników i zespołu programistów, w zależności od tego, co jest testowane.

Mauris
źródło
2

TESTOWANIE JEDNOSTEK jest koniecznością dla wszystkich programistów

Aby uzyskać informacje na temat tego, jak można to wykorzystać na swoją korzyść, przeczytaj poniższe linki, jeśli jesteś w rozwoju C ++:

NIE MA ŻADNEGO SPOSOBU, ABY OSOBA QA MOŻE ZROBIĆ TE TESTY. NIE MA MOWY.

Fanatyk 23
źródło
Zgadzam się, ale zadawałem to pytanie w drugą stronę. Czy programiści powinni być zaangażowani w testowanie (z wyłączeniem testów jednostkowych), w których zwykle uczestniczą tylko osoby zapewniające kontrolę jakości?
LudoMC,
1

Zakładając, że projekt ma znaczną liczbę programistów, to z całą pewnością programiści pracują nad testowaniem. Jednym zastrzeżeniem byłoby to, że programiści nie pracują nad testowaniem (nie obejmuje testowania jednostkowego) własnego kodu.

John Percival Hackworth
źródło
+1 dla programistów, którzy nie testują własnego kodu (a przynajmniej nie samodzielnie)
LudoMC,
0

Wolę, aby pracownicy administracyjni (lub potencjalni potencjalni użytkownicy) wykonywali testy kontroli jakości niż programiści. Ktoś, kto nie wie, jak produkt został zaprojektowany, musi spróbować go użyć. Programiści mają bardzo ograniczone podejście do testowania i, szczerze mówiąc, są zbyt drogie na godzinę, aby użyć ich również do testowania jakości.

HLGEM
źródło
0

Ty piszesz:

Problem polega na tym, że z powodu problemów z zasobami (*) fazy testowe są zbyt długie i często są skracane z powodu ograniczeń czasowych To dlatego, że programiści ich nie robią. Jedna z największych firm internetowych dostarczających najlepsze, najbardziej stabilne produkty w ogóle nie korzysta z testerów. Używają tylko testów automatycznych, wszystko wykonane przez samych programistów. Wyniki są x10 lepszymi produktami niż w przypadku, gdy programista zostawia testy „testerom”.

To tak, jakby pracownicy budowlani zbudowali dom, ale inny zespół musi się upewnić, że budynek rzeczywiście stoi, drzwi się otwierają i zamykają, działa klimatyzacja itp. Prawdopodobnie zajmie to x10, a większość z nich skończy być niewiarygodnym.

Chłopak
źródło