I had the opportunity in my career to create a quality assurance (QA) team from scratch for a small software development company. Prior to this, developers and project managers would do all the testing. After petitioning for quite some time that this was not the best approach to ensuring quality, I was finally given the challenge of developing a stand-alone quality assurance team.
Getting Started with Quality Assurance
When I set out, my priority was simple, to make sure no bugs made their way into production. So I interviewed and built out a team, established processes, attended conferences, selected tools, and tested.
My first realization in this role was that my team relied on developers to get their tasks completed on time, and on system admins to have test servers put in place. We would often rely on data being loaded from other systems. As is often the case, no project team wants to push out go-live dates, so any delays in development or server setup typically results in reduced time for testing.
Okay, we got our servers in place and tasks are starting to be completed by the developers. Time for testing and inevitably finding defects. We would document these defects and hand them back to the project manager, business analysts, and developers to be reviewed and fixed. From time to time, the defects we opened would be closed as a “non-issue” or the dreaded “won’t fix.” As it turns out, not all defects have the same priority. Some get closed because of their lack of impact on the system and the availability to have the defect addressed. Others are closed simply because even though it worked differently than documented, the unintended result was deemed better than first planned.
My team was heavily integrated into the projects we worked on and certainly had influence on decisions being made, but in the end we couldn’t control how much actual time we had to test, and that all the reported defects got fixed. My original idea of making sure the system was defect-free all of a sudden seemed much harder than I optimistically anticipated.
Reevaluating the Purpose of Quality Assurance
So it made me rethink the purpose of our team. After a lot of thought and continual improvements made by the team, what became clear to me was that our purpose as a QA team is to provide an unbiased assessment of the state of a system.
Having this clarity puts a different perspective on how a QA team goes about doing its job and how the rest of the project team interacts and makes the most use out of the QA team.
It is critical that a QA team is unbiased. Developers working on the project certainly cannot be considered unbiased. Too often developers only know how to test what they coded. Ideally, if they were aware of how to break something, they would have coded against that from the start. Also, they may choose to ignore areas of testing simply because of their own time constraints. With complex systems with multiple developers and various interfaces between features, some things don’t get properly tested by an individual developer due to an overlap of work. Project managers can be good testers, but again, they have a bias in that they usually are responsible for ensuring delivery. They also may overlook things for the sake of meeting a deadline.
A QA team, on the other hand, should be made up of members who are not only trained in finding defects and ensuring everything works as expected, but because of their position on the project, can be objective in reporting what they find.
Here are a few more best practices I’ve found for each party involved in development and testing.
How to Make the Most of Your Quality Assurance Team
If you are a project manager, work with you QA team to understand:
- How much development has been completed to a state where it can be used and tested?
- What has and has not been tested?
- What areas of the application have more defects?
- Is the project ready for turn over to the next phase (User Acceptance Testing, beta testing, etc.)
If you are a business analyst (BA):
- Advise the QA team on the most critical areas of the application.
- Have use cases well defined so QA team members know how to construct real-world test cases.
- Allow QA team members to review requirements and provide feedback. They can not only find defects in software, but also may find missing or unclear requirements.
- By all means, test alongside the QA team.
If you are a developer:
- Ask QA team members to set up test data while you are developing and have them share test scripts with you.
If you manage developers:
- Consult the QA team to advise you on which developers need extra training, and in what areas they should be trained.
If you are a QA team member:
- Use a Master Test Plan to clearly communicate to your project team exactly what is going to be tested, what tools you will use, and what you need from the team to accomplish this.
- Work with developers. Do what you can to speed up their development by creating test data, and testing early and often.
- Work with BAs to know what is most important and how the users will interact with the system.
- Have clear reporting to the project team so they know exactly what has and hasn’t been tested and how many defects you are finding.
If you are member of a software development team, you will get more from your Quality Assurance team if you don’t just view them as a team that finds bugs. Leverage them to review and provide feedback on requirements, setup test data for developers, and provide a true representation of the state of the software.
