In this episode of The Evil Tester Show, host Alan Richardson describes context-driven testing. Is there really such a thing as context-driven testing, or is it just a phrase we use to describe our testing approach? Alan explores the intricacies of context in testing, discussing its evolving nature, the impact of context on testing practices, and the challenges in defining it.

From the origins of the term by James Bach, Brian Marick, Brett Petichord, and Cem Kaner, to Alan’s personal insights on systems within systems and how context impacts our testing methodologies, this episode provides a comprehensive look at how context affects software testing. Alan also critiques the principles of context-driven testing and emphasizes the importance of adapting to projects without being swayed by ideologies.

We explore how to navigate context in testing environments, adapt our approaches, and effectively challenge and evolve systems. Discover the importance of context-driven testing in software development, exploring models, adaptability, and useful practices.

This episode covers the Test Automation Pyramid, created by Mike Cohen in 2008-2009 in the book "Succeeding With Agile". We will go beyond the diagram and look at the model that supports it. Then deep dive into the model to explore it's meaning in relation to Automated Execution Coverage, not Testing.

- The model was created by Mike Cohen in 2008-2009 in the book "Succeeding With Agile."

- The original model focused on UI, service level, and unit level automation.

- Over the years, different interpretations and variations of the model have emerged.

- The term "service level" in the model has led to ambiguity and different interpretations.

- The diagram in the model is a simplified representation of a deeper underlying model.

- The focus should be on achieving coverage at the most appropriate level in the system.

- The model addresses the importance of avoiding duplication and redundancy in automated coverage.

- The process and team structure can impact the effectiveness of the model.

- The model can be reframed as an automated execution coverage pyramid.

The most common Testing Entities that I've encountered over the years are:

• Test Condition
• Test Scenario
• Test Case
• Test Script

In my Testing I pretty much now have:

• Test Idea
• Test Log (Execution Log)

Is there any value in the original Testing Entities? There might be if we view them as logical concepts, but not really as physical artifacts.