Building great products is ensuring the products perform as expected. The quality of a product has a large impact on the customer/user experience.
I constantly hear developers/project teams calling testing or QA means “Send the build to QA and QA will find the bugs.
As company grows and evolves, we should align our titles to reflect what we actually do Testing or QA.
Some Quality professionals don’t agree when called QA as it is impossible to assure quality with the activities they do. However, others mostly seniors don’t like being called testers as they feel that they do a bit more than testing.
Some may believe that the terms can be used interchangeably, yet QA and testing are completely different. To understand why we are talking about it, it is worth understanding what each term means first.
Testing: The process of reviewing a system with the intent of finding bugs.
Quality Assurance: QA is designed to ensure that the process is adequate to ensure a system will meet its objectives.
And objective of any product is user satisfaction and user is not the client but the actual end user who uses the product at the end.
Everyone should be agreeing on the fact that “Having a testing component in your development process demonstrates a higher degree of quality”.
Are we focusing about that quality or we are just finding bugs or our processes are designed for our QA’s to find the bugs only?
Let’s figure it out why tester should behave as QA’s who are not just finding bugs but thinking out of the box to ensure the qualitative product.
Keeping the above discussion in mind, suppose testing is actually the process of executing a system with the intent of finding bugs only.
For instance, if a defect has been found and fixed, there is no guaranty it won’t pop back up. The role of QA is to identify the process that allowed the error to occur and re-engineer the system so that these defects won’t appear for the second time. The QA process verifies that the product will continue to function as the customer expects.
Though QC/Testing is absolutely necessary, QA is perhaps more. By the time you reach the testing stage which is just before deployment usually, for instance, fixing bugs becomes an expensive issue. Because of that, focusing efforts on improved QA processes is one of the best investments an organization can make.
By keeping Agile in our mind I think we should consider the ‘shift left’ philosophy, which is embedded in agile principles which says testing should be done as early as possible and in every stage of the software engineering process.
And with that a Quality personal can:
- Identifies what-if scenarios,
- Imagine future exceptions,
- Gaps in user stories/documents/questions/doubts,
- Some acceptance criteria that are not testable,
- Missing acceptance criteria’s
Thus preventing defects instead of finding them at the end.
- We are following small part of QC i.e. only testing but let’s start some practices As QA, let’s start planning some processes to avoid the defects by calling QA’s in kickoff calls and all the after discussions so that QA can have the same knowledge of the product and client expectations as PM or developers have.
- Along with finding defects let’s discuss and focus on the weakness in the systems.
- Let’s start creating checklists with priorities or Automated test scripts for regression and define the timeline for every set instead of writing a big document called Test Cases which nobody follows and it become a big detailed description of the product only.
Let’s try to make Quality checks as the combination of failure prevention system plus failure detection system and let’s start considering calling QA as first person in any project/product discussion.
Like with UI testing, there are many important parameters you should check while performing UX tests.