Let’s start with the definition: Quality Assurance (or QA) are those activities we do to ensure that whatever project we’re delivering is at the required quality level.
Now for most people, those activities are all related to testing. And truthfully, whenever I think of QA and attempt to explain it to someone else, I go over my imaginary checklist:
- Test the new functionality to make sure it is working as expected.
- Test the new functionality to make sure all labels and texts have no typos and are grammatically correct.
- Test other related functionalities to make sure we didn’t break anything.
- Test with different users, make sure the new functionality has the right permissions.
- Test the functionality as someone who is not tech savvy (so click on things cluelessly) to see if I can break something and find a bug us techies wouldn’t find otherwise.
But here at inQbation, QA is a lot more than that. It starts early in the process of a project, pretty much since the moment we first meet the client. Whenever we start gathering requirements from the client, our quality assurance services start. With our QA hats on, we need to start clarifying those requirements, understanding what is it exactly the client needs and what is the quality level for those needs.
Project quality level
The required quality level will come out of the balance of three things: the requirements (scope), the time, and the cost (this is what is called the Project Management triangle or Iron triangle). Of course, everyone wants the highest quality for their project, but the quality level required depends on how much time and money is available for delivering the project.
After the requirements have been gathered, and their quality level has been defined, our next step is sharing this with our team of developers. We first create the user stories (we use JIRA for this) and then we have a video call planning session to discuss them with our team of developers. During those planning sessions, our team will give us feedback (mostly technical) and we’ll need to ensure that they understand the quality level required for each user story. Then they go on and do their magic.
Our testing work will start once the developers believe some of their work is done, or at the stage we call “Ready for testing”. Before starting to test, I usually run through my mental checklist (mentioned above) and plan what and how I’m going to test. After making sure everything is working fine (or reporting the bugs for when it wasn’t), I do one more test: I put myself in the shoes of the end user and make sure that the new functionality is clear and easy to use.
When we feel that some of the requirements are done (with the required level of quality), we demo them to the client. If everything goes well during the demo, we’re done and we continue with other requirements until we’re done with the whole project. But let’s be real, that almost never happens.
During our demo meetings with the client, they usually modify something in the requirement or they change the level of quality, and as annoying as it might seem, that is okay and is also to be expected. That’s how agile software development works, and as fierce practitioners of the agile methodology we embrace unforeseen changes in our projects. So, we welcome the new feedback from the client and we move on to define the new level of quality required before meeting with the team, then performing quality assurance testing again.
This process, or loop, repeats itself as many times as necessary (or as many times as time/money permits). This constant revision of QA is what helps us deliver great looking, easy to use and functional projects every time. So if you have a project that needs quality assurance testing services, then we’re here to help. Give us a call or send us an email for a quick chat on how we can ensure your project’s success!