Kiedy należy zakończyć rozwój i rozpocząć kontrolę jakości?

Piszemy pełną specyfikację funkcjonalną dla naszego dwuosobowego zespołu programistów. Nie mamy profesjonalnych testerów, jednak opracowaliśmy z pomocą naszego dostępnego personelu działu pomocy technicznej, aby przeprowadzić „testowanie jakości”.

W przeszłości mieliśmy problemy z brakiem pełnej funkcjonalności, lub dostarczenie kodu jest niezgodne ze specyfikacją.

Moje pytania brzmią: na jakim etapie programiści powinni przestać kodować pod ręką zespół QA? Czy to zbyt wiele, aby prosić programistów o sprawdzenie kodu pod kątem specyfikacji przed przekazaniem go zespołowi ds. Kontroli jakości?

Nie powinno!

Bardzo trudno jest wykonać całą pracę, zatrzymać, a następnie naprawić wszystkie problemy. Po rozwiązaniu problemu znalezionego podczas procesu kontroli jakości możesz dowiedzieć się, że lepiej byłoby zrobić coś inaczej.

Zamiast myśleć o wszystkim jako o procesie blokowania, spróbuj uczynić to bardziej cyklicznym. Zakoduj niektóre funkcje i przetestuj je. Kod jeszcze trochę i przetestuj (a stare rzeczy nadal działają). Ten bardziej płynny proces łagodzi trud związany z próbą załadowania wszystkiego z przodu. Nadal możesz mieć pojęcie zawieszania się kodu (po prostu naprawiać błędy), kiedy zbliżasz się do terminu, ale chodzi o to, aby testować wcześnie i często.

Cóż, jeśli całe sekcje kodu są przekazywane do kontroli jakości w stanie niedziałającym, być może powinieneś rozważyć dodanie pewnego rodzaju testów jednostkowych / integracyjnych do swojego procesu. Nie nadużywaj swoich pracowników ds. Kontroli jakości, zmuszając ich do odkrycia, że ​​nie udało Ci się przetestować kodu jednostkowego lub integracyjnego.

To delikatna linia, ponieważ jeśli kod jest dostarczany zgodnie ze specyfikacją, to dla mnie oznacza to, że nie ma błędów (i nie ma potrzeby kontroli jakości!). Fakt, że kod rutynowo nie jest dostarczany zgodnie ze specyfikacją, jest powodem, dla którego przeprowadzamy kontrolę jakości w pierwszej kolejności.

Ale tak naprawdę nie sądzę, że o tym mówisz. Masz na myśli to, że zespół programistów wydaje się zbyt leniwy w kodowaniu i istnieją duże oczywiste rzeczy, które nie działają. Ustalenie przed testem, że testy jednostkowe muszą być obecne dla każdej z funkcji A, B i C (w specyfikacji), a następnie poddanie niezależnego przeglądu kodu i testów (przez zespół lub menedżera) powinny pomóc w rozwiązaniu tego rodzaju problemu .

Twierdziłbym, że przynajmniej programiści powinni przetestować „szczęśliwą ścieżkę”. Że jeśli wprowadzą oczekiwane dane, robi to, co według specyfikacji powinno zrobić. Programiści, którzy nie robią tak wiele, powinni zostać przesłuchani.

Jestem również rozczarowany, jeśli programista nie przetestował oczywistych przypadków skrajnych: ciąg zbyt długi dla bazy danych, oczywiście niepoprawny tekst, jeśli wprowadzasz litery tam, gdzie powinna być liczba itp. Jeśli to się zdarza często, należy ponownie zadać pytania .

Jednak zakładając, że nie jest to wyraźnie wymienione w specyfikacji, jeśli programista ogranicza nazwę do samych wielkich i małych liter, ale zapomina, że ​​niektóre nazwy mają apostrofy lub dopuszcza datę 29 lutego 2011 r. - to nieco bardziej zrozumiałe . Chyba że popełniają ten sam błąd za każdym razem.

Zespół kontroli jakości powinien wychwytywać skrajne przypadki. Wolę QA niż testerów małp: po prostu wprowadzam losowe śmieci, sprawdzając, czy mogą w ten sposób złamać aplikację.

Podczas tworzenia stron internetowych dział kontroli jakości powinien wypróbować różne przeglądarki i spróbować znaleźć wtyczki, które mogą wpłynąć na kod. Powinni wyłączyć Javascript i CSS i zobaczyć, co mogą im w tym pomóc. Tego typu rzeczy. Jeśli oczekujesz, że programiści to zrobią, wydajesz na to zbyt dużo pieniędzy.

Jeśli dostarczana jest funkcja, która nie działa, problem nie polega na rozwoju i kontroli jakości, ale na rozwoju i właścicielach produktu.

Właściciele i programiści produktów powinni należeć do tego samego zespołu i powinni współpracować, aby zdefiniować, co musi działać, aby uznać funkcję za „wykonaną” i upewnić się, że kod spełnia tę potrzebę.

Gdy dostarczany jest kod, testowanie powinno być zwykłą formalnością, ponieważ właściciele produktu powinni współpracować z programistami po drodze, aby upewnić się, że wszystkie przypadki użycia zostały uwzględnione.

(Jeśli masz profesjonalnych testerów, powinni oni należeć do zespołu i powinni być zaangażowani na każdym etapie).

Mamy proces sprawdzania projektów, w którym prosimy programistów o wprowadzenie / pokazanie kodu przed wprowadzeniem kontroli jakości. Uwzględniamy nie tylko testerów zapewniania jakości, ale także właścicieli biznesowych kodu, obsługi klienta oraz marketingu / projektowania. Zwykle koncentruje się na programistach co najmniej na łatwych przypadkach użycia, a czasami wynikowa dyskusja między różnymi zespołami powoduje zmiany specyfikacji i opóźnienie w wejściu do kontroli jakości. Kiedy możemy, włączamy kontrolę jakości dużo wcześniej w proces, co pomaga naprawić błędy, gdy kod jest jeszcze ciepły - ale nadal wykonujemy instrukcje przed rozpoczęciem „oficjalnej” kontroli jakości.

Czasami mówiłem, że kodu nie należy przesyłać do kontroli jakości, jeśli byłbyś zdenerwowany, gdyby przypadkowo trafił do produkcji zamiast kontroli jakości. Kod z dużą dysfunkcją nie należy do kontroli jakości (z wyjątkiem szczególnych okoliczności)