Jaka jest dobra miara wydajności testowania / testera?

Mam zamiar wziąć udział w dyskusji z kierownictwem na temat pomiaru naszej wydajności testowania jako organizacji zapewniania jakości. Głównym powodem tego jest to, że połowa naszego zespołu jest zlecana na zewnątrz, a nasza firma chciałaby podać pewne wskaźniki dotyczące naszej skuteczności / wydajności, abyśmy mieli dane na podstawie których można negocjować parametry umowy z umową serwisową naszych kontrahentów .

Zagłębiłem się trochę i większość opinii na ten temat dotyczy wydajności programistów: wierszy kodu, dostarczonych punktów fabularnych, wprowadzonych defektów itp.

A co z testerami? Nasze testy opierają się głównie na wymaganiach i są połączeniem testów ręcznych, półautomatycznych i automatycznych (nie dlatego, że nie zautomatyzowaliśmy wszystkiego, ale ponieważ niektóre rzeczy nie są zautomatyzowane w naszym systemie testowym).

Liczba napisanych testów jest bezużyteczna, a duża liczba znalezionych błędów może być miernikiem słabego rozwoju, a nie wydajnej kontroli jakości.

Środki automatyzacji (pokrycie kodu, pokrycie funkcji ...) mogą być dobre, ale myślę, że są bardziej pomocne w rozwoju (jako programista, czy będę wiedział, jeśli coś przypadkowo popsuję) niż klienci (chcę to zrobić i to nie działa).

Ponieważ jakość jest dobra, jeśli klienci nie napotykają problemów, dobrą miarą skuteczności (a nie wydajności) zespołu i procesu kontroli jakości jest miara błędów wykrytych przez klientów, których nie wykryła QA .

Głównym problemem związanym z tą miarą jest to, że pomiędzy wykonaną pracą a rozpoczęciem znaczących liczb może wystąpić znaczne opóźnienie.

Istnieje kilka wskaźników, które wykorzystaliśmy w mojej ostatniej pracy do oceny jakości:

• Liczba znalezionych błędów. Nienawidzę tego. To jest jak „liczba napisanych wierszy kodu” dla programisty.
• Liczba wyprodukowanych automatycznych przypadków testowych.
• Procent całkowitej liczby aplikacji objętych testami funkcjonalnymi.
• Liczba błędów znalezionych podczas inscenizacji i produkcji.

Ostatecznie zadaniem twojego zespołu QA jest znalezienie błędów, zanim wyjdą na wolność. Ich wskaźniki powinny opierać się na faktycznym osiągnięciu tego celu. Jeśli liczba przypadków testowych jest niska, minimalna liczba testów automatycznych i duża liczba błędów w produkcji, to nie wykonują oni dobrej roboty. Jednak jeśli mają dobre wyniki w wykrywaniu błędów na długo przed trafieniem w prod, ich wskaźniki powinny być dość wysokie.

Kontrola jakości powinna być mierzona dwoma głównymi wskaźnikami: ile błędów minęło, gdy można je znaleźć w terenie? Jakie są ich nasilenie?

Być może uda ci się sprawdzić QA za znalezienie poważnych błędów bliżej wydania niż dev-complete. Być może uda Ci się sprawdzić jakość za nieukończenie testów przed ich szacunkową datą ukończenia (według funkcji).

Obawiam się jednak, że wydasz więcej pieniędzy, próbując zmierzyć efektywność swoich pracowników kontraktowych, niż oszczędności uzyskane dzięki zatrudnieniu pracowników kontraktowych ...

Firma, w której pracuję, korzysta z wielu wskaźników jakości.

Ten, który wydaje mi się najbardziej odpowiedni, to pokrycie kodu. Narzędzie takie jak EMMA działa świetnie, ponieważ oprócz testów ręcznych piszą dokładne testy automatyczne.

Cokolwiek robisz, nie koncentruj się na liczbie testów. Jest to tak samo przydatne jak LOC dziennie.

Wiele sposobów pomiaru wydajności w fazie programowania i testowania podczas realizacji projektu. W naszych projektach zastosowaliśmy poniższe środki. Wydajność programistyczna mierzona za pomocą 4 popularnych wskaźników kodu (wskaźnik utrzymania, złożoność cyklometryczna, głębokość dziedziczenia, sprzężenia klasowe). Dla C # dostanie to w Microsoft Visual Studio. Do pokrycia testów bardzo użyteczne jest Ncover / Ndepend. Testowanie wydajności mierzone liczbą błędów programistycznych - przewijanie przez ostatnie 4 sprinty Systemowe testowanie błędów przewijających się przez ostatnie 4 sprinty. Liczba testów automatyzacji nie przeszła w konkretnej wersji / dostarczonych funkcjach.