Wzajemna ocena testów, podobnie jak recenzje kodu

Czy ktoś ćwiczy proces „przeglądu kodu” testów funkcjonalnych? Czy uważasz to za przydatne? W sposobie, w jaki mój obecny pracodawca stosuje SCRUM, uwzględniamy testy funkcjonalne jako część naszych „obowiązkowych działań” w każdym sprincie.

Ćwiczymy również SCRUM. Podobnie jak Ty, uwzględniamy również testy funkcjonalne jako część naszej definicji.

Z mojego doświadczenia wynika, że ​​jest to niezwykle przydatne. Znacząco zmniejszyliśmy liczbę błędów w naszym kodzie, po prostu wymuszając testy funkcjonalne.

Drugą fajną rzeczą w przeglądzie kodu jest to, że daje on inny widok na rzeczywistą funkcjonalność i daje 100% pewność, że jest zgodny z tym, czego chciał klient / klient. Kilka razy ktoś sprawdzał kod i funkcjonalność, w którym poszedł ... „Poczekaj, to nie jest poprawne ...” i okazało się, że osoba wdrażająca kod po prostu coś źle zrozumiała.

Dobre niebiosa tak (staram się nie używać przekleństw na SO; p). Recenzowanie testów funkcjonalnych polega w zasadzie na recenzowaniu twoich wymagań i analiz, jest to niezwykle ważne, a jeśli używasz języka BDD, takiego jak ogórek, możesz również zaangażować osoby niebędące programistami!

To niesamowite, gdy nasi użytkownicy końcowi zauważają problemy z naszymi testami funkcjonalnymi i sprawiają, że czują się niezwykle zaangażowani w proces tworzenia „Mogę też czytać kod !!”

Ma to dla mnie idealny sens. Każdy napisany kod powinien być sprawdzany przez kogoś innego, nawet jeśli kod jest używany tylko wewnętrznie i nigdy nie zostanie uruchomiony przez klienta.

Dzięki metodologiom, które przykładają tak dużą wagę do testowania, przegląd testów staje się znacznie ważniejszy, być może wymagany, czasem ważniejszy niż przegląd samego kodu, ponieważ często zakłada się, że można go zastąpić dowolnym kodem, który spełnia ten sam zautomatyzowany wynik testu.

Sprawdzenie, czy testy są prawidłowe, jest jednym z aspektów, że są one wystarczająco kompletne i dokładne / reprezentatywne jest również bardzo ważne.

Brak tego punktu jest jedną z rzeczy, które sprawiają, że te metodologie wydają się niechlujne dla zewnętrznych recenzentów.

Możesz wykonywać kontrole parami!

Inspekcje parowe to:

Przegląd dokumentów aktywnie i nieformalnie w ramach cyklu tworzenia i produkcji dokumentów.

Powody, dla których działa to dobrze w testach, to:

1. Często można sprawdzać wymagania lub dokumenty za pomocą więcej niż jednej pary oczu.
2. Możesz zaangażować więcej niż tylko programistów: wypróbuj BA z przewodem pomiarowym, BA z PM, BA z Dev.
3. Możesz ustawić spotkania ponownego leczenia w ramach zwinnego procesu - pamiętaj o poważnym podejściu do niego z solidnymi zobowiązaniami członków zespołu.
4. Możesz wykorzystać te kontrole par jako część ćwiczenia budowania relacji i ćwiczenia komunikacji z interesariuszami. Rozpocznij rozmowę!

Sprawdzamy testy funkcjonalne przynajmniej od czasu do czasu i zdecydowanie zachęca się naszą organizację do sprawdzania wszystkiego pod kątem kodu.

Polecam wybranie recenzenta na podstawie celów przeglądu. Testy kodowane najlepiej sprawdzać zarówno przez programistę (przede wszystkim pod względem jakości kodu), jak i przez inny tester (przede wszystkim pod kątem zasięgu testu). Testy bez kodu (z wykorzystaniem wiązki, np. Testy oparte na danych) najlepiej sprawdzać może tylko inny tester. Recenzje są również świetnym sposobem na zachęcenie testerów do uczenia się od siebie.