This document discusses context-driven testing, emphasizing its origins, principles, and significance in software testing. It highlights that context-driven testing focuses on tailoring testing practices to the specific context of a project rather than adhering to standardized 'best practices.' The document also contrasts context-driven testing with agile methodologies, noting that while they share similarities, context-driven testing is not inherently linked to agile development.

1. Context-Driven
Testing

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

5. Why I talk about Context-Driven Testing?

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

9. “Software development is a
social activity”
Gerald M. Weinberg

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.

21. Sources
Sites:
http://context-driven-testing.com/,
http://www.satisfice.com/, http://kaner.com/,
http://developsense.com/
People to follow:
James Bach, Cem Kaner, Michael Bolton, Rikard Edgren, Shmuel Gershon, Karen
N. Johnson, Rob Lambert ...