Temat: Testlink - scenariusze testowe

Mam pytanie
Czy istnieje możliwość skonfigurowania testlinka tak, aby poziom weryfikacji scenariusza testowego zagęścić do kroków scenariusza.
Testlink umożliwia weryfikację scenariusza jako całości, a co jeśli na 10 kroków 2 nie działają 1 działa a reszta działa, ale warunkowo ? Czy można tak skonfigurować narzędzie, abym mógł zaznaczyć wyniki testu pojedynczego kroku? Jeśli tak to jak ?

Temat: Testlink - scenariusze testowe

Mateusz L.:

Wydaje mi się że nie
Ale możesz inaczej zaprojektować testy dzieląc sobie na Test Suite Operations annie na test casy

w test case'ie tak naprawdę powinieneś mieć kroki do wykonania pojedynczego zadania

no bo to testcase w końcu :D

Temat: Testlink - scenariusze testowe

Mateusz L.:
Czy istnieje możliwość skonfigurowania testlinka tak, aby poziom weryfikacji scenariusza testowego zagęścić do kroków scenariusza.

Nie sądzę. TestLinka - moim zdaniem - od strony wbudowanego w niego modelu dobrze przemyślano i nie bez powodu jest, jak jest.

Mateusz L.:
Czy można tak skonfigurować narzędzie, abym mógł zaznaczyć wyniki testu pojedynczego
kroku? Jeśli tak to jak ?

Mozna na upartego dodać "custom field" na "Test Execution" typu "Failed at step"... albo dopisywać w Execution Notes.

Rezultat per "test step" wymagałby modyfikacji kodu (co w TL dla dostatecznie zmotywowanych, przeszkodą nie jest... ;) )

Mateusz L.:
Testlink umożliwia weryfikację scenariusza jako całości, a co jeśli na 10 kroków 2 nie działają 1 działa a reszta działa, ale warunkowo ?

Tzn. że przypadek testowy nadaje się do wymiany. Moim zdaniem, i jak sądzę w duchu PDFa dostarczanego w podkatalogu /doc/ w TestLinku wynik wykonanego scenariusza testowego może być GO / NO GO. Nie ma znaczenia, na którym kroku jest pad - scenariusz nie przechodzi, CBDO.

Poza tym, jakoś ta warunkowość mi się nie podoba...

Temat: Testlink - scenariusze testowe

Zgadzam się z przedmówcami. Kroki scenariusza testowego powinny następować po sobie sekwencyjnie. Tzn. wykonanie kolejnego kroku może się odbyć dopiero po zaspokojeniu kryteriów wyjścia kroku poprzedzającego (zwykle osiągniecie na wynikiu oczekiwanych rezultatów).
Sytuacja, w której coś takiego mogło by być potrzebne to np. budowa przypadku testowego przypominająca check-listę, np.
krok 1 :
sprawdzić czy system X, zwraca 5,
krok 2:
sprawdzić czy podsystem Y zwraca 4
krok 3:
sprawdzić czy serwis Q, zwraca wartość "prawda".

Z tym, że w takim wypadku TestLink nie jest najwygodniejszy w użyciu bo i nie do tego został stworzony.

Chyba lepiej już było by stworzyć ogólny przypadek testowy który w jednym "kroku" zawierałby wszystkie wymagane sprawdzenia, czyli bazując na ww. przykładzie:
Krok 1:
sprawdzić czy system X, zwraca 5 oraz sprawdzić czy podsystem Y zwraca 4, oraz sprawdzić czy serwis Q, zwraca wartość "prawda".
Krok 2:
.....
Krok 3:
....
itd.

Wtedy przynajmniej wyniki takiego testu są jednoznaczne (wiemy już, że coś nie działa wg. założeń, ale dalej nie wiemy dokładnie co). To powinno nam zasugerować, że być może
potrzebujemy rozbić ten przypadek testowy na kilka bardziej szczegółowych.

Patrząc z innego punktu widzenia:
Podczas automatyzacji takich przypadków testowych w momencie nie możliwości "przejścia" jednego z kroków, test powinien zakończyć się failem. W przeciwnym wypadku jaki miałby być status takiego scenariusza? Pass czy Fail (najbardziej pasowałby xUnitowy Inconclusive:)? I czy jeżeli nawet arbitralnie uznasz jedną z tych odpowiedzi za prawidłową w takim wypadku, to czy jest to informacja użyteczna ?Ten post został edytowany przez Autora dnia 04.03.14 o godzinie 22:57