Redakcja
Podstawowa reguła testowania mówi, że jeśli coś może pójść nie tak, to na pewno pójdzie. Im wcześniej rozpoczniesz testy w procesie tworzenia oprogramowania, tym większe szanse, że coś się spektakularnie "wysypie". Jeśli natomiast właśnie uruchomiasz pierwszy test na systemie, to spodziewaj się stuprocentowej gwarancji poważnej awarii. Jednak awarie, defekty czy wyjątki, nie powinny Cię w żadnym przypadku zaskakiwać.
Wielorakość sposobów, na jakie system może nie działać, prezentujemy na przykładzie stworzonego przez Informatyka Zakładowego opisu działania modułu "Dostawca Tożsamości".
https://twitter.com/InfZakladowy/status/1379904109432692742/photo/1
A działa on zgodnie z tabelką poniżej:
Patrząc na to testerskim okiem, możecie zadać sobie pytanie, co mogłoby pójść nie tak? Podsuwamy więc 6 przykładów, spośród niezliczonych możliwych scenariuszy.
1. Usługi nie ma
2. Dostawca przeciążony
3. Usługa się zresetowała
4. Dostawca się wypiera
5. Usługa się myli
6. Usługa kończy przedwcześnie
Istnieje również technika projektowania testów, bazująca na defektach, która zachęca do takiego budowania swoich testów, aby pokrywać typowe czy też popularne awarie w systemach.
Dlaczego testerzy powinni zastanawiać się nad tym, co może się popsuć? Powodów jest wiele, a do najważniejszych należy sprawdzenie, jak funkcje systemu zachowają się po pojawieniu się awarii. Nie możemy się jednak ograniczyć jedynie do funkcji i należy pamiętać, że są jeszcze charakterystyki jak np. wydajność, w których również mogą pojawić się awarie.
