Piramida testów w praktyce (notatki z dyskusji)

1. 0
5
10
15
20
25
30
35
nie nie dotyczy tak
Czy w Twojej pracy developerzy piszą testy (jakiekolwiek)?
Czy w twojej pracy developerzy piszą testy (jakiekolwiek)? Liczba oddanych głosów %
nie 12 20
nie dotyczy 17 28
tak 31 52

2. DB WS GUI
- ilość i jakość zwróconych wyników
- sortowanie
- paginacja
- zwracane http codes
- security (kto ma dostęp, czy można w URL endpointa
podstawić jakieś zmienne itp.)
- komunikaty, gdy produkt nie zostanie znaleziony
Aplikacja webowa wyświetlająca
zawartość magazynu
Co chcemy
przetestować?

3. Podsumowanie dyskusji – poruszane kwestie
• Odwrócenie proporcji piramidy testów skutkuje bardzo długimi test suitami
(wolno wykonujące się testy UI)
• Narzędzia do automatyzacji systemów desktopowych: AutoIT, TestStack/White,
skrypty Powershell, Squish, Inspect
• Czasem developerzy tworzą tylko testy unitowe, testerzy testy UI
• Kto i jak powinien robić review testów unitowych pisanych przez developerów
• Czy tester ma wiedzę co i jak dokładnie jest pokryte unit testami?
• Wstrzykiwanie błędów jako weryfikacja, czy testy w ogóle wykrywają błędy
• Eksploracja manualna z otwartą konsolą – pokazuje błędy w tle, które
niewidoczne są w UI

4. Podsumowanie dyskusji – poruszane kwestie
• Czy testy security bywają trudne dla mniej technicznych osób
• Czasami za testy security odpowiadają dedykowane osoby lub zespoły
• Ważna jest edukacja zespołów developerskich z zagadnień security
• Niekorzystna tendencja do wykonywania wszystkich testów funkcjonalnych jako
superuser
• Podczas performance testów dobrze jest mieć wsparcie adminów i pełnego
dostępu do logów i statystyk
• Którymi testami warto podzielić się z developerami