STEC Portfolio - Module 2: What Do Software Testers Do?

So much of what we do as testers, as Jenna Charlton said, is invisible work. When everything goes well, all is well. But what actions can we as testers take to help everything roll out as smoothly as possible?

In Module 2, I learned more about Glue Work and Hueristics, and discovered some valuable resources I want to keep for later.

These are my notes. Is there anything you would add? What have you learned in your journey through STEC? 

Definitions:

• Glue Work: “Glue work: A collection of small, often invisible actions and tasks that generate a lot of team value”

Discussion with Cassaundra Lueng and Melissa Fisher - As a Junior Tester, what kind of reporting works?

• Read this: https://www.ministryoftesting.com/articles/what-is-exploratory-testing-four-simple-words-to-level-up-your-testing-efforts

Important links:

• 99 essential resources to help software testers by Rahul Parwal

• The Club and search for ‘new testers’ and explore the “New to Testing” tag.

Great Quotes:

• Assumptions definition: something we believe to be true without any real proof. - Ady Stokes from Mind the Gap!

Resources on Hueristics:

• What are heuristics? - Software Testing Glossary

• Look at the Test Heuristics Cheat Sheet on the Ministry of Testing

Tasks:

🛠️ Activity: Use the 5Ws and H Framework to Challenge Assumptions

1. Identify an assumption: The City of Madison, Wisconsin, gives me headaches

   1. I recently traveled to Madison, Wisconsin. Before I left, I did not have a headache. While I was there, I had a headache the entire time i was there. Coming home, my headache went away.

2. Challenge your assumptions using thought techniques: Now, use the 5Ws and H (Who, What, When, Where, Why, and How) framework to think more critically about your assumption:

   1. Who was affected by this assumption, and could thinking from their perspective have helped? I was affected by this assumption, but this assumption could also affect my partner because we are considering moving there. If I make a decision based on my assumption alone, my partner will be affected as well.

   2. What was the assumption you made? Because I felt bad in Madison, I assumed it was the city, since altering my food did not affect how I felt (this typically works)

   3. When did you make this assumption, and did the timing or time pressure affect the outcome? While I was in Madison

   4. Where did this assumption come from (your past experiences, habits, unconscious biases, etc.)? This is my first time being in Madison, so I have no prior experience.

   5. In answering the previous questions, can you determine why you made this assumption? Because I felt fine before traveling and returning home.

   6. How could you prevent this from happening again? What steps could you take to improve your process or thinking?

   (Working through this task brought up this discussion topic that I posted in the MOT club)

⚒️ Assess the following scenarios, map the skills to the tasks, and share tips on how to develop these skills if you can.

• Scenario 1: Investigating a Bug Report

  • Skills/Traits: Inquisitiveness, Critical thinking, Attention to detail, spotting patterns

  • Explanation: When working with incomplete bug reports, it’s easy to be frustrated by what you don’t have: missing steps, cropped screenshots, or vague explanations. Being inquisitive, you can begin with what you do have. What hints are in the existing bug report that you can start from? If there is a screenshot or a video, watch it for tiny actions the user is making that could help you understand what issue they are facing. Can you figure out which browser they are using? Sometimes, even the machine they are using can help you figure out the issue. Windows users are notorious for double-clicking, while Mac users are typically single-click people (this uses your pattern-spotting skill).

  • Tips: Develop a great relationship with your customer experience team. If they see you as an ally, you can ask questions that they can redirect to the client. Get familiar with different user behaviors (like the difference between Mac and Windows users). And, above all else, get curious. If you have the end result (User cannot log in), approach the login page with the result in mind and try to find any way that you can to achieve the same result
    

• Scenario 2: Collaborating on a New Feature

  • Skills/Traits: Analytical Skills, Critical Thinking, Collaboration, Adaptability, Communication, Empathy

  • Explanation: Empathy was added as a skill here because when developing a new feature, in my mind, QA can approach the feature from a new user’s perspective. Does the design make sense? The functionality? If I am attempting to complete a task, does the UI give me clear directions on how to achieve what it’s promising that I can do? I can use empathy, analytical skills, and critical thinking when approaching development from this mindset. Then, being able to communicate my thoughts respectfully is crucial. Asking questions when I am confused gives the team a chance to rethink what’s been developed so far. And, I may think I see a better way, but due to time constraints, I may need to let go of what I think would be helpful. This is where adaptability comes in. I work with the team, communicating what seems valuable to me, then agreeing on what’s possible so that we can move forward with development.

  • Tips: When collaborating with others, approach people with the belief that everyone is working hard and wants to do their best work. You are not there to belittle what’s already been done or to merely “poke holes”. You are there to see where potential value might be missed, be willing to communicate that, and help bring to life what the team is working on together.

• Scenario 3: Conducting Exploratory Testing

  • Skills/Traits: Inquisitiveness, Time Management and Organisation, Spotting patterns, Communication, and Attention to detail

  • Explanation: When approaching functionality that hasn’t been tested yet, Exploratory Testing is a great way to approach this. First, gather your tools (this helps with Organisation). Be ready to document your findings as well as write test cases that can track what is working from a pass/fail rate. Know which browsers your development team supports, and try to view as a first-time user. Are the pages responsive? What is the first thing you are tempted to do when you see the page? If you don’t automatically want to follow the happy path, why is that? Be ready to communicate that to your team (communication). Do the elements match up with existing elements in other parts of the application (spotting patterns)? If you know how to break a particular part of the application in one way, can do break it in the new functionality you are testing? Be as inquisitive as possible and be willing to look at with with new eyes, over and over. At some point, though, you will reach a point where you won’t know how to break it. This is good! That means you have reached your limits and you are ready to see how other users could possibly break it (Time Management). Write up your reports and share what test cases you’ve created, which passed, which failed, and how reliable you feel about the application if it were released today.

  • Tips: Get your tools together. Have a test case management system ready. Know how to communicate your findings. Be able to share the number of test cases that are passing or failing. Be willing to “sleep on it” if you’ve spent the day on exploratory testing. Looking at it again with fresh eyes the next day can sometimes provide a whole new perspective, or you might have the ability to spot something you missed the day before because you spent so long looking at it.

• Scenario 4: Prioritising Bugs for a Release

  • Skills/Traits: Critical Thinking, Collaboration, Communication, Adaptability

  • Explanation: Not everything will come out as squeaky clean as we like before releasing it to production. This is where trust in the team comes in (collaboration). It is our job to communicate what the current risk of releasing looks like. Having an existing list of issues that the team can work through and determine priority will help foster trust. Leaning on adaptability, the team may make a decision that I am not a fan of. That’s fine as long as the team made the decision. Based on user feedback, the team can come back together and decide which steps to take. Being willing to view functionality from the user’s point of view and determine what is high priority is not only the QA’s job. It’s everyone’s job to decide how they want their work to display for the world.

  • Tips: Communicate the risks. Provide educated information for the team to decide how they want to spend their time, either before or after a release. Then, let things happen. Hopefully, you are not in an environment where the team is the scapegoat. If this happens, be very clear in communicating that you shared your findings with the team and that the decisions made were a team decision. Being able to trust each other and own quality together is what makes a good team great.

Till next time…

All my posts are free to read, and clicking subscribe will bring each post to your inbox. If my work brings you joy, and you’d like to support it, you can become a paid subscriber by clicking the button above. If a paid subscription is not your thing, you can support my caffeine addiction writing by clicking the button below! Thanks!

Written with make a dent in the universe — dreamcore sleep music playing in the background