Tomasz D.

Tomasz D. test entrepreneur

Temat: Wymagania

Aktualnie wszedłem w okolicę, gdzie nie zaczynamy niczego jeśli nie mamy spisanych wymagań, a testujemy tylko i wyłącznie rzeczy, które mamy wymienione w wymaganiach. Osobiście się z tym nie zgadzam, ale poniewaz niekoniecznie to ja muszę mieć rację chciałem zasięgnąć opinii osób doświadczonych w temacie.

A pytanie jest takie :
Czy powinniśmy zacząć testowanie (testowanie jako jakiekolwiek czynności testowe, niekoniecznie wykonywanie testów; mowa o testach systemowych), jeśli nie mamy udokumentowanych wymagań.
Łukasz K.

Łukasz K. powrot do biegania

Temat: Wymagania

a co macie?
bo testowanie bez zadnego dokumentu to chyba nie ma sensu, w koncu skad macie wiedziec czy jest ok czy tez raczej nie?:)
Dariusz P.

Dariusz P. Wdrażanie i
zarządzanie
innowacją w
korporacjach, m.in.
R...

Temat: Wymagania

Tomasz D.:
Aktualnie wszedłem w okolicę, gdzie nie zaczynamy niczego jeśli nie mamy spisanych wymagań, a testujemy tylko i wyłącznie rzeczy, które mamy wymienione w wymaganiach.

1) Testujesz nowe oprogramowanie? To na podstawie czego ono powstało skoro nie ma wymagań?

2) Testujesz istniejące oprogramowanie, do którego do tej pory nie było spisanych wymagań? Jeżeli tak to tutaj pewnie można się oprzeć o wiedzę osób, które z tego oprogramowania korzystają w codziennej pracy.

Pozdr,
DP.
Tomasz D.

Tomasz D. test entrepreneur

Temat: Wymagania

Oprogramowanie jest nowe lub istniejące, ale modyfikowane. Są wymagania ogólne (powiedzmy takie high level), ale niekoniecznie oficjalnie zatwierdzone w oficjalnym dokumencie. Są wymagania "zbierane" z maili, etc.

Czy zaczynamy tworzyć przypadki testowe jak mamy jakąkolwiek wiedzę o systemie czy dopiero jak mamy detailed wymagania?

Łukasz K.:
a co macie?
bo testowanie bez zadnego dokumentu to chyba nie ma sensu, w koncu skad macie wiedziec czy jest ok czy tez raczej nie?:)

No właśnie. Powiedzmy, że aplikacją do testów jest sklep internetowy (najlepszy do teoretycznych przykładów ;) do którego nie ma żadnych wymagań konkretnych. Ale wiem, że powinien mieć możliwość logowania, przeglądania asortymentu, etc. Wiem jak ogólnie powinien wyglądać, wiem jak ogólnie powinny wyglądać przypadki testowe (część z nich). Nie mam wymagań, ale wiem czy pewne rzeczy sa ok, czy raczej nie.
Michał K.

Michał K. Quality Assurance
Engineer

Temat: Wymagania

Tomasz D.:
Nie mam wymagań, ale wiem czy pewne rzeczy sa ok, czy raczej nie.

,,PEWNE RZECZY''

Powiem tak jeśli brać pod uwagę ze chcesz ,,sprawdzić'' tylko te pewne rzeczy to logicznie myśląc po co wymagania :) Jednak wówczas sprawdzasz nie testujesz inaczej mówiąc dbasz żeby było JAKOŚ natomiast JAKOŚĆ wciąż jest gdzieś tam w oddali.

Należy się dobrze zastanowić dla kogo ten sklep internetowy.

Jak wysoka jakość produkty chcecie zagwarantować i ile masz czasu bo przygotowanie dobrej specyfikacji wymagań trochę trwa.
Teoretycznie najczęściej używane ostatnio modele wytwarzania oprogramowania (lekkie) odchodzą od obowiązku tworzenia gór dokumentów jednak specyfikacja wymagań znacznie ułatwia prace i wciąż jest wykorzystywana.

Można by było cały wykład zrobić dlaczego testowanie bez tego dokumentu mija się z celem nie o to tu chodzi patrząc jednak po pytaniu które zadałeś to nie brak dokumentacji ale brak osoby QA która wie po co się ja tworzy jak ja wykorzystać stanowi podstawowy problem .

Dariusz P.:
Tomasz D.:
2) Testujesz istniejące oprogramowanie, do którego do tej pory nie było spisanych wymagań? Jeżeli tak to tutaj pewnie można się oprzeć o wiedzę osób, które z tego oprogramowania korzystają w codziennej pracy.

Tutaj by mozna było pomyśleć raczej co zrobić zęby z Chaosu zrobić kontrolowany chaos i przynajmniej na podstawie tej wiedzy stworzyć taka dokumentacje bo biorąc tylko jeden z pechowych w takiej sytuacji scenariuszy :) w przyszłości któraś z tych osób co tak to znają odejdzie i będzie trzeba znowu coś zmodyfikować to kogo się spytasz ?

Poza tym skąd masz pewność ze osoby używające tej aplikacji codziennie pewnych błędów już nie traktują jak błędy bo najzwyczajniej w świecie sie do nich przyzwyczaiły.Michał Koza edytował(a) ten post dnia 28.05.09 o godzinie 09:19

konto usunięte

Temat: Wymagania

Tomasz D.:
Oprogramowanie jest nowe lub istniejące, ale modyfikowane. Są wymagania ogólne (powiedzmy takie high level), ale niekoniecznie oficjalnie zatwierdzone w oficjalnym dokumencie. Są wymagania "zbierane" z maili, etc.

Czy zaczynamy tworzyć przypadki testowe jak mamy jakąkolwiek wiedzę o systemie czy dopiero jak mamy detailed wymagania?

Jeśli tylko jest taka możliwość, to chyba warto tworzyć testy jak najwcześniej.

Po pierwsze: już coś będzie istniało, mniej roboty na później.

Po drugie, tworząc testy zrewidujemy już te pierwsze szczątkowe informacje na temat systemu. Czasem przy tworzeniu testów rodzi się tyle pytań bez odpowiedzi, że wymagane jest przemyślenie podstawowych założeń aplikacji, co lepiej jest robić jak najwcześniej, prawda?
Tomasz D.

Tomasz D. test entrepreneur

Temat: Wymagania

Michał Koza:
Tomasz D.:
Nie mam wymagań, ale wiem czy pewne rzeczy sa ok, czy raczej nie.

,,PEWNE RZECZY''

Powiem tak jeśli brać pod uwagę ze chcesz ,,sprawdzić'' tylko te pewne rzeczy to logicznie myśląc po co wymagania :) Jednak wówczas sprawdzasz nie testujesz inaczej mówiąc dbasz żeby było JAKOŚ natomiast JAKOŚĆ wciąż jest gdzieś tam w oddali.

Czy w którymś miejscu napisałem, że chcę sprawdzać tylko "pewne rzeczy"? Aż przeczytałem jeszcze raz swoją wypowiedź... i JAKOŚ nie zauważyłem... ;)
Jak wysoka jakość produkty chcecie zagwarantować i ile masz czasu bo przygotowanie dobrej specyfikacji wymagań trochę trwa.

Chyba nie sugerujesz, że przygotowanie dokumentacji wymagań to zadanie testera?

OK. Teraz będzie prosto i dużymi literami.

Do przetestowania jest aplikacja (na potrzeby naszej dyskusji uznajmy, że jest to sklep internetowy). Nie ma specyfikacji wymagań, bo klient stwierdził, że ma być sklep. Załóżmy, że projekt jest real life, czyli zdanie klienta co do tego co ma być w takim sklepie zmienia się średnio trzy razy na dobę. I przy okazji całego procesu powstawania oprogramowania idzie request do testera "masz to przetestować". Jak dla mnie są dwa podejścia. Albo biedny tester zabiera się do roboty pracując z tym co ma (nawet średnio inteligentny makak potrafi wymyśleć jak maja działać podstawowe funkcje sklepu internetowego), a w dalszych krokach, gdy wiadomo więcej, aktualizuje co trzeba. Ewentualnie siedzi dłubiąc w nosie (lub przeglądając wiadomości na sieci) czekając aż powstanie dokument z wymaganiami i dopiero wtedy zabiera się do pracy. Żadne podejście nie jest jedyne słuszne, z wielu względów, ale które według was jest słuszniejsze? Ewentualnie co pominąłem.

Osobiście wyznaję stanowisko podobne do Agaty, ale jestem ciekawy jakie są plusy dłubania w nosie ;)
Łukasz Berezowski

Łukasz Berezowski
http://www.wookashbe
rezowski.com/

Temat: Wymagania

"Osobiście wyznaję stanowisko podobne do Agaty, ale jestem ciekawy jakie są plusy dłubania w nosie ;) "

Plusy wynikające z oczekiwania na coś bardziej konkretnego niż "sklep". Jest brak marnowania czasu na pisanie czegoś, co może się do czegoś nadać, bądź nie.

W dużych machinach testowych, gdzie testuje wiele osób lub/i jest testowanych w pewnych cyklach wiele projektów. Czas na zabawy w dziurce można zastąpić pracą przy innych projektach, o których wiadomo więcej niż, to, że się pojawią. A pracę na budowę skryptów, scenariuszy wykorzystać wtedy, gdy są już dokumenty na których można pracować.

Pozdrawiam,
J.
Łukasz K.

Łukasz K. powrot do biegania

Temat: Wymagania

a jak nie wiadomo nic konkretnego na temat zadnego z projektow? jak mija wlasnie 3 rok projektu, development ma byc skonczony w czerwcu, wdrozenie we wrzesniu a do przeszkolenia jest 6000 userow (kazdy min 1-2 dni), gora chcialaby pochwalic sie swojej gorze testami automatycznymi (funkcjonalne) a docelowy interfejs pojawi sie za 4 tygodnie?:)

to jest zycie, to o czym piszesz to jest piekna teoria, ale ja sie z nia nigdy nie spotkalem...
Krystian K.

Krystian K. Agile Coach, Autor

Temat: Wymagania

Tomasz D.:
Albo biedny tester zabiera się do roboty pracując z tym co ma (nawet średnio inteligentny makak potrafi wymyśleć jak maja działać podstawowe funkcje sklepu internetowego), a w dalszych krokach, gdy wiadomo więcej, aktualizuje co trzeba. Ewentualnie siedzi dłubiąc w nosie (lub przeglądając wiadomości na sieci) czekając aż powstanie dokument z wymaganiami i dopiero wtedy zabiera się do pracy.

Makak może przestać dłubać w nosie i pobawić się w Exploratory Testing ucząc się systemu i jako wymagania brać referencję do znanych powszechnie rozwiązań np.: osCommerce w tym wypoadku, czy Amazon.com lub doświadczenia z poprzednich projektów. W ten sposób możemmy znaleźć już jakieś błędy logiczne\display\security, stworzyć też listę wątpliwości na których można zbudować wymagania pytając klienta\Business Ownera.
Jest to też bardziej higieniczne\estetyczne rozwiązanie niż dłubanie w nosie ;)

Następna dyskusja:

wymagania + kryteria akcept...




Wyślij zaproszenie do