The Misconceptions Around Quality Assurance

The role of being a quality assurance analyst involves doing exactly that – delivering high-quality solutions to clients. Yet, within this delivery, people often have differing expectations. Within our industry, there are misconceptions surrounding the role of a QA analyst. In this blog, we will unpack these misconceptions and outline what being a QA is really like.

QA is Not Just Testing

Quality assurance is essential at every stage of a project, so that a solution or service can be successfully delivered to a client. The QA analyst should be involved from the initial requirements gathering stage, to create a foundation on which to build the best possible solution delivery. If quality is emphasised from the start, then testing will be better.

A steady stream of communication should occur from the outset, as this will reduce the unknowns and eradicate multiple questions. At ClerksWell, the communication starts from the account manager and continues through to all other resources working on a project. We have internal project kick-off meetings, detailing the project so everybody involved defines and understands their roles. The meeting also identifies risks and dependencies that may affect the project. As the project evolves, daily stand-up meetings occur, keeping everybody updated daily as the project goes on.

The quality of the solution delivered is a direct representation of what we stand for as a company; if the quality of work is assured from the beginning, this will contribute to the constant delivery of good solutions, and demonstrate that the company is one built on high standards.

A Pessimistic Approach

There is a certain joy in identifying bugs and faults in a system as an analyst. By doing so, you demonstrate your attention to precise detail and draw attention to your understanding of the solution's functionality and requirements. The approach to identifying bugs should be simple - work to break down the system but hope that you don't - emphasising the latter here.

A QA analyst should always believe they will find faults and be driven to find them. The mindset of wanting to find a fault is not a pessimistic one. This gives you a high level of concentration in making sure you do everything possible to make sure the system is flawless. If you do not identify a bug or fault, you should be satisfied that the project can be signed off.

The Adhoc Master - More Than a Tester

A QA analyst is so much more than being just a tester. There is a need for QA within various roles:

• The QA analyst can act as an assistant PM if needed; this will help in maintaining control of the project.

• The QA analyst is in the perfect position to become a guide around what is being delivered, as they have a strong familiarity of how a solution works through the testing process.

• The QA analyst can also become the user liaison when the solution is at UAT stage. This helps users to differentiate between what is a bug and what isn’t.

Requesting Within a Clients' Requirements

The QA can request changes to the functionality or design of a solution within the clients' requirements, if they feel this will help with quality an provide a better user experience. The keyword here is 'request', as such matters would need to be discussed with the project team and agreed upon before taking it to the client. 

In doing so, this will demonstrate to the client that there is a strong commitment to ensuring solutions are delivered to a high standard. The QA should bridge the gap between business and the user.

To find out more about our QA work, and work with some of our experts, get in touch.