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

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)

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

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.

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

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.

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 ++:

• Szybkie wprowadzenie do struktury testowej Google C ++
• Narzędzia do testowania jednostek C / C ++ typu open source, część 1: Poznaj strukturę testów jednostek Boost
• Narzędzia do testowania jednostek C / C ++ typu open source, część 3: Poznaj CppTest

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

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.

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.

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.