3. O czym jest
mowa w tej
książce?
Tester i jego rola w zespole
Techniki testowania
Zgłaszanie błędów
Automatyzacja
Dokumentacja
Zarządzanie testami
Planowanie
5. Find important
bugs fast
Zarządzanie ryzykiem!
Test things that are changed before things that are
the same
Test core functions before contributing functions
Test capability before reliability
Test common situations before esoteric situations
Test common threats before exotic threats
Test for high-impact problems before low-impact
problems
Test the most wanted areas before areas not
requested
6. Tester w
zespole
Zapewnianie jakości jest zadaniem całego
zespołu, niezależnie od metodyki!
If you're ever given authority to control the
release, we recommend immediately insisting on
sharing that authority with the other roles on the
team
Dlaczego programiści i testerzy powinni
siedzieć razem?
7. Specyfikacja
A tester who treats project documentation
(explicit specifications of the product) as the sole
source of requirements is crippling his test
process
You may get so familiar with a particular feature
that you test it in progressively narrower ways.
Introduce variation wherever you can or switch
testing duties with another tester
8. Zgłaszanie
błędów
Make your bug report an effective sales tool
Your bug report is your representative
Report the problem clearly, but don't try to solve
it - your job is to report problems, not to identify
root causes and not to push for specific solution
Evaluate bugs reported by nontesters, consult
with the author
9. Testy
automatyczne
Design automated tests differently from manual
tests
Test automation is a software development
process
Design your automated tests:
Ensure that the test has been set up correctly
Specify expected results
Notice potential errors and side effects
Recover from potential test failure
Prevent tests from interfering with each other
Refaktoryzacja!
Właściwie mają coś do powiedzenia na każdy temat, książkę można (i chyba najlepiej) czytać po kawałku i na każdym etapie pracy zawodowej znajdzie się tam coś dla siebie
Ciągły proces nauki, poznać produkt lepiej od klienta (!)
Każdy w końcu zetknie się z sytuacją, gdzie będzie ograniczony czas na testy (bo bardzo często, niestety, są traktowane przez managerów jako zło konieczne) i trzeba będzie wybierać, co przetestować.
Zespół powinien być zespołem, siedzieć razem, ROZMAWIAĆ! Bo zawsze ktoś może rzucić jakąś interesującą myśl albo znać odpowiedź na pytanie
Branie odpowiedzialnośći za kontrolowanie releasu może być kusząca dla początkujących...
Proza życia vs teoria ze studiów
Szersza specjalizacja, brak nudy i jak ktoś pójdzie na urlop, to wiadomo, co się dzieje. Ale nie zawsze jest taka możliwość, bo brakuje czasu.
Szczególnie w korporacji, przykład z Thomson Reuters.
o nie zmienia faktu, że poznanie przyczyny błędu zwiększa naszą wiedzę o systemie i wg mnie należy zawsze dążyć do tego, żeby zrozumieć na czym polegał błąd!
Szczególnie wartościowe, żeby poznać perspektywę klienta.
Wykorzystać możliwość powtarzania uciążliwych scenariuszy, dużej ilości danych. Ale wg mnie, na smoke test nadają się scenariusze "z życia wzięte".
Nawet jeżeli korzystamy z keyword-driven testing, framework się sam nie zrobi!