You heard it here first - Rocket now has a QA team and we do more than test. Among other things, we rely on our curiosity (or skepticism) to do our jobs and provide the quality our clients are looking for.
More Than Testing
The role of a QA engineer isn’t solely about testing. Yes, that is a significant part of it, but in our experience trying to summarize it into that one act does not paint the full picture. The entire team is responsible for quality, but it is the job of QA to champion that cause. QA should understand the product and its landscape as a whole.
In my head the product is a puzzle and my job is to understand all the pieces of that puzzle and every aspect of where and how they fit. My goal is to keep in mind the perspective of all the various stakeholders i.e. developers, customers, designers and the business. Yes, I am responsible for verifying that Feature A is working in the product, but that means more than you might think.
What "Working" Means
There’s a variety of factors that go into determining that Feature A is “working”. Some of those factors:
- Learning about Feature A's implementation
- Learning Feature A's origin and purpose
- Understand how the business thinks customers will use Feature A
- Anticipate how it will actually be used
- How it integrates with external products (if it does at all)
- (Last but certainly not least) Verify it achieved its purpose
I like to ask questions (sometimes a lot of them!) much to the delight (or chagrin) of the developers that I work with. There should be a constant dialogue between QA and developers but also the product team. How else would you gain that deep level of product knowledge?
A recent conversation...
QA: I think I found an issue with Feature A. I tried Scenario X where a member can schedule...
Dev1: I will have to check that
Dev2: I'm sure I missed that scenario. I'll fix it
So, I do spend a good chunk of time executing tests, but that alone does not convey the thought and research that goes into writing and maintaining test cases and plans. I get excited when I’m told I thought of a scenario that was never considered (but should have been) or that I found an edge case in how Feature A should work. I dissect every detail of Feature A in hopes I get that moment of excitement.
Another recent conversation...
Dev: You catch a lot of things that I didn’t think of originally
QA: I’ll take that as a compliment
Dev: It’s a compliment to you and a slight to myself
What Else?
A QA engineer should be constantly assessing and analyzing. What exactly for? It could be anything from estimating the duration of the test effort to anticipating issues that might occur during the development lifecycle and beyond. QA also needs to be able to succinctly articulate what testing is required. In addition, we have to be able to explain why a defect is or is not critical.
QA will not only strategize what to test, but how that effort should be accomplished - manual, automated, or a combination of both. Once that is decided upon, then there may be research to figure out which tools to use.
So, yes, we test but that is only one of the many tools in our back pockets that we lean on to ensure the quality of the software we are working on.
At Rocket, a QA engineer should be doing all of this for every assignment no matter if the project is 3 weeks or 3 months.