efektywne testowanie z metodą dziel i rządź
Efektywne testowanie metodą dziel i rządź

W dzisiejszym artykule spróbuję przedstawić, jak w efektywny sposób możemy weryfikować dane, za pomocą metody dziel i rządź. Wiedza na temat tego jak zastosować tą metodę testowania może być przydatna podczas wyceny czasochłonności zadań. W sytuacji gdy zostaniemy poproszeni o podanie czasu potrzebnego na testy.

Zgodnie z Wikipedią dziel i rządź to sposób projektowania algorytmów, w wyniku której otrzymujemy efektywne rozwiązania.

„W strategii tej problem dzieli się rekurencyjnie na dwa lub więcej mniejszych podproblemów tego samego (lub podobnego) typu, tak długo, aż fragmenty staną się wystarczająco proste do bezpośredniego rozwiązania.”

źródło Wikipedia

Przykładowe zadanie dla testera

Wyobraźmy sobie aplikację, której pierwszą wersją produkcyjną była wersja 1.0. Numer każdej kolejnej wersji był zwiększany o 1.0 aż do wersji 20.0. Oznacza to, że w historii działania produkcyjnego mieliśmy w sumie 20 wersji od 1.0 do 20.0. Dla uproszczenia przyjmujemy, że klient nie dostawał żadnych poprawek do wersji (nie było więc produkcyjnych wersji aplikacji o numerze 1.5, 11.3 itd. itp. ). Po wdrożeniu na produkcję wersji 20.0 klient zgłasza błąd. Błąd dotyczy nieprawidłowego przeliczania zaokrąglenia kwoty do dwóch miejsc po przecinku. Klient podejrzewa, że błąd mógł już występować we wcześniejszych wersjach aplikacji i chce wiedzieć, od której wersji wystąpił.
Zadaniem naszym, testerów jest znalezienie tej wersji.

Wyszukiwanie metodą liniową

Wyszukiwanie możemy wykonać „liniowo”, czyli reprodukujemy kroki błędu na kolejnych wersjach począwszy od 20.0 (na której wiemy, że błąd występuje), następnie 19.0, 18.0 itd. Czynność powtarzamy, aż trafimy na wersję, w której błąd nie wystąpił.

W tym wypadku mamy minimum 2, a maximum 20 weryfikacji do wykonania. Dwie w przypadku, gdy błąd jest tylko na 20.0 wersji, dwadzieścia, gdy występuje na wersji 1.0 lub 2.0.

Testy wykonane metodą dziel i rządź

Efektywniejszym sposobem weryfikacji, na której wersji aplikacji błąd występuje, może być zastosowanie wyszukiwania algorytmem dziel i rządź (albo dziel i zwyciężaj). W tym wypadku odtworzenie błędu może wyglądać następująco.

Krok 1

Zaczynamy od podzielenia wersji na dwa zbiory. Wersje 1.0 do 10.0 oraz 11.0 do 20.0. Weryfikujemy, czy błąd można powtórzyć na wersji 10.0. Tak można go powtórzyć. To znaczy, że w wersjach 10.0 do 20.0 błąd występuje.

krok1 metoda dziel i rządź
Krok 1: metoda dziel i rządź
Krok 2

W kolejnym kroku zbiór wersji 1.0 do 10.0 dzielimy na dwa mniej więcej równe podzbiory. Weryfikujemy, czy błąd występuje na wersji 5.0 i widzimy, że nie występuje. Oznacza to dla nas tyle, że musimy zweryfikować wystąpienie błędu na wersjach 6.0 do 10.0.

Krok 2: metoda dziel i rządź
Krok 3

Dzielimy zbiór na dwa podzbiory i reprodukujemy kroki testowe dla wersji 8.0. Błąd występuje dla wersji 8.0.

krok 3 metoda dziel i rządź
Krok 3: metoda dziel i rządź
Krok 4

W wyniku retestu błędu na wersji 7.0 otrzymujemy, że nie występuje on na tej wersji.

Tak więc w czterech krokach odnaleźliśmy wersję, od której błąd zaczął występować. Gdybyśmy zastosowali liniowe sprawdzanie, wówczas musielibyśmy dokonać reprodukcji błędu na 15 wersjach aplikacji.

Zanim jednak przystąpiłbym do sprawdzenia wersji 10 z pierwszego kroku, zacząłbym od weryfikacji wersji 20.0. Dlatego, że czasami zdarza się, że defekt zgłoszony przez klienta nie jest realnym defektem w aplikacji. Wówczas jeżeli faktycznie występuje taki błąd, zacząłbym szukać dalej zgodnie z opisanym powyżej przykładem. Miałbym zatem nie 4 a 5 kroków weryfikacji. Co i tak jest znacznie mniejszą liczbą niż 15.

Czy zatem zawsze powinniśmy stosować tą metodę?

Oczywiście tak jak już wspomniałem, może się też okazać, że wystarczą 2 weryfikacje wyszukiwania liniowego, by mieć wyniki. O tym jaki algorytm użyć do tego typu testu może decydować nie tylko to jak często jeden algorytm jest lepszy od drugiego, ale też nasza intuicja. Jako testerzy możemy domyślać się, od której wersji błąd mógł wystąpić i w ten sposób ograniczyć wyszukiwanie w wersjach od np. 11.0.
W wielu moich artykułach podkreślałem jak istotny jest czas przy wytwarzaniu oprogramowania – nasz czas to pieniądz a poprawa naszej wydajności jest bardzo istotna! 🙂

Waldemar Szafraniec

Nazywam się Waldemar Szafraniec. Karierę testera rozpocząłem w 2012 roku. Od początku pracy w zawodzie wiedziałem, że będzie to coś więcej niż tylko praca. Obecnie praca jest również moim hobby. Jednym z moich obowiązków w obecnym miejscu pracy jest rekrutowanie nowych testerów oraz szkolenie ich. Sam stale podnoszę swoje kwalifikacje uczestnicząc w szkoleniach (ISTQB, ISTQB Advanced Level – Test Analyst). Szkolę ludzi w dziedzinie testów manualnych od 2014 roku. Jestem trenerem, ponieważ wiem, że dobrze mi wychodzi przekazywanie wiedzy, wiem jak praca testera wygląda oraz mam doświadczenie w rekrutacji.

Dodaj komentarz

Zamknij