7 Zasad testowania oprogramowania
Czy wiesz drogi czytelniku co to w ogóle jest testowanie oprogramowania i czy tak naprawdę jest konieczne?
Mnie na myśl przychodzi, że słowo testowanie to nic innego jak sprawdzenie czegoś oraz czy jego funkcjonalność jest zgodna z moimi oczekiwaniami. Należy brać pod uwagę to, że nim coś trafi do testowania to przechodzi przez kilka etapów. Cały proces może mieć kilka faz takich jak: planowanie, projektowanie, analiza, wykonanie, implementacja oraz ocena wyników.
Oprogramowanie to już nieodzowny element naszej codzienności. Już nie tylko komputery mają oprogramowanie, ale i nasze telefony, telewizory, samochody i wiele innych przedmiotów ogólnego zastosowania. Obecnie technologia tak poszła do przodu, że z pozycji własnego telefonu możemy otworzyć samochód, zapalić w nim światła czy chociażby namierzyć jego lokalizację. To, co kilka lat temu wydawało się utopią, dziś jest codziennością. Różnego rodzaje oprogramowania otaczają nas z każdej strony, są dostępne w wielu dziedzinach życia i nie unikniemy dalszej digitalizacji i rozwijającej się technologii no, chyba że wyjedziemy na drugi koniec świata i zaszyjemy się w głębokiej dżungli. Wracając do głównego tematu, przypomnij sobie drogi czytelniku, ile raz twój telefon, komputer, telewizor wywinął Ci psikusa i się zawiesił? Albo przestał działać zgodnie z twoimi oczekiwaniami? Zakładam, że nie raz ulubiona strona internetowa wyświetliła Ci komunikat 500 Internal Server Error i nie było to zbyt atrakcyjne. Wiąże się to z wieloma dodatkowymi problemami, startą czasu, pieniędzy i innymi niedogodnościami. W niektórych podręcznikach o testowaniu można znaleźć stwierdzenie, że oprogramowanie ulega awarii bądź usterce z winy czynnika ludzkiego oraz pomyłek programistów. To, że tzw. “bug” wychodzi spod ręki programisty nie zawsze oznacza ze to jego wina. Również tester nie sprawi, że nagle wszystkie usterki zostaną wychwycone i naprawione, ale jeśli testy zostaną dobrze zaplanowane i przeprowadzone to zmniejszone zostanie ryzyko wystąpienia “bugów”.
Każdy tester na początku swojej ścieżki zawodowej poznaje 7 podstawowych zasad, które powinien zastosować w swojej pracy
- Testowanie ujawnia błędy — jakkolwiek to interpretować to testowanie ma ujawnić właśnie usterki, a nie ich braki. Jeśli podczas wykonywania testów otrzymuje się inny wynik od założonego można domniemywać, że istnieje jakiś problem. Może to dotyczyć samego programu jak i całej dokumentacji, a wtedy należy przeprowadzić dokładną analizę problemu i odpowiednią ją zaraportować. Czy jeśli testy nie zwrócą błędów to jest równoznaczne, z tym że oprogramowanie jest idealne? Zdecydowanie nie, najprawdopodobniej istnieje błąd, którego nie wykryły testy. Oczywiste jest, że testowanie redukuje ryzyko błędów, ale nie jest dowodem na to, że sama aplikacja jest całkowicie wolna od defektów.
- Nie da się przetestować wszystkich możliwych kombinacji — nawet najlepszy tester na świecie nie jest w stanie tego zrobić szczególnie w złożonej aplikacji, gdzie istnieje wiele zależności i różnych rozwiązań.
- Im szybciej zaczniesz testowanie, tym lepiej — tak szybko jak to tylko możliwe. Tak naprawdę proces testowy powinien się rozpocząć już podczas analizy wymagań. Nawet jeśli nie powstała jeszcze żadna linia kodu pisanego przez programistów. Test plan czy pierwsze testy mogą być tworzone jeszcze w pierwszym etapie podczas gdy zespół analizuje wymaganie względem aplikacji. Dlaczego? Otóż kluczowym faktem jest to, że analizy pokazują, że koszt naprawy błędów rośnie z czasem tzn., jeśli zostanie wychwycony we wczesnej fazie projektu będzie on kosztował firmę mniej niż naprawianie tej samej usterki na produkcji. Nie warto zatem odkładać fiksowania błędów na później.
- Błędy często się kumulują — w testowaniu obowiązuje zasada 80/20 to znaczy 20% przyczyn odpowiada za 80% skutków, czyli w tym przypadku należy przyjąć, że 80% błędów znajduje się tylko w 20% modułów aplikacji, a błędy kumulują się w jednym miejscu. Jeśli tester zna dobrze aplikację i dobrze zorganizował proces testowy to szybko odnajdzie te części produktu, które wymagają najwięcej uwagi i wykryje sporą ilość błędów.
- Paradoks pestycydów — w testowaniu również znajduje zastosowanie. Tak samo jak w uprawie stosuje się pestycydy, aby pozbyć się szkodników tak samo działa to w przypadku testów i ich skuteczności podczas testowania. Jeżeli będziemy wykonywać wciąż te same testy bez żadnych zmian to będą wykrywać te same błędy, a potem przestaną wykazywać je w ogóle. Zupełnie jak w stosowaniu pestycydów, kiedy wciąż są używane te same środki hodowla się na nie uodparnia i preparaty przestają działać. Aby uniknąć tego zjawiska testy, zestawy testów i przypadki testowe powinny być systematycznie sprawdzane i modyfikowane.
- Ważny kontekst — każdy przypadek jest inny i różne czynniki mają wpływ na jego kształt. Inaczej będzie testowana aplikacja mobilna, inaczej webowa a jeszcze inaczej aplikacja oparta o Machine Learning. Innego podejścia wymaga aplikacja dedykowana ograniczonemu gronu użytkowników a zupełnie inaczej dla szeroko dostępnej, którą w dowolnej chwili każdy może pobrać z Internetu. Wszystkie decyzje dotyczące kształtu całego procesu testowego zależą od kontekstu, zatem poziom testów też będzie różny. Czasem może zdarzyć się również tak, że to sam klient zobliguje nas do tego, aby testy odbyły się w ściśle określonych warunkach. Dość trudne jest zdefiniowanie dobrego procesu testowego dlatego też należy być bardzo elastycznym, ale jednocześnie bardzo uważnym, bo to, co sprawdzi się w aplikacji A nie koniecznie znajdzie zastosowanie w aplikacji B i odwrotnie a skutki mogą być katastrofalne.
- Fałszywe przekonanie o braku błędów — generalnie użytkownika końcowego wcale nie interesuje jak były prowadzone testy, jego interesuje efekt końcowy, czyli działający program. Podczas prowadzonych testów koniecznie trzeba pamiętać o tym, że aplikacja nie była tworzona z myślą o nas (testerach), ale o użytkownikach. Nawet jeśli przeprowadzimy tysiące testów, powstaną super raporty nie mamy gwarancji, że produkt spełnia oczekiwania i wymagania użytkowników, bo po co klientowi coś, co nie działa albo będzie zupełnie bezużyteczne.
Jak już wcześniej wspomniano tester nie ma możliwości przetestowania wszystkiego i tu z pomocą przychodzi mu wyznaczenie priorytetów. Należy je ustawić w taki sposób, aby niosące największe ryzyko były wykonane w pierwszej kolejności, do takich które mogą być wykonane później. Dzięki temu nawet jeśli z jakiegoś powodu trzeba będzie wcześnie zakończyć testy to kluczowe części aplikacji będę już przetestowane. Kolejnym etapem sugerującym ukończenie testów są metryki. Można zmierzyć niezawodność systemu liczbą znalezionych defektów, stopniem pokrycia wymagań, naprawionymi defektami itd. Jeśli w trakcie testowania znajdowanych jest relatywnie mało błędów może świadczyć o tym, że albo mamy wysokiej jakości oprogramowaniem, albo o złym procesie testowym. Jeśli uda nam się wykluczyć drugi wariant to znaczy, że powstało oprogramowanie o doskonałej jakości.
Other entries
Słowniczek pojęć internetowych cz.2
Dziś dalsza część słowniczka pojęć związanych z pojęciami internetowymi, które są używane codziennie, a mogą być nie do końca nam znane. Digitalizacja — to cyfrowa postać, która jest nadawana pismom i dokumentom zawartych na nośnikach danych. E- administracja...
Słowniczek pojęć internetowych cz.1
W XXI w. prawie każdy i to bez względu na to, ile ma lat, codziennie siada do komputera, laptopa czy innego urządzenia, gdzie w szerokim zakresie może korzystać z Internetu. Ktoś skończył szkołę czy uczelnie o profilu informatycznym, ktoś inny zdobył wiedzę na kursach...
Na jakich stanowiskach pracują programiści?
Intensywny wzrost nowych technologii sprawia, że również stanowiska pracy w branży IT ewoluują w ogromnym tempie. Autorzy oprogramowania wpływają już praktycznie na każdy aspekt naszego życia. Firmy o różnym profilu, coraz częściej sięgają po nowoczesne rozwiązania...