STEC: Module 3 - The secret skill set of software testers

The value of making the unknown, known

Author

Judy Mosley
January 28, 2026

In module 3, we learn the value a good tester brings to the table. Good testers are curious, empathetic, able to ask questions, able to have a variety of conversations with all kinds of teammates, and to make the invisible become visible in a variety of ways.

Key Takeaways

In Lesson 1: What makes a good tester? Jenna Charlton and Beren Van Daele recommend the following

In Lesson 4: Receiving and Giving Feedback, Jesse Berkeley advised starting a feedback journal.

In thinking about this idea, I created my own online Brag Book/Feedback Journal. I hope to keep all my findings to help catalogue feedback and important accomplishments I’ve achieved along the way.
https://github.com/jmosley5/feedback-journal/

Another tool to use to get our thinking caps in a different mindset is The Six Thinking Hats. Use the colors to identify which mindset you need to take on at the moment.

🤍 white: What facts do we need to know?
💛 yellow: What are the positives, values, and benefits?
🖤 black: What are the problems and risks?
❤️ red: What do you feel about the situation?
💚 green: What are the possibilities?
💙 blue: How can we ensure guidelines are followed?

And, if I were going to add one… 🤠 
💜 purple: What would we like to see happen that doesn’t seem to be an option right now?

Activities

The Goldilocks Hueristic:

Find software and apply the Goldilocks heuristic to create three testcases:

  • Less than: The cart page should tell the user that their cart is empty

  • Just right: A user can see when one coffee is added to their cart

  • More than: A user can see when they’ve added 20 different cups of coffee to their cart

Mnemonic portfolio:

Either trigger or recall an error message in software. Apply the mnemonic based on the information you have available and capture it for your portfolio.

Using the Sauce Demo website, we will assess the login page.

Example:

As a user who is locked out, what information can I gather when attempting to log in?

  • Functional: Do we detect errors automatically? Can users report errors?

    • After attempting to log in, I can see by the error message that I’m locked out. There is no way to report being locked out, or any next steps given.

  • Appropriate: Are errors reported instantly, to the right audience? Do we have false errors?

    • The error is reported instantly, and to the right audience. If I attempt to log in with a valid username and password, I do not receive the same message. Logging in as a user that is locked out, I see the correct message.

  • Impact: Does it fail as soon as possible? Is the user flow blocked? What do users lose?

    • The user does not have any way to access an alternative route. The question becomes, if a user is logged out, what are their options to gain access? Do we want them to gain access? Why or why not.

  • Log: Are logs accessible, detailed, searchable and understandable by us?

    • Looking in the network calls, the logs don’t give any reason why the locked_out_user is locked out. Just the error message that they don’t have acess.

  • User Interface (UI): Is the error message understandable by users?

    • Yes.

  • Recovery: Does the message help users recover from the error? Can they contact support?

    • No

  • Emotions: What does a user feel when an error occurs? Does the error message ease or worsen that pain?

    • Without the option to contact support, a user can do little else. This is a simplified example, for sure, but it’s a reminder that if someone finds themselves on the other side of a blocker, we need to figure out what is the best way to get them on the right track.

Oracle Activity:

Activity: Those are just a few examples of where you can take oracles from. Why not spend some time researching them for yourself as well as considering what oracles you use in making everyday decisions? Thinking about thinking is always a good way to grow your awareness. When done, don’t forget to update your portfolio.

What Oracles do I use in making everyday decisions?

  • The weather: to figure out how to dress every day

  • Written test cases: when I’m working to create automated test cases. I want an automated test case to mimic the written test case so that the person reading it has a mirrored example to follow

  • Bug reports: When a user reports a bug, and it’s a verified bug, I use that bug report to create a written test case, and then a related automated test case to increase coverage (if it’s not too much of an edge case)

And, finally, building your Tester Skills Plan. I’ve learned a lot in my journey so far, but I'm thinking learning how to make the invisible, visible is the theme that’s been coming up for me the most. It’s time to start talking about what makes up the work that I do, and tell it in a way that matters to the receiver.

YourTesterSkillsPlan.pdf237.25 KB • PDF File

Till next time:

Reply

or to participate.