Quality Assurance at an Agile Product Design Company
You’re gathering your team of resources for a project, that’s being run in Agile. Your resources include a Scrum Master, Product Owner, Development Team, Design Team, and QA Team. What about your client? Working for a product design and development company, the client is actively involved in every aspect of the Software Development lifecycle. They serve as the voice for the Product as stake holders and potentially a product owner. Together we are all responsible for maximizing the potential of the product and ensuring that all releases meet a high standard of quality and assurance.
The Experience
Working in the field of Quality Assurance for a product services company can be quite the roller-coaster of an experience. You become the product expert, knowing all of the features, defects, and specific edge-cases that are found within the product. On the other hand, as the product expert, whenever something goes wrong you will be the one everyone turns to for an understanding of the issue. The last thing that a member of a QA Team wants to hear from their client is “have you seen this?”, or “has this been tested?”. These four words in conjunction can make for a pride breaking experience, not to mention cause sleep deprivation. As a quality assurance engineer you must welcome the challenges that come along with the pressure, and more importantly, you must be passionate about helping the team create a quality driven product.
Identifying critical defects is one of the most exhilarating and rewarding experiences in the field of QA. It’s great to find certain issues that occur, especially critical ones, before the product makes its way to the client’s hands. One caveat to the pleasures of reporting defects, however, includes the fact that these need to be reported to the client directly. While this may seem like a very trivial task, and one that should appear seamless, essentially what is occurring during this event is – one member of your team has produced a software bug during their development, and it must be brought to the attention of the team, specifically to the attention of the client. During this reporting event, the QA Engineer becomes the bearer of bad news for all parties involved. If the approach taken when conveying these types of reports to the client isn’t thought out thoroughly, it can result in either stirring up your development team members, or even worse, your client.
”Without superior QA, your customers become your alpha testers. It’s not a good look for anyone involved." - Michael Yackavage, IPS Sr. Embedded Systems Engineer
There is an art to delivering these defect reports in a way which alleviates the clients guard on a defect, while also keeping them ‘in the know’ about their product, while also protecting your fellow colleagues from being thrown under the bus. “The application is always crashing” versus “the application crashes when the following reproduction steps are taken” are two examples that are addressing the same concern. The second example being one that can diminish a client’s concern based off of the way the issue is encountered, which can also paint a better picture as far as the frequency of the problem at hand.
The Collaboration
In the realm of QA, it’s imperative that critical defects are encountered and documented, prior to releasing new software to the client. Obviously, there is never going to be “perfect” or bug free software, but at a minimum, there needs to be a certain level of excellence that is achieved upon releasing software.
With trying to achieve this level of excellence, it is okay for the team to encounter disagreements along the way. It’s healthy and shares in the growth of each member of the team. Each member plays a vital role in the success of building a quality driven product. One sports analogy I’d like to reference is one of the greatest teams in Professional Sports, the New England Patriots. Do you think Tom Brady and Bill Belichick would have been able to compete for 9 Superbowl’s, winning 6 of them, without having their fair share of disagreements? They’ve had plenty of these, and as a result have achieved excellence, being recognized as one of the greatest dynasties of all time, in pro sports.
”On a team, it’s not the strength of the individual players, but it is the strength of the unit and how they all function together." - Bill Belichick, Head Coach, New England Patriots
Similarly, a scrum team will encounter their disagreements during the life of a project, whether the disagreements are around architecture, design implementation, software development, or how a specific feature should function. At the end of the day, this all contributes to building quality software. Each member of the team has their role to fill. The Scrum Master has the responsibility of sticking to their project schedule as well as their budget. The Development Team has tasks that need to get done during each Sprint. In addition to this, developing in Agile, there are bound to be new feature requests/asks driven by the Client that’ll result in the need to pivot functionality. Lastly, the QA team is making sure the team is delivering quality driven software. All of these in conjuncture, can make for some healthy disagreements during the development lifecycle which is completely normal. I’d argue that if this was not occurring at all, you’d have bigger issues at hand.
With that being said, software is still software at the end of the day, and the nature of the beast is that defects are bound to occur. It’s important to note that software defects are not necessarily the result of poor development. Both hardware updates and operating system updates contribute their fair share of defects. While this may seem trivial, OS updates certainly play a factor in defects being brought about. The yearly Apple OS update spawns a dirge of defects related to changes in underlying libraries and UI constructs. Hardware updates with displays changing in size and screen density can also contribute to defects in the way UI elements are displayed on a screen.
It is important to identify and address these issues as quickly as possible, as the sooner they are encountered, the less expensive they shall be to address. Finding defects later than expected causes a diversion in the development lifecycle. As a result of this diversion in development, this results in the need to hotfix a defect and release it to QA for verification. At this point, validating the bug fix and performing an acceptance test on the new build becomes the priority for the QA team. Any tasks being worked on during that time become second in priority. On the other hand, encountering these defects early does not always mean that they will be addressed in the following Sprint, but it does propose a valid question for the Client and allow them to make a decision based on the severity of the problem. The QA team is responsible for bringing forth these defects and encouraging the team (including the client) to revisit and prioritize tasks in order to address the raised concerns. While the team may disagree, at the end of the day, the Client/Product Owner has the last say. If they feel strongly about prioritizing a feature for a newly encountered issue, it is their call to make.
Being the gatekeeper for a software product means that QA will serve as the teams last line of defense. The Dev Team has done their due diligence in unit testing their code, has signed off and released the build to QA. At this point, the QA Team’s responsibility is to acceptance test the software, executing their automated and manual test plan. If all goes well during this process, the Team is now ready for a release to the client. This is not a trivial undertaking, preparing for a release to the client is a very big deal. Releasing to the client means that the team has done everything that was asked of them, the build has received the QA Team’s blessing and stamp of approval, and the software is ready to be handed over to the client in a production ready state.
The Goal
Our mission as testing professionals is to discover the truths about a product, not prove that the product “works”. Overall, to sign off on quality driven software ensuring that the team has produced a product that meets our high standard of excellence and provides the user with an experience that is free of frustration. Nothing short of excellence is what is expected from our clients, and being a Product Design and Development company, it is our mission to provide that!
