I held a learning session with my team a couple of weeks ago about this topic “What Does A QA Do?” The reason is because I think as we are so much driven into the daily tasks and responsibilities to deliver projects and hitting deadlines, sometimes its good to take a pause and rethink, “What are you actually supposed to be doing?”
Who are we?
 
There are many definitions of the role. QA, tester, test analyst, test engineer. Regardless of what our official title is, I think we are simply part of the development team that help the team to deliver a quality and successful product.
What do we do?
 
Most would say we find bugs and raise them. Correct, but not just that. We link business requirements with technical design, into a quality end user product.
How do we do our job?
 
There are many technical terms for this, manual, exploratory, automation, regression, performance, security, etc. Firstly, we need to have the knowledge of a product manager to know what product are we building. Secondly, we need to have the knowledge of a business analyst to understand the detailed business rules behind each piece of functionality built. Thirdly, we need to have the knowledge of a developer to understand the system design,  and technical solution such as what does the code do, the data flow into the database, etc. Lastly, we need to be able to use the product as an experienced end user.
What type of bugs we find?
Most would think that bugs are software bugs, careless mistakes by the developers. This is only a minor part of it. Bugs can be:

 

  • Product bug – building the wrong product from the very beginning, wrong idea
  • Requirement bug – caused by lack of understanding of the business rules and outside the square thinking
  • Software bug – caused by wrong implementation
  • Environment bug – caused by the way the software interacts with an operating system, system configuration, database version, etc
  • Deployment bug – caused by sequence of deploying (e.g.: running a script prior update of code might break a system), code merge mistake, database backward compatibility issues
  • Performance bug – all the above bugs are eliminated, but we forgot to take into account that the system might break down under peak usage
  • Security bug – all the above bugs are eliminated, but we forgot that there are back doors or windows opened that allow intruders in to break the system and do nasty stuff!
Conclusion
I am not trying to over complicate things. Many would think QA only test. Yes, but a good QA does not only test. A good QA should have the following skill sets:
  • Good understanding of business knowledge
  • Able to think outside the square
  • Good communication skill with technical and non-technical stakeholders
  • Good team player
  • Good technical skills