We don't test to find out if something works, we test to find out if it doesn't work.

"Dzień dobry,

piszę od razu jak zauważyłem, że coś nie działa w tej nowej wersji. Bo zapomniałem hasła i wtedy okazało się, że nie da się nowego wpisać. Sprawdzałem dzisiaj na moim iPhonie, zapomniałem hasła, a chciałem się zalogować. Jak wpisałem swojego maila, potem dałem nie pamiętam hasła i wtedy nie miałem możliwości wpisania nowego hasła. Znowu pokazała się strona z logowaniem. 

Proszę o sprawdzenie tego błędu."

To nie jest przykład wymyślony przeze mnie, ba! To jest samo życie.

Od strony praktycznej tak to właśnie wygląda. Większość z Was przeczyta tony dokumentacji o testowaniu, później jeszcze więcej o praktyce testowania, o teoretycznej części, o praktycznej, godziny nauki, tygodnie praktyki i dostaje powyższego maila...

Z perspektywy czasu, takie maile lubię najbardziej, bo tak naprawdę, to nie wiadomo o co chodzi, ale jak się przypatrzeć to wszystko jest napisane.

piszę od razu jak zauważyłem, że coś nie działa w tej nowej wersji.

Pierwsza informacja- najnowsza wersja, wystarczy sprawdzić build aplikacji, który został wypuszczony niedawno i mamy odpowiedź na jedno z pytań scenariusza zgłaszania błędów z wcześniejszego wpisu.

Sprawdzałem dzisiaj na moim iPhonie,

Następna informacja- system- iOS.

Bo zapomniałem hasła i wtedy okazało się, że nie da się nowego wpisać.

Cały błąd kończy i zaczyna się w tym miejscu. Mamy informację, że nie da się wygenerować nowego hasła. Wystarczy teraz udać się na stronę logowania aby sprawdzić co dokładnie się dzieje. Nigdy nie będzie tak, że błąd podany przez klienta będzie pięknie rozpisany, będzie zawierał wszystkie szczegóły itp. To MY jesteśmy od tego! Ten krótki wpis dodałam, aby nie rozpisywać się o konieczności posiadania testerów w firmie, o tym, jaki to wspaniały zawód, że wymaga dużo pracy, to wszystko każdy powinien ocenić według siebie. Napisałam go, aby pokazać Wam trochę praktycznej strony testowania, trochę z przymrużeniem oka :-)