Prezentacja z ósmego spotkania z cyklu Quality Meetup.
Autor: Michał Stryjak (QA Manager, PiLab SA)
Przez wiele lat ludzie starali się wskazać niezawodne podejście do testowania. Nasz Gość uczestniczył w wielu dyskusjach dotyczących wyższości jednej metody nad drugą, które zwykle sprowadzały się do poszukiwania odpowiedzi na pytanie, czy jakaś konkretna praktyka zmieni świat testów na zawsze.
Już wiele lat temu Cem Kaner zauważył, że najlepsze praktyki głoszone przez jego kolegów wykładowców nie zawsze sprawdzają się dobrze w rzeczywistości. Często obserwował jak procesy i narzędzia stosowane z powodzeniem, np. w startupach, nie sprawdzają się w bankach lub branży medycznej (i vice versa). Z biegiem lat Cem doszedł do wniosku, że coraz więcej osób ma podobne spostrzeżenia dotyczące najlepszych praktyk. Ludzie podzielający jego poglądy (najbardziej znani to James Bach i Bret Pettichord) twierdzą, że aby móc testować dobrze, najpierw trzeba uwzględnić i przeanalizować kontekst. Ich idee znalazły odwzorowanie w siedmiu zasadach, które dzisiaj stanowią podstawę podejścia Context-Driven Testing (CDT). Na spotkaniu Michał opowie nam o podstawach CDT oraz podzieli się pomysłami, jak można wdrażać wspomniane siedem zasad w życie.
2. HELLO!
I’m Michal
QA Manager at PiLab,
Testing enthusiast, gamer, soon to be a father
You can find me at:
● @MStryjak
● michal.stryjak@gmail.com
3. Place your screenshot here
PiLab DataWalk
● Integrate data
from multiple
sources (internal
or external)
● Find hidden or not
obvious
connections
between large
datasets
● Gain new insight
without SQL
knowledge
4. Agenda
● Why I talk about Context-Driven Testing?
● The beginning
● Principles
● What is Context-Driven Testing?
● Context-Driven vs. ...
● Context-Driven Techniques?
● Hints
6. The beginning
● Roots of CTD can be traced back to 80s’
● 1999 - Term “Context-Driven Testing” was forged by Cem Kaner, James
Bach, Brian Marick, Bret Pettichord
● 2001 - first CDT book was published (Lessons Learned in Software Testing: A
Context-Driven Approach)
7. Principles
● The value of any practice depends on its context
● There are good practices in context, but there are no best practices
● People, working together, are the most important part of any project’s context
● Projects unfold over time in ways that are often not predictable
8. Principles
● The product is a solution. If the problem isn’t solved, the product doesn’t work
● Good software testing is a challenging intellectual process
● Only through judgment and skill, exercised cooperatively throughout the entire
project, are we able to do the right things at the right times to effectively test
our products
10. What is Context-Driven Testing?
Context-driven testers choose their testing objectives,
techniques, and deliverables by looking first to the details
of the specific situation, including the desires of the
stakeholders who commissioned the testing.
11. What is Context-Driven Testing?
The essence of Context-Driven Testing is project-
appropriate application of skill and judgment.
It declares that the human part of that context is most
important, and that good testing is ultimately a matter of
skill, not procedure.
12. What is Context-Driven Testing?
Ultimately, Context-Driven Testing is about doing the best
we can with what we get. Rather than trying to apply “best
practices,” we accept that very different practices will work
best under different circumstances.
13. Context-Driven vs. Agile
Agile development models advocate for a customer-responsive, waste-minimizing,
humanistic approach to software development and so does context-driven testing.
However, context-driven testing is not inherently part of the Agile development
movement.
14. Context-Driven vs. Context-Aware
When someone looks to best practices first and to project-specific factors second,
that may be context-aware, but not context-driven.
Being Context-Driven reaches beyond your job. It affects how you develop
yourself and how you contribute to the CDT community.
http://www.satisfice.com/blog/archives/1504
15. Context-Driven Techniques?
CDT is an approach, not a technique. Our task is to do the best testing we can
under the circumstances–the more techniques we know, the more options we
have available when considering how to cope with a new situation.
The set of techniques that we need is not just a testing set.
16. Tester’s toolbox (just to start …)
Tester’s syllabus:
http://www.satisfice.com/images/testsyllabus.pdf
Heuristic Test Strategy Model:
http://www.satisfice.com/tools/htsm.pdf
The Test Eye Publications:
http://thetesteye.com/blog/publications/
17. Hints
● It is not a testers' job to demand documentation. Good testers work with the
information they have, use unofficial documents, and are specific when
requesting additional information.
● Testers exist to provide testing-related services. They do not run the
development project; they serve the project.
18. Hints
● The value of testing is determined by whether it provides useful and timely
information.
● Test what’s needed, not only things you can
● We don't hide behind the test plan. We learn how to improve testing as we
test.
● Different types of defects will be revealed by different types of tests. Tests
should become more challenging or should focus on different risks as the app
becomes more stable.
19. Hints
● All oracles are fallible. Even if the product appears to pass your test, it might
well have failed it in ways that you (or the automated test program) were not
monitoring.
● A tester is a customer advocate. Testers try to understand the customer
position and make the best case when they feel it isn't being address.
20. Hints
● Test artifacts are worthwhile to the degree that they satisfy their stakeholders’
relevant requirements.
● CDT does not say what you should always do or avoid.
● Testers are scientists. They experiment
● Testing is an information-providing service, not a "quality assurance" function.