When starting on a new project, it’s very common for me to be the first and / or only tester. I find myself frequently wanting to document the same things, rewriting them from scratch. To help with this, I’ve decided to include some of this documentation on my own blog, so I no longer have to start from scratch. I’ll probably edit and improve them over time. You can view all posts in the documentation series.
Many teams benefit from some clarity around the role of a Quality Engineer (QE). Whether you’ve never worked with one before, only worked together in one context, or have only experienced one type of tester, it’s helpful to know what having this tester on the project will mean for you. Here, I hope to answer some questions you might have. This list is neither exhaustive, nor a replacement for conversation, so please approach me for a chat any time.
How will having a QE benefit us?
This depends a little on context, but in general, having a QE often provides the following benefits:
- Faster feedback loops
- A bridge between business and technical topics
- A bigger picture of how our solutions relate to end users’ needs
- A sounding-board for ideas
- Better quality testing, and a better quality product
- Improved processes
- Faster delivery times
- …
Does having a QE mean we don’t have to test ourselves anymore?
No 🙂 Quality is everyone’s responsibility, and part of building quality in from the start means testing throughout the SDLC, by everyone.
Why are you asking me to test?
See Why Are You Asking Me to Test?
Will you support us to test ourselves?
Of course! Some ways I could help include:
- Pair testing
- Training and coaching on specific topics
- Coming up with test ideas
- Advising on what, where, and how to test
- …
What kind of testing will you do?
This depends on the project and how things progress. It may be that one kind of testing makes more sense or is more helpful in the beginning, and another later on. Here are some examples of testing I could do:
- In-sprint testing of stories, improvements, bugs
- Back-end, front-end, integration testing
- Verification testing – testing according to requirements or specifications
- Validation testing – assessing the value the SUT provides, and whether it actually helps users achieve their goals
- Exploratory testing to uncover information and inform decisions, like whether we’re comfortable releasing
- Shift-left testing – testing requirements, designs, proposed solutions
- …
Where can we find your testing notes?
My testing notes will always be either directly added to the comments of the relevant tickets, or otherwise linked.
Do you expect us to fix / implement every issue / idea you have?
Definitely not! I’m thorough with my testing, and document on the side of caution, so I’m prepared to answer any questions that might come later. It’s still up to the team (and ultimately the product owner) what we choose to fix / implement and when.
Are you only concerned about the product?
No. As QE, I’m also interested in the quality of the project, processes, and people topics. Along with product, these are sometimes referred to as “the four Ps“. This means I’ll also be looking at the bigger picture of everything it takes for us to build and deliver a good quality product.
What else will you do?
As well as testing and assessing quality, a big part of what I do will involve test strategy and test planning. This can include:
- Forming a holistic test strategy
- Running workshops, such as RiskStorming
- Supporting in project management
- Supporting continuous improvement efforts
- …
Some other ways I can contribute include:
- Investigating how to recreate user-reported bugs
- Taking part in code reviews
- Liaising with stakeholders
- Supporting with compliance requirements and audits
- …
What won’t you do?
My role as QE is pretty open, and flexible to your needs. However, here are some things I usually don’t do, or that are outside my current area of expertise:
- All the testing
- Writing production code
- In-depth security and performance testing
- Stay silent – you’ll get lots of questions and opinions from me, all of which are open for discussion
- …
How can we support you as QE?
What a nice question! 😉 Here are some ways you can support me:
- Keep an open mind
- Contribute to quality and testing throughout the SDLC
- Offer me the same information and access as developers (even though I might not need / accept it all)
- Actively approach me with your needs, questions, ideas, etc.
- Give me feedback – if there’s anything you particularly appreciate or think I could improve, just let me know any time, and I’ll use this information to help provide the most value to you
- …
I have another question or topic for discussion.
That’s great! Approach me any time, and I’ll be happy to chat. If you think others might benefit too, feel free to bring it up in an open channel.
Find this useful? I’m happy for you to use it as a basis for your documentation too. Please just add appropriate attribution (e.g., linking to this post).