Redakcja
Radek Smilgin
Śmieszny obrazek o teorii i praktyce, który zapewne wiele osób zna, ma następujący tekst:
Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined: nothing works and nobody knows why.
Każdy, kto pracował w różnego rodzaju laboratoriach, czy konkretnie w "laboratoriach" wytwarzania oprogramowania wie, że powyższe zbyt często jest prawdziwe. Możemy więc całego mema przerobić na specyfikę IT.
Theory of software development is when you know everything but nothing works.
Practice of software development is when everything works but no one knows why.
In IT, theory and practice are combined: nothing works and nobody knows why.
Czyli w wolnym tłumaczeniu:
Teoria wytwarzania oprogramowania jest wtedy, gdy wiesz wszystko, ale oprogramowanie nie działa.
Praktyka wytwarzania oprogramowania jest wtedy, gdy wszystko działa, ale nikt nie wie dlaczego.
W IT teoria spotyka się z praktyką: nic nie działa i nikt nie wie dlaczego.
Co ciekawe, tezy postawione w tym memie są potwierdzeniem pewnych reguł, które znamy z testowania oprogramowania.
Teoria testowania
Oprogramowanie zawsze ma niemożliwą do określenia liczbę defektów. Teoria testowania mówi, że:
- testowanie jest nieskończone,
- liczba defektów w oprogramowaniu jest nieznana,
- ile byśmy nie testowali to i tak nie uda nam się potwierdzić, że wszystkie defekty zostały znalezione.
Można to sprowadzić do stwierdzenia, że gdy znasz teorię testowania to wiesz, że oprogramowanie nigdy nie działa (w pełni) poprawnie.
Praktyka testowania
Uruchomienie testów pozwala nam potwierdzić, że w danym obszarze oprogramowanie działa poprawnie i to pomimo tego, że wiemy, że ogólnie musimy założyć, że w oprogramowaniu musi się znajdować przynajmniej jeden defekt więcej niż dotychczas znaleźliśmy.
Tester czarnoskrzynkowy uruchamiając oprogramowanie może potwierdzić, że "działa", ale nie mając wiedzy o konstrukcji oprogramowania, nie wie dlaczego działa.
Teoria i praktyka testowania
Tester oprogramowania nie musi znać przyczyn źródłowej awarii. Według teorii testowania tester może raportować defekty oprogramowania nie znając ich źródła. Sprowadza nas to do wniosku, że w momencie kiedy znajdowane są defekty o statusie "bloker" nic nie działa i (jeszcze) nikt nie wie dlaczego.
PS Oczywiście na samym końcu projektu często jako zespół doprowadzimy do sytuacji, że jednak "działa". :)
