Testowaniem oprogramowania zajmuję się od ponad trzech lat. Od początku mojej przygody z tą dziedziną IT pracuję w Gdańsku, w firmie zajmującej się produkcją systemów bazodanowych. Brałem jak dotąd udział w 4 projektach: aplikacje webowe (.NET/Oracle, php/mySQL) oraz programy typu clients (VBA, C++/Sybase).
Kwalifikacje zawodowe - znajomość technik, metodologii i standardów testowania i tworzenia dokumentacji (IEEE Std 829-1998, BS 7925-1, BS 7925-2) oraz metod wytwarzania oprogramowania, podstawy SQL, HTML. ISEB Foundation Certificate in Software Testing. Praktyczna znajomość narzędzi typu open source/freeware oraz komercyjnych wspomagających proces testowania i zarządzania nim (m.in. OpenSTA, Test Maker, Test Case Manager, Allpairs, Test Log, MI Astra Load Test, MI Astra Quick Test, MI Astra Site Manager).
Kiedy zawiesza się program konkurencji, to jest awaria. Kiedy zawiesza się własny program, to jest "drobiazg". Często pojawia się komunikat typu "ID 02". "ID" to skrót od "idiotyczny drobiazg", a następująca po nim liczba wskazuje, przez ile jeszcze miesięcy produkt informatyczny powinien być testowany.
Guy Kawasaki, "The Macintosh Way"
Wytwarzane obecnie oprogramowanie staje się coraz bardziej złożone i coraz trudniej jest sprawić, aby było niezawodne. Niezależnie od tego jak dobrzy będą programiści i jak bardzo będą się starać, błędy pojawią się zawsze. Na pozór nie brzmi to groźnie - wszak niedoskonałości zdarzają się wszędzie, lecz jeśli weźmiemy pod rozwagę fakt, iż coraz więcej kluczowych dziedzin naszego życia zależy od oprogramowania, a historia zna przypadki, w których ceną zapłaconą za przeoczenie błędów (często z uwagi na brak testowania) były miliony dolarów, a nawet ludzkie życie, powinniśmy traktować tę fazę produkcji oprogramowania z należytą powagą.
Ponadto, testowanie jest jedną z metod oceny jakości oprogramowania oraz dostarcza cenne informacje o ryzyku, związanym z produktem.
Celem procesu testowania oprogramowania jest wykrywanie błędów, a właściwie wykrywanie tych błędów jak najwcześniej, ponieważ koszt ich naprawy jest tym większy, im później zostaną znalezione. Wzrost kosztów może być gwałtowny, zwiększać się nawet dziesiątki razy wraz z upływem czasu. Błąd znaleziony na wczesnym etapie, np. w czasie specyfikowania wymagań, można często naprawić niemal za darmo. Ten sam błąd znaleziony w czasie testowania gotowego już programu kosztuje o wiele więcej.
Testować należy jak najwcześniej, ponieważ podstawowymi źródłami błędow są specyfikacja i projekt.