The Evil Tester Show - Software Testing and Development with Attitude

Are you trying to figure out how to break into the software testing job market or make your next big move? This episode of the Evil Tester Show dives deep into the realities of tech recruitment, job search strategies, and career planning for testers - with recruitment veteran Jack Cole from WEDOTech.uk - Whether you're an experienced Test manager, expert Tester, junior QA or even a programmer, Jack’s decades of Software Testing and Development industry experience will give you strategies and tips about what works in today’s competitive job seeking world.

In this packed hour-long conversation, we cover everything from market trends, LinkedIn networking, and the recruitment pipeline, to building a career roadmap and even the AI hype machine. Grab your notebook, settle in, and get ready for real insights you can use – plus a few stories from the trenches and actionable tips for every step of your job hunt.

Software Testing is a skill and like all skills require practice, that's what makes you a practitioner of Software Testing. In this episode we're diving into the world of practice with the James Lyndsay.

In this conversation, your host Alan Richardson chats with James about the essence of practice in software testing, exploring how exercises and real-world scenarios can enrich our skills. James shares insights on his weekly online practice sessions and the interactive Test Lab concept, offering a dynamic playground for testers.

Discover how practice blends with rehearsal and learning, and delve into the intriguing intersection of testing and development. With firsthand experiences in software experiments, fencing, and scientific investigation, James and Alan discuss the art of modeling and exploring software systems. Whether you're refining your testing techniques or embracing new perspectives with AI, this episode offers a wealth of wisdom for testers at all levels.

Join us as we learn, laugh, and explore the world of testing practice. We hope you find inspiration for your own practice sessions. Don't forget to check out James's resources at https://workroom-productions.com for more testing challenges and exercises.

Effective Software Testing is highly contextual: we adapt what we do to the project and the process.

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.

Software Testing and Development professionals often mention the Test Automation pyramid when describing Test Autoamtion. Let's do a deep dive and explore what that means.

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.

Software Testing is often taught with a focus on Test Cases and Test Scripts. But this is the 2025, we don't test like it's 1984 any more. Let's revisit how we model testing and create a more effective test process.

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.

Software Testing often looks at the exactitude of language. We look for ambiguity in Software Requirements, we find gaps in Specifications, so it's no wonder we explore the use of terms and definitions in our own Software Testing craft.

Top 3 Phrases that should carry trigger warnings for the Test Community:

- Manual Testing

- Test Automation

- Quality Assurance

In this episode I'm going to talk about Manual Testing.

So that's your Trigger Warning.

And I'm going to talk about what we might want to say instead of "Manual Testing"

Software Testing is going through a time of change. This episode explores how we can adapt.

Manual QA is dead. Companies are getting rid of their QA teams. Quality Control performed manually is phasing out of style. What can we do instead? Become coaches, assistants or advisors? We could become developers? Or we could be better testers. QA and Quality Control is not Testing. This might be how people learn.

Software Testing is highly contextual and requires flexibility in our approach and thinking. But we are only human and sometimes we have beliefs and biases that limit our approach.

In episode 16 of The Eviltester Show we are looking at Test Automation Biases, what they are, how to avoid them, and how to evaluate your own biases.

00:00 What is an Automation Bias?

00:29 Treat all opinions as biased

01:50 Automating a GUI is Slow and Flaky

03:36 Automate through the API

05:23 Code Free Automating is Bad

06:17 Tool X is Better than Y

07:04 Postman is Better than Insomnia

08:54 Python is Better than Java

10:24 Seeing Through Biases

12:52 Try it, then decide

13:17 Page Objects vs Screenplay

14:52 Take Responsibility

16:11 External Experience

17:02 Start Small, Make Progress

17:50 Do not ignore issues

20:34 Be Real rather than Believe

21:18 Keep Options Open

22:48 Be Aware of your biases

23:19 It takes time

Software Testing is often a proprietary process where we never share how we are doing it. Governmens are an exception because they make public a lot of documents explaining what they do and how they do it.

In this episode we have a discussion of a UK government guide to exploratory testing.

• https://www.gov.uk/service-manual/technology/exploratory-testing

The aim is not to criticise the document, the aim is to use it as a base from which to see how far our thoughts diverge or overlap with the document. I want to know what I can learn.

Show notes are here:

https://www.eviltester.com/show/015-exploratory-testing-gov/

This podcast, was originally released to Patreon supporters in January of 2019,

• https://patreon.com/posts/what-is-testing-23907385

I read through the document and try to understand the intent and meaning behind statements and offer my own thoughts.

Software Testing is a hard activity to recruit for,.Recruiting Testers is hard. What we want to do is minimise the friction and barriers. In this podcast I'll share some tips on what has worked for me in the past.

- remove as much ambiguity from your job spec as possible

  - someone like me, will read 'the worst' into your ambiguity

- send clear messages, not mixed messages, in the job spec

- help the applicant filter out roles that are not suitable for them

- when writing a job spec, review existing job specs in the world, critique them and then build on what is best from those

- start with a phone interview, never start face to face

- some people bluff, some people offer general answers

  - your job as an interviewer is to help them answer specifically and ask for more information when you want it

- Interviews as auditions, held by someone who knows how to do the activity being auditioned

- audition hands on with the actual code, or the actual system

- use your best people for the interviews, not just anyone that is free

Show Notes:

https://eviltester.com/show

We have more posts in our recruitment category:

- https://www.eviltester.com/categories/recruitment/

And our Career category:

- https://www.eviltester.com/categories/career-advice/

This video was originally released as a Patreon exclusive video back in January 2019

- https://www.patreon.com/posts/recruitment-tips-23896867