blog.testowka.pl

No i gdzie ta jakość?

opublikowany przez 16, Lut, 2011, w kategoriach Agile, Testowanie, Zarządzanie

Złapałem się na tym, że ostatnimi czasy piszę głównie o zarządzaniu projektami, agile, procesach wytwarzania oprogramowania itp., a coraz mniej skupiam się na testowaniu. W podtytule tego bloga jak zapewne zauważyliście jasno jest napisane: „Blog o jakości oprogramowania”. Gdzie ta jakość?

Odpowiedź jest prosta – wszędzie. To, że skupiam się głównie na procesach wytwarzania oprogramowania, zarządzania tymże wytwarzaniem oprogramowania oraz aspektach bardziej miękkich z tym związanych wynika z tego, iż doszedłem do wniosku, że szukanie bugów jest bez sensu. Tak! (Jak ja lubię strzelać sobie zawodowego samobója – najpierw, że testerzy są niepotrzebni, teraz, że szukanie błędów jest bez sensu…). Testowanie oprogramowania nie tworzy żadnej wymiernej wartości w projektach informatycznych, wynika to między innymi z tego, że jakości samej w sobie nie da się zmierzyć – często ciężko jest nawet zdefiniować jakość. Znalezione błędy muszą być poprawione – i przeważnie zostają poprawione, po czym powinny zostać sprawdzone i dopiero wtedy produkt może ujrzeć światło dzienne, ot i cała filozofia.

Błędy kosztują – wszyscy doskonale o tym wiedzą, ale większość komentarzy skupia się na kosztach błędów, które nie zostały wykryte. Warto czasem spojrzeć na temat z drugiej strony – znalezione błędy też kosztuję. Każdy znaleziony błąd wymaga opisania, zgłoszenia, debugownia, poprawienia oraz ponownego sprawdzenia, do tego dochodzą jeszcze inne zróżnicowane w zależności od projektu i innych czynników czynności takie jak oczekiwanie na zbudowanie nowej paczki czy mergowanie zmian. To wszystko zajmuje pewną ilość czasu, a jak powszechnie wiadomo czas to pieniądz.

Skoro już wiemy, że znalezione błędy też kosztują i wiemy ile kosztują to zastanówmy się co zrobić by zmniejszyć koszty. Najprostsze rozwiązanie – nie popełniać błędów. Istnieje wiele teorii na temat tego skąd biorą się błędy, większość z nich ma wspólne elementy takie jak np. „to człowiek jest źródłem błędów”, „niepełne wymagania powodują błędy”, „ograniczona wiedza i możliwości technologiczne zwiększają prawdopodobieństwo powstawania wad”, „coraz większe skomplikowanie projektów powoduje wzrost prawdopodobieństwa pojawienia się błędów, wynikający z większej ilości możliwych scenariuszy użycia” itd.. Próbując znaleźć najprostsze rozwiązanie dochodzę, do wniosku, iż kluczem do osiągnięcia sukcesu w tym przypadku jest skupienie się na procesie i zarządzaniu tymże procesem. Zapobieganie błędom jest dużo tańsze niż ich wykrywanie i poprawianie – nie wspomnę już nawet o tym, że jeszcze droższe jest nie znalezienie błędów i ich niepoprawienie.

Dlatego właśnie ostatnio moje myśli i poszukiwania skupiają się wokół zarządzania projektami i zapewniania jakość a nie weryfikacji jakości jaką jest testowanie oprogramowania samo w sobie.

Mam to szczęście (a może właśnie pecha), że podczas swojej stosunkowo krótkiej (kilka lat) „kariery” w IT, miałem okazje pracować z kilkoma bardzo różnymi zespołami i uczestniczyć w wielu bardzo zróżnicowanych projektach dzięki czemu mam spory zasób doświadczeń na podstawie których mogę wyciągać trafne (czytaj: „sprawdzające się w praktyce”) wnioski.

Jeśli zadbamy o jakość od samego początku i każdy z członków zespołu (a także klient, zarząd etc.) będzie zaangażowany w zapewnianie jakości to możemy być pewni, iż ta inwestycja się nam zwróci.

Zapytacie pewnie o liczby, dane, w jaki sposób mogę zagwarantować, że tak właśnie jest? Nie mogę niczego zagwarantować – nie da się tego zbadać doświadczalnie, nie można zmierzyć ile pieniędzy czy czasu zaoszczędziliśmy dzięki podejściu skupiającemu się na jakości. Musicie mi uwierzyć na słowo – to działa. Zresztą nie tylko ja tak uważam. Jak pogooglujecie, poczytacie książki na temat testowania oprogramowania, zarządzania projektami etc. sami prędzej czy później dojdziecie do podobnych wniosków.

W jaki sposób dbać o jakość? Odpowiedzi są na wyciągnięcie ręki – czytajcie tego bloga, a także szukajcie innych. Ludzie i ich doświadczenia to najlepsze źródła wiedzy. Dzielcie się swoją wiedzą i przemyśleniami po to by je zweryfikować i skonfrontować z przemyśleniami innych. Na prawdę warto!


1 Comment for this entry

  • Adam Hepner

    Błędy nieznalezione kosztują, znalezione też kosztują – wydawałoby się, że to błędne koło :). Całe jajo polega na tym, żeby koszt testowania prewencyjnego (z szacowaną ilością znalezionych defektów)był dużo mniejszy od kosztów potencjalnej naprawy nieodkrytych defektów. Ot, risk-based testing. Dlatego nie da się przetestować wszystkiego, dlatego priorytetyzuje się testy.

    I dlatego nie poprzestaje się na jednym rodzaju testów – TDD, czy BDD nie są receptą na całe zło. Exploratory testing też nie. Trzeba to wszystko z głową łączyć.

    Pozdrawiam!

Skomentuj