Temat: testowanie funkcjonalne - sposoby podejścia - gdzie poczytać

Witam,
trochę staram się interesować (noo.. powiedzmy, że na polu nauki) tematyką tworzenia testów akceptacyjnych funkcjonalności oprogramowania.

Czy może spotkaliście się ze skondensowaną wiedzą (case studies, jakieś ciekawsze analizy) jak podchodzić do tworzenia przypadków/scenariuszy testowych?

Ciekaw też jestem jak się ma w praktyce testowanie funkcjonalności na podstawie (zdefiniowanych wcześniej i obustronnie zaakceptowanych) scenariuszy w porównaniu do testowania funkcjonalności "na żywioł", czyli użytkownik dostaje dostęp do środowiska testowego i to co na nim wyczynia to już sprawa fantazji, a potem tylko zgłasza co mu się wydaje usterką czy brakiem..
Może jakieś publikacje na ten temat? opracowania?

Z góry dzięki
PW

Temat: testowanie funkcjonalne - sposoby podejścia - gdzie poczytać

Paweł Wiśniewski:
Witam,
trochę staram się interesować (noo.. powiedzmy, że na polu nauki) tematyką tworzenia testów akceptacyjnych funkcjonalności oprogramowania.

Czy może spotkaliście się ze skondensowaną wiedzą (case studies, jakieś ciekawsze analizy) jak podchodzić do tworzenia przypadków/scenariuszy testowych?

Ciekaw też jestem jak się ma w praktyce testowanie funkcjonalności na podstawie (zdefiniowanych wcześniej i obustronnie zaakceptowanych) scenariuszy w porównaniu do testowania funkcjonalności "na żywioł", czyli użytkownik dostaje dostęp do środowiska testowego i to co na nim wyczynia to już sprawa fantazji, a potem tylko zgłasza co mu się wydaje usterką czy brakiem..

W jakim sensie?

Może jakieś publikacje na ten temat? opracowania?

Są publikacje: Software Testing, Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional

Temat: testowanie funkcjonalne - sposoby podejścia - gdzie poczytać

Krystian K.:

Paweł Wiśniewski:
Witam,
trochę staram się interesować (noo.. powiedzmy, że na polu nauki) tematyką tworzenia testów akceptacyjnych funkcjonalności oprogramowania.

Czy może spotkaliście się ze skondensowaną wiedzą (case studies, jakieś ciekawsze analizy) jak podchodzić do tworzenia przypadków/scenariuszy testowych?

Tutaj chodzi mi o to jakie są reguły postępowania przy konstrukcji przypadków sprawdzania (i zapewniania odbiorcy oprogramowania), że dana funkcja oprogramowania realizuje swoje cele...
Branie najczęstszego/średniego przypadku, branie przypadków "przełączających" ścieżki użycia? Jak określać kryterium ilości przypadków na funkcję (bo przecież jedną funkcję oprogramowania można testować akceptacyjnie do końca świata)?

Ciekaw też jestem jak się ma w praktyce testowanie funkcjonalności na podstawie (zdefiniowanych wcześniej i obustronnie zaakceptowanych) scenariuszy w porównaniu do testowania funkcjonalności "na żywioł", czyli użytkownik dostaje dostęp do środowiska testowego i to co na nim wyczynia to już sprawa fantazji, a potem tylko zgłasza co mu się wydaje usterką czy brakiem..

W jakim sensie?

Moją ciekawość najlepiej zaspokoiłaby tabelka, np w stylu:
przedsięwzięcie, budżet, ilość miesięcy realizacji zakładana, ilość miesięcy rzeczywista, liczba osobodni zespołu budującego, liczba osobodni zespołu testującego, sposób podejścia do testowania (scenariusze/żywioł), rozmiar funkcjonalny systemu zakładany (FP czy nawet ilość ekranów/raportów itp.), rozmiar funkcjonalny uzyskany,... może jeszcze jakieś ciekawe informacje..

Na podstawie czegoś takiego odpowiedziałbym sobie czym charakteryzują się owe różne podejścia do testowania.. przynajmniej w jakimś zakresie.. :)

Może jakieś publikacje na ten temat? opracowania?

Są publikacje: Software Testing, Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional

Podejście Pattona opiera się, o ile pamiętam (bo tylko przez jakiś czas miałem tą (tzn polskie wydanie z 2001 czy 2002) książkę w zasięgu), właśnie o doświadczenie własne i o prostą logikę, która nie daje weryfikowalnej wiedzy, o którą mi chodzi. To trochę podręcznik, trochę zbiór rad.
Spróbuję jakoś uzyskać do dostęp do tej drugiej. Mam nadzieję, że będzie to pozycja, która nie działa na podstawie prawdy objawionej (autorom) a są tam jakieś konkretne doświadczenia, na podstawie których autorzy dokonali twierdzeń o efektywności i wydajności.

Dzięki
pozdrawiam

Temat: testowanie funkcjonalne - sposoby podejścia - gdzie poczytać

Paweł Wiśniewski:

>

Ciekaw też jestem jak się ma w praktyce testowanie funkcjonalności na podstawie (zdefiniowanych wcześniej i obustronnie zaakceptowanych) scenariuszy w porównaniu do testowania funkcjonalności "na żywioł", czyli użytkownik dostaje dostęp do środowiska testowego i to co na nim wyczynia to już sprawa fantazji, a potem tylko zgłasza co mu się wydaje usterką czy brakiem..

Hejże Pawle.

Chyba sam odpowiedziałeś sobie na swoje pytanie... jeżeli nadal nie widzisz różnicy to może wyobraź sobie poszukiwanie min przez kogoś z mapą pola minowego i kogoś z informacją "tam jest pole minowe, idź i znajdź 20 min" ;)

Wydaje mi się, że testowanie "na żywioł" jak to nazwałeś ma swoje zalety - ale wszystko zależy tu od doświadczenia użytkownika, który takie testy przeprowadza. Rzekłbym, że ogólnie jest to śliska sprawa: testerzy będą zgłaszać rzeczy, które nie są błędami (tak jak napisałeś "sprawa fantazji" (lub doświadczenia)), nie przetestują tego co powinni (skupią się na tym co będzie dla nich najłatwiejsze bądź najważniejsze), może być im trudno zreprodukować akcje prowadzące do błędów, etc. Oczywiście jeżeli takie testy są wykonywane przez osobę znającą się dobrze na testach oraz na testowanym produkcie (czyli w tym szaleństwie jest metoda ;)) sprawa może wyglądać całkowicie odwrotnie -- zamiast jechać przez 300 scenariuszy testowych taka osoba opierając się na swoim doświadczeniu będzie w stanie w kilku ruchach znaleźć ważne błędy.

Jeżeli o mnie chodzi to odwołałbym się do takich testów w kilku
przypadkach i na bardzo określonych warunkach:

- mało czasu na przygotowanie przypadków testowych
- mało czasu na testy a testerzy nie są zaznajomieni z produktem
(uczą się go w trakcie testów)

Oczywiście testerzy powinni rejestrować swoje działania w formie przypadków testowych. Do tego muszą mieć dostęp do wymagań/opisu systemu, żeby wiedzieć, że to co widzą ma sens. Najlepiej, żeby był do konsultacji ktoś kto zna system.

- jako metoda uzupełniająca uporządkowane testy (wstępna weryfikacja dostarczonego oprogramowania, eksperckie testy UAT) ale w tym wypadku przeprowadzałyby to osoby znające produkt

Nie mam żadnych "twardych danych". Poszukaj sobie czegoś na temat 'ad hoc testing' i 'exploratory testing'.

Pozdr,
DP.Dariusz P. edytował(a) ten post dnia 27.03.09 o godzinie 13:49

Temat: testowanie funkcjonalne - sposoby podejścia - gdzie poczytać

Dariusz P.:
[CIACH!]

Generalnie zgadzam się ze wszystkim co napisałeś.
To nie jest tak, że tego nie widzę, skoro zgadzam się - to mam tożsamy pogląd (a skoro go mam to coś widzę :-) ) na te kwestie..

Ale co innego, żebym mógł to udowodnić (bo pogląd to nie weryfikowalna wiedza)...

Nie mam żadnych "twardych danych".

Szkoda :-( właśnie najbardziej to tego szukam :-)

Poszukaj sobie czegoś na temat 'ad hoc testing' i 'exploratory testing'.

Dzięki - naprawdę nie wiem jak mogłem do tego wcześniej nie dotrzeć..

Pozdr,
DP.Dariusz P. edytował(a) ten post dnia 27.03.09 o godzinie 13:49

pozdrawiam

Temat: testowanie funkcjonalne - sposoby podejścia - gdzie poczytać

wedlug mnie najlepiej swoja strategie testowania "obgadac" z business analitykiem (lub inna osoba ktora ma dobra wiedze businessowa twojej aplikacji). powinien zwrocic Ci uwage na najwazniejsze aspekty funkcjonalne aplikacji ktora testujesz. ja tak do tej pory robilem i dosc dobrze sie to sprawdzalo. dla mnie to jest optymalne rozwiazanie pod warunkiem ze taka osoba w Twoim projekcie jest :)

pozdr