test scenario vs test case
Różnica między scenariuszem testowym a przypadkiem testowym.
6 lat temu Podczas pracy ze średniej wielkości MNC, kiedy zasugerowałem dokumentowanie scenariuszy testowych zamiast tracenia czasu na przygotowanie pełnego dokumentu sprawdzającego zwanego przypadkami testowymi, wszystkie głowy zwróciły się do mnie z irytacją.
Wyraz twarzy jasno wskazywał, że sugerując to popełniłem duży błąd. Chociaż nikt nie zaprzeczył pomysłowi, nikt nawet go nie zaakceptował. Wszyscy uważali, że podążanie za tradycją, czyli pisanie dokumentów testowych, będzie bezpieczniejsze. Nie mogłem się kłócić.
Po 4 latach firma otrzymała projekt testowy, w którym jedynym ograniczeniem był czas, a jedynym oczekiwaniem był pełny dowód testowanie.
Byliśmy ponownie na spotkaniu i omawialiśmy pomysły na dotrzymanie krytycznego terminu. Aplikacja polegała głównie na wyszukiwaniu i generowaniu różnych raportów poprzez różne pozycje menu. Dokumentowanie przypadków testowych miało najczęściej przechwytywać i nie byliśmy pewni, ile dokument zostanie wykorzystany przez klienta.
Zaproponowałem udokumentowanie scenariuszy testowych i jakoś z pewnym wahaniem wszyscy się zgodzili. Nie trzeba wspominać, że mogliśmy zaoszczędzić cenny czas dokumentacji i wykorzystać go do testów.
Czego się nauczysz:
- Czy przypadki testowe są szybko zastępowane scenariuszami testowymi?
- Kiedy dokumentacja przypadków testowych jest ważna?
- Różnice między scenariuszem testowym a przypadkiem testowym w formacie tabelarycznym
- Wniosek
- rekomendowane lektury
Czy przypadki testowe są szybko zastępowane scenariuszami testowymi?
Z biegiem czasu, ponieważ wszystko się zmienia, przemysł oprogramowania i procesy również bardzo się zmieniły.
zrobić tymczasowy fałszywy adres e-mail
Tradycyjny Wodospad i Modele V. są zastępowane przez modele zwinne i iteracyjne. Dokumentacja jest konieczna ale aby dotrzymać terminów i uczynić proces łatwym i przejrzystym, można zmienić sposób dokumentacji.
Kiedy dokumentacja przypadków testowych jest ważna?
- Klient poprosił o to samo w ramach projektu.
- Nie ma ograniczeń czasowych (nie sądzę, żeby to było możliwe).
- Testery są świeższe lub nieznane produktowi.
- Polityka firmy (wierzę, że można ją zmienić).
Podzielę się z wami jednym doświadczeniem:
Ja i mój zespół byliśmy zaangażowani w testowanie projektu firmy z listy Fortune 500 z elastycznymi ramami czasowymi. Udokumentowaliśmy przypadki testowe najlepszym dostępnym szablonem i uzyskaliśmy akceptację klienta.
Gdy kompilacja zaczęła być udostępniana zespołowi ds. Kontroli jakości, przez większość dnia naszym obowiązkiem było mechaniczne śledzenie 100 przypadków testowych dziennie, aktualizowanie dokumentu z wynikiem pozytywnym / negatywnym i wysyłanie go do klienta na koniec dnia. Większość członkowie zespołu zaczęli narzekać monotonna praca ale firma generowała dochody.
Potem była jednodniowa przerwa bez nowej kompilacji do przetestowania. Na początku dnia siedzieliśmy razem i rozmawialiśmy o tym, co będziemy robić na ten dzień. Kiedy zaproponowałem wygenerowanie większej liczby pomysłów, aby ulepszyć dokument przypadku testowego, wszyscy członkowie zespołu zaprzeczyli, że podjęli wysiłki.
Według nich nie było już o czym myśleć, ponieważ omówiliśmy wszystkie scenariusze. I przekonanie ich do tego myśl po wyjęciu z pudełka i generuj więcej pomysłów był naprawdę ciężki.
W większości przypadków, gdy dokumentujemy przypadki testowe, a także po zatwierdzeniu przez klienta, ludzki umysł myśli, że wykonaliśmy swoją pracę i nasz umysł automatycznie przestaje rozważać wszelkie próby zastanowienia się nad innymi sposobami przetestowania produktu.
I uwierz mi, kiedy dokument przypadków testowych jest przygotowywany, chcemy po prostu postępować zgodnie z nim mechanicznie. Powiedz mi, ile razy w swojej karierze doświadczyłeś, że Ty lub kolega z zespołu oferowaliście dodatkowe przypadki testowe do zatwierdzonego dokumentu przypadków testowych?
Jeszcze jedno doświadczenie:
Podczas cotygodniowych wyzwań zespołowych ogłosiliśmy aplikację i poprosiliśmy członków zespołu o przedstawienie scenariuszy testowych.
Wszyscy członkowie zespołu, w tym osoby spóźnione lub niereagujące, zgłaszały pomysły. Czemu? Nie było formalnej dokumentacji, w której musieliby wypełnić oczekiwany wynik dla każdej sekwencji funkcjonalności i warunku wstępnego dla każdego przypadku testowego. Zebraliśmy 40 scenariuszy testowych w jeden dzień i to było wspaniałe doświadczenie.
Aby sprzyjać mojemu doświadczeniu, Chciałbym przedstawić przykład.
Weź przykładową aplikację, powiedzmy stronę logowania z nazwą użytkownika, hasłem, loginem i przyciskami anulowania. Jeśli poprosimy o napisanie przypadków testowych dla tego samego, w końcu napiszemy ponad 50 przypadków testowych, łącząc różne opcje i szczegóły.
Ale jeśli scenariusze testowe zostaną zapisane, będzie to kwestia 10 linii, jak poniżej:
Scenariusz wysokiego poziomu: Funkcjonalność logowania
Scenariusze niskiego poziomu :
1. Aby sprawdzić, czy aplikacja się uruchamia
2. Aby sprawdzić zawartość tekstową na stronie logowania
3. Aby sprawdzić pole Nazwa użytkownika
4. Aby sprawdzić pole Hasło
5. Aby sprawdzić przycisk logowania i anulować działanie przycisku
Zobacz też=> Ponad 180 przykładowych scenariuszy testowych do testowania aplikacji internetowych i komputerowych.
Ponieważ wszystkim brakuje czasu, scenariusze testowe działają raczej jak spray przeciwbólowy niż stary IODEX. A jednak efekt jest ten sam.
Różnice między scenariuszem testowym a przypadkiem testowym w formacie tabelarycznym
Na koniec chciałbym podsumować różnicę między scenariuszem testowym a przypadkiem testowym:
Przypadki testowe | Scenariusze testowe | |
---|---|---|
Co to jest => | Pojęcie, które dostarcza szczegółowych informacji, co należy przetestować, jakie kroki należy podjąć i oczekiwany rezultat | Pojęcie, które dostarcza jednowierszowych informacji o tym, co testować. |
Chodzi o => | Chodzi bardziej o dokumentowanie szczegółów. | Chodzi bardziej o myślenie i omawianie szczegółów. |
Znaczenie => | Jest to ważne, gdy testowanie odbywa się poza bazą, a programowanie odbywa się na miejscu. Pisanie przypadków testowych ze szczegółami pomoże w synchronizacji zarówno deweloperów, jak i zespołu ds. Kontroli jakości. | Jest to ważne, gdy czasu jest mniej i większość członków zespołu może uzgodnić / zrozumieć szczegóły ze scenariusza jednowierszowego. |
Zaleta => | Jednorazowa dokumentacja wszystkich przypadków testowych jest przydatna do śledzenia 1000 rund testów regresji w przyszłości. W większości przypadków jest to pomocne przy zgłaszaniu błędów. Tester musi tylko podać numer identyfikacyjny przypadku testowego i nie musi wspominać o najdrobniejszych szczegółach. | Działanie oszczędzające czas i generujące pomysły, preferowane przez społeczność testerów oprogramowania nowej generacji. Modyfikacja i dodawanie jest proste i nie dotyczy konkretnej osoby. W przypadku dużego projektu, w którym grupa ludzi zna tylko określone moduły, ta aktywność daje każdemu szansę przyjrzenia się innym modułom, burzy mózgów i dyskusji |
Korzystne dla => | W pełni sprawdzający dokument przypadku testowego to linia życia dla nowego testera. | Dobre pokrycie testów można osiągnąć dzieląc aplikację na scenariusze testowe, co zmniejsza powtarzalność i złożoność produktu |
Wada => | Zajmuje czas i pieniądze, ponieważ wymaga więcej zasobów, aby szczegółowo określić, co i jak testować | Jeśli zostało utworzone przez określoną osobę, recenzent lub inny użytkownik może nie zsynchronizować dokładnej idei, która się za nim kryje. Potrzebujesz więcej dyskusji i pracy zespołowej. |
Wniosek
Przypadki testowe są najważniejszą częścią cyklu życia oprogramowania i bez nich trudno jest coś śledzić, rozumieć, śledzić i wymyślać. Ale w erze Agile przypadki testowe są szybko zastępowane scenariuszami testowymi.
sql pytania do rozmów z programistami na 2-3 lata doświadczenia
Powszechny lista kontrolna testów dla każdego typu testowania (testowanie baz danych, testowanie GUI, testowanie funkcjonalności itp.) w połączeniu ze scenariuszami testowymi to nowoczesna artyleria dla testerów oprogramowania. Dyskusje, szkolenia, pytania i ćwiczenia mogą zdecydowanie zmienić ostateczny wykres Twoja produktywność a także macierz raportów błędów.
Jak zwykle czekamy na Twoje przemyślenia i pytania. Włącz się.
POPRZEDNIA samouczek | NEXT Tutorial
rekomendowane lektury
- Różnica między planem testów, strategią testów, przypadkiem testowym, skryptem testowym, scenariuszem testowym i warunkami testowymi
- Rodzaje testowania oprogramowania: różne typy testów ze szczegółami
- Jak pisać przypadki testowe: najlepszy przewodnik z przykładami
- Jak przeglądać dokument SRS i tworzyć scenariusze testowe - Szkolenie z testowania oprogramowania w projekcie na żywo - Dzień 2
- Jak klasyfikować pozytywne i negatywne scenariusze testów - ściągawka testera
- Testy wydajnościowe a testy obciążeniowe a testy obciążeniowe (różnica)
- Testowanie statyczne i testowanie dynamiczne - różnica między tymi dwoma ważnymi technikami testowania
- 101 Różnice między podstawami testowania oprogramowania