Below, Julian, one of our Project and Quality Assurance Managers runs through the common misconceptions surrounding Quality Assurance, and answers how to deliver the best solutions possible.
The role of being a quality assurance analyst involves doing exactly that, insuring quality – 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. Based on my personal experience as a QA analyst, I will go through some of the main misconceptions below.
QA is not just testing.
From the outset of a project, quality assurance is essential at every stage, in order for a solution or service to be successfully delivered to a client. Crucially, the QA analyst should be involved from the initial requirements gathering stage, as this creates a foundation on which to build the best possible solution delivery. If quality is emphasised at the earliest stage, when the solution reaches the point of testing, the quality of that testing will be elevated.
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.
Pessimistic approach, not a pessimist
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. The latter here needs to be emphasised.
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.
For example, during a recent intranet build project. I found no bugs during the first three days of QA! My approach had to adapt and become more innovative as a result. I tried all manner of ways to break the solution. I covered all the user and content editor scenarios as well as real edge cases. Yet I still found no bugs! With faith in my approach, I was happy to sign off our ‘perfect’ solution so that it could be passed to the client for User Acceptance Testing where they confirmed that there were indeed, no bugs.
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 trainer around the solution that 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.
Here at ClerksWell, I have had the capacity to play many roles within different projects I have worked on. For example, I worked closely with the project manager, attending our weekly catch up meetings with Robert Fleming insurance broker (RFIB). I was responsible for all the Demos and conducted all the user training for the SharePoint site we developed for RFIB. I also stayed on the client site during UAT & the go-live phase to help with user education and handle errors that did not involve a technical fix.
Requesting within a clients’ Requirements
The QA can request changes to the functionality or designs of a solution or service within the clients’ requirements if they feel this will help with quality and provide a better user experience. The keyword here will be ‘request’, as such matters would need to be discussed with the project team and agreed upon before taking it to the client. Yet, in doing so, this will demonstrate to the client that, as above, there is a strong commitment to ensuring solutions are delivered to a high standard. The QA should bridge then link between business and the user.
To find out more about some of the work we do, check out some of our case studies here and get in touch here.
Think Quality , Think ClerksWell
