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)
źródło
Odpowiedzi:
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:
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
źródło
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.
źródło
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ń.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
Ty piszesz:
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.
źródło