Redakcja
W poprzednim artykule opisaliśmy zawartość raportu z testów. Jakie powinien mieć cechy?
Aby raport był czytelny, musimy odpowiedzieć sobie dla kogo ma być czytelny? Jedną z głównych cech testera oprogramowania jest umiejętność komunikowania się z innymi członkami zespołu. Jeśli raport ma być dla nich zrozumiały, powinniśmy dostosować jego zawartość do ich poziomu zrozumienia.
- Biznes i kierownik projektu będzie wymagał raportu jednoznacznie i szybko wskazującego na jakość oprogramowania
- Programista będzie wymagał informacji na temat pojedynczych problemów, a całościowy obraz będzie dla niego ważny.
Przemek napisał do redakcji maila z propozycją cech dobrego raportu dla testów automatycznych. Propozycję obrobiliśmy i oto naszym zdaniem cechy dobrego raportu (niekoniecznie tylko testów automatycznych):
- Spójność - jednakowe miary i metryki w całym raporcie oraz ich jednakowa (jednoznaczna) interpretacja
- Czytelność - graficzne wizualizacje z opisem i przejrzyste tabele
- Jednoznaczność - wyniki 2-3 stanowe, np. przeszło, nie przeszło, nieuruchomione
- Łatwość rozpowszechnienia i prezentacji - format ogólnie dostępny i łatwy w edycji, np. html (plik wiki), xls, ppt
- Informacja z testów - czy jest dobrze czy źle? Czytelna informacja dostępna "na pierwszy rzut oka"
- Podsumowanie całości wyników w nagłówku z odpowiednią kolorystyką lub elementami graficznymi np. kciuk w górę, uśmiechnięta buźka
- Łatwość porównania z poprzednimi wynikami testów - tabele porównawcze
- Wsparcie do dalszej analizy wyników - wynikające również z formatu danych.
Przemek S. zasugerował również, że raport z testów automatycznych może być napisany w języku kodowym (nieczytelnym dla osób z biznesu), ale trzeba go umiejętnie przetransformować w czytelny raport. Dobrą notacją w takim przypadku będzie wygenerowany plik XML, który po poddaniu szybkiej obróbce można przetworzyć na dowolny "office'owy" język biznesu.
