That’s right. You read the title well. It is an eternal fight for a place in your company, in your team, in the involvement that you have with the software development and delivery to a customer.
A lot of people want in their company a QA team, but most of the people don’t know what they are talking about. What does having a QA team imply when it comes to changes in the process that you’re company is currently working in? Will they be a pain in the ass, or just “another thing at the end of the process to make the delivery slower”? Sounds like a bad thing doesn’t it? I assure you it’s not!
Let’s start by understanding what a QA does and what kind of knowledge should he have in order to actually do the job well. A Quality Assurance (QA) is a person who monitors every phase of the software development process so as to ensure the design quality, usability, and making sure that the software adheres to the standards set by the company. A software Quality Assurance makes sure that the new products developed by a company are working correctly before they are released to the public.
A software quality assurance engineer is someone that should be involved in all the phases since the planning and control, analysis and design, implementation and execution, evaluating exit criteria and reporting and doing the test closure activities. What the hell does this mean? Well it means that the job of a QA doesn’t start only when the developers start coding. It actually starts after the new idea for the new project comes into someone’s head and gets discussed between few people. Imagine that hein?
So let’s break it down a bit. A software quality assurance work starts when we have a new idea for a project and the project gets approved. A quality assurance should be able to understand what the entire project is about and the result and impacts it will have on the customer. Because they are visionaries, they should usually be involved in helping writing the right requirements in order to get the right characteristics in the project. They also understand the workflow the customers will have while using the product making it easier, hence, for the usability team to work on the best way of creating the concept of the new product.
After helping with this part, and because the Quality Assurance should have some software engineering knowledge, we are sure that all the requirements and acceptance criteria will be well understood by the development teams. So, we sat down with them and help them understand what they are going to start to develop.
At this stage, we can also start writing our test strategies (which include the test approach, a test plan, test monitoring, test conditions, test basis, the test cases and test suites to be developed and also the schedule for when will what happen).
While the developers are focused in delivering the working code, we as software quality assurance focus on writing automation to make our life easier when the developers deliver the code. This way, when they start delivering, we can run our automated tests, do our manual testing, increment more tests to our first sketch and deliver the results to the developers. Now this part can be tricky. We are part of the team, just like the developers are! We need to make them understand they we are friends and we all work for the same cause which is delivering the software in time and with the best results that we can achieve together! The communication between a QA and a developer must be really good in order not to accuse them of making mistakes when a QA finds a bug. It’s not a developer fault. After all we are all humans. We need to make them understand that is something
missing without compromising the quality of the team work. Remember we are not here to point mistakes from other people. We are just here to assure that the requirements are met (and the acceptance criteria too) in a way that we have a very good product to deliver to our customer.
After all the things are tested, bugs are fixed and everything is ready to be delivered, the quality assurance has the last word and should submit a report with the quality of the product.
So, why “fight for a place”!? Because we are everywhere in the software development process. We need to be part of it all. We need to have the courage to stand out and give ideas to make the product better. We need to understand clients, product owners, developers and business people. We are the base that keeps everyone together. Good communication is one of the skills that is absolutely necessary in a quality assurance. In the end, we are communicating with everyone and helping everyone, facilitating conversations between people and giving the final word if the product should be released or not.
Hopefully the companies will start understanding all of this. The QA Team is not just for the end of the product, is for every software development process life cycle.