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.
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 3
Dzielimy zbiór na dwa podzbiory i reprodukujemy kroki testowe dla wersji 8.0. Błąd występuje dla wersji 8.0.
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! 🙂
