Była metafora szarlotki do testowania a zarządzania jakością. To może teraz serniczek? Żarcik – jeszcze nie wiem, jaka będzie metafora i czy w ogóle jakaś się napatoczy.

Co było najpierw? Testowanie czy debugowanie (kura czy jajko)? W słowie „debugowanie” jest sławetny „bug”, więc po polsku tłumaczylibyśmy je jako „odrobaczanie” i dokładnie to oznaczało pierwotnie, kiedy to bugi były niczym innym jak robaczkami włażącymi do sprzętu i psującymi programy. Najlepiej zachowany, martwy obecnie robal wlazł między kable i Grace Hopper znalazła go bez żadnych testów – po prostu oprogramowanie nie zadziałało, więc szukała przyczyny. Można więc powiedzieć, że debugowanie jednak jest jajem.

No to dlaczego testerzy i programiści stosują te dwa pojęcia i jeszcze będą głośno protestować, że programiści to nie są od testów, a testerzy nie są od debugowania, skoro oba wyrazy wiążą się z szukaniem i usuwaniem błędów? Dlaczego nie mówią po prostu, że debugują/testują jedni i drudzy? To może po kolei.

Kto?

Mimo woli zdradziłam różnicę. Testują testerzy, debugują programiści. Testerzy mogą co najwyżej debugować kod swoich automatów, co zresztą robią. Testów zwykle jednak nie testujemy.

Co?

Testujemy w zasadzie wszystko. Możemy testować specyfikację, analizę, wymagania. Możemy sobie dokumentację testować, szukając błędów logicznych, merytorycznych czy ortograficznych (testy statyczne). Zasadniczo jednak testujemy oprogramowanie. Może być w całości, mogą być jakieś jego części, pojedyncze funkcjonalności (zwykle dynamicznie jednak). A co debugujemy? Kod. Nie debugujemy niczego innego. Możemy go debugować nawet wtedy, gdy mamy coś, co jeszcze nie działa, nie wygląda, czego się jeszcze nie da uruchomić. I to są władni robić jedynie programiści, którzy potrafią kod czytać i rozumieć. Albo umio w debugery.

Jak?

Testować może każdy, kto poznał założenia projektu. Testują użytkownicy (choć nie w usystematyzowany sposób, jak powinni robić to profesjonaliści). Oczywiście, że przeciętny korzystacz z aplikacji do zamawiania taksówek nie będzie się skupiał na aspektach technologicznych – to będzie działka wykwalifikowanego testera. Ale zauważy literówkę, rozjechane menu czy to, że apka wywala mu się zawsze, kiedy coś kliknie.

A debugują tylko programiści. Nie muszą być autorami kodu, ale muszę go rozumieć. No i oczywiście – muszą mieć do niego dostęp – zwyczajowo testerzy dostępu do kodu raczej nie mają. Programiści mają do debugowania odpowiednie narzędzia (debugery właśnie), często zaszyte zgrabnie w środowisko pracy. Ale mogą zwyczajnie czytać kod i w ten sposób znaleźć błąd. Jeśli nie wiesz, czym jest zmienna i czym się różni od właściwości, czym jest metoda, obiekt, pole itd. raczej nie znajdziesz błędu w tym (C#):

public int Polacz(int dwa, string dwaString)
 {
    int dwa = 2;
    string dwaString = " = dwa";
    return String.Concat(dwa, dwaString)
 }

Dobra, przyznajmy się – to najgłupszy kod, jaki kiedykolwiek wyszedł spod mojej ręki (a konkurencja jest niemała). Każdy, kto miał coś wspólnego z programowaniem, od razu pokaże tu błąd na błędzie, a kto nie miał, ale zna memy o programistach, powinien znaleźć choć jeden. Oczywiście każde szanujące się środowisko, w które to wkleimy (czyli w tym wypadku VisualStudio), będzie podkreślać na czerwono, świecić żarówkami i wręcz krzyczeć. No masz! Odbiegłam od tematu.

Kiedy?

Jak powiedziałam – testować można różne produkty procesu powstawania oprogramowania. Jest jeden warunek – powinny być skończone lub przynajmniej w końcowej fazie. Debugujemy zaś dopiero, kiedy mamy kod do tego debugowania się nadający. Ale – to mogą być raptem dwie linijki, a nawet linijka kodu. I to jest takie koło. Programista zdebuguje swój kod przed oddaniem testerowi (zwłaszcza jak mu się nie skompiluje), tester przetestuje to, co dostał, a jak znajdzie awarię, to programista znów będzie debugował w poszukiwaniu błędu.

Wnioski?

Testowanie de facto nie jest usuwaniem błędów (choć lubimy tak sobie myśleć), a znajdowaniem awarii lub defektów. Na podstawie zgłoszenia testerskiego to deweloper (programista) jest w stanie błąd znaleźć i usunąć.

No i nie było zabawnej metafory, bo testy serniczka wykazały jego doskonałość i cóż – nie było czego debugować.