Project Planning and Management
As a project manager that specializes in digital software products, I will let you in on a secret about a new role, a new type of person that is emerging in the ranks—and it’s all good news for your project. This particular role actually inspired this series of articles about new roles that were emerging in the project life cycle due to digital disruption. The previous articles in this series are:
- The Servant Leader, Team Doctor, Technically-Comfortable Agile Project Manager
- The Connected, Inspired, Hands-on Project Sponsor – Leading the Digital Charge
- The Emergence of the Elusive Digital Unicorn
As a project sponsor or agile project manager, you should definitely be on the lookout for this person, because if you can find them and secure them for your team, you will have given yourself a much-needed advantage in ensuring you ship a quality product. The person is the new type of QA engineer.
Who They Are Not – the Traditional Tester and Test Manager
So, if there is a new type of QA engineer, what is the traditional role that they are replacing?
The QA engineer may be mistaken for the traditional tester or test manager, but they certainly are not the same person. The tester was the person who was often responsible for finding the errors or strange behaviors in the product. This was the person who walked around with the coffee cup titled “developers tears” the one who enjoyed finding bugs in the code and rubbing the development teams face in it.
This was the person who warned you that the product could not be shipped to production because there were 80 bugs or defects found. They were often involved towards the end of the software development lifecycle and would add around 80 percent, if not a 100 percent, of scope onto your project as items that were found would lead to drastic changes in software architecture. They did not see themselves as part of the development team but a quality checker, someone who was responsible, and in some cases even incentivized, for finding errors. These were the people who outlined their testing strategy way after development had already started, you know the type of person.
The QA Engineer Is Actively Involved in Understanding Your Product and Recommending the Quality Strategy
The QA engineer is not the same. They understand up-front that quality should always be built into the product upfront, instead of quality being driven into the project by detailed inspection. Therefore they take a hands-on approach to guiding the project sponsor and manager in how best to do that with an effective budget. They see themselves as part of the team, not separate. They carry the balance between effectiveness, quality, and value add.
Interested? Read on.
The QA Engineer Helps the Team with Unit Tests and Writing Integration Tests
If your development team is not using an agile type methodology, then you should definitely consider looking to implement this framework as soon as possible. With agile software construction, there are often two testing strategies: one geared at the code level and the other geared at the integration, behavior level. The QA engineer helps drive both. When the development team are workshopping a user story, the QA engineer can be seen helping the product owner give the team direction on what they are looking for from the development.
You will hear the QA engineer say, “So when we are looking to test the code, we will be focusing on performance, how the application integrates with the other systems etc…” This gives the development team clear direction as to how performance and requirements are going to be geared without telling the team how to code the solution. Forget about the Scrum Master leading the planning ceremony, have the QA engineer lead and see how well you do.
The QA engineer, first and foremost, is an engineer. This goes a long way in earning the trust of the developers. They understand code and can coach the developers in a way that enables them to write the best code they have ever produced. The QA engineer is technical, they could have become a developer but decided to focus on quality; they are no slouch in the technical department and it shows. They are invaluable in helping guide developers on how to find and resolve bugs.
They guide the developers when the they are writing their unit tests. Ensuring the product owner has provided the correct acceptance criteria that will translate into great unit tests. The test cases that they provide, gives additional information that the developers can use in their test-driven design strategy. The integration tests that they set up and write themselves, test the system end to end and, at the end of each development sprint, the product owner or sponsor, has a clear handle of what quality state their product is in. This provides management with a high level of trust that their product is often only weeks away from being able to ship, which is worth its weight in gold.
The QA Engineer Understand the Benefits of Quality and Where It Fits In as It Relates to the Overall Strategy
The quality engineer understands that the lack of attention to quality results in more rework, more defects, and more dissatisfied customers. This means they have their eye on quality all the time while understanding how it affects the project’s bottom line.
They know that apart from some research projects, most software projects are geared toward making a profit, generating revenue, or reducing expenses. What this means is they will not “gold plate” the quality exercise, and will guide the team to what is right for their project.
They don’t label everything as a bug or a defect but categorizes them in ways that allow the team to make the correct decision as to which ones they will address first and which ones they will allow slide. Examples of this are level 1 bugs that need to be fixed straight away, level 2 defects, great to be fixed but can be fixed later, level 3 are enhancements that make the system work better. Each of these levels have different activities associated with them.
They understand that every change or fix carries a cost implication and they use their experience to measure the reward over the risk. They understand that even though the best practices are implemented, changes and fixes do introduce a level of complexity and so returns must be measured against effort and complexity that has been introduced.
They question themselves and the product owner as to whether the bug can be lived with or not and provide guidance. Like a coach, they know the development team can’t be rock stars overnight, they just know which issues need to be resolved now and which ones can be handled later.
My Own Project Experience
Last year, I had this experience on one of my IOT projects. I encountered a QA engineer on my team who was the inspiration for this series. He was fantastic. From the beginning he worked with me as the project started. The project was a lite MVP used for the customer to introduce a working pilot for clients to measure occupancy levels. He implemented a quality strategy that I, as the agile project manager, just had to oversee while the team knew the requirements that unit tests had to be written at. He also automated our integration tests and was the chief tester, running through demos before the review sessions. I have subsequently tried, on all my projects, to introduce the things he has taught me, and it has paid dividends not only to quality but turnaround times and the ability for my teams to ship to production. I trust it will be your experience as well.
