🚀 go-pugleaf

Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości 
news:f2bn06

> Tak. Właśnie po to, żeby tester miał odniesienie do rzeczywistego 
> przypadku
> użycia, tzn. takiego z jakim będzie pracował użytkownik, a nie takiego
> niedopracowanego z początku zastanawiania się "co to my chcemy zrobić".

nie znajduję w tym odpowiedzi na zacytowane przez ciebie moje pytanie/a, być 
może będe musiała sprecyzować je inaczej. Natomiast poproszę o rozwinięcie 
tego, co napisałeś, gdyż co rozumiem dotąd z tego, to truizm, iż PU powinien 
być aktualny i wystarczająco szczegółowy, by służył za podstawę miarodajnego 
testu.
Innymi słowy nie zajmujemy się tym , czy PU jest 'rzeczywisty' 
(świeży/kompletny/ukończony/odzwierciedla docelowe wymaganie) - w 
postawionym przeze mnie problemie istotne jest to, że PU jako dokument 
wymagań f. będzie podstawą do testy systemowego (/ akceptacyjnego), podczas 
gdy PU jako dokument rozwiązań byłby podstawą dla wytworzenia jakiegoś testu 
rozwiązania (zapewne typu biała-skrzynka), i nalezy to literalnie 
rozdzielić, nazwać i nie mieszać pod żadnym pozorem, ale może ja źle 
rozumuję?

(że nie wspomnę poprzednio wypowiedzianej wątpliwości - jaki niby test mam 
utworzyć na podstawie PU dokumentującego zarówno funkjonalność jak i 
rozwiązania?)


ps:
Może się mylę, ale jeśli to, co chcemy zrobić zmienia się po zrobieniu tego, 
znaczy że robimy coś innego. Wymaganie nie powinno ulec zmianie z powodu 
jego realizacji (bądź powinno ulec walidacji w iteracyjnym procesie).