When a developer is finished with a development issue, it must be tested. People often think the goal of testing should be to find all the errors. Well, it’s not entirely realistic. Actually, it’s impossible! Despite the title of “quality insurance” testers can never really ensure level of quality, nor can they be expected to find all the errors. The real goal of testing should be to improve the software. As at the end of the day we want to minimize the cost of fixing critical bugs after a release, minimize cost of handling customer complaints and pushing a patch in the production. So it is import to understand that Quality Assurance is a process, not a department.
Today there are basically two different components of QA role in FINN. One of which is “QA in a team” and the other one is of a “team without the QA”. The QA role today is often a safety net for many developers and teams. The role involves manual testing in the sprint, regression testing and writing Cucumber tests. In addition this role has some administrative tasks such as being contact person for the Release Manager, participating in the release status meeting, filling out the checklist of early / late shift, contact for Tech Support (E-journal issues), participating in status meetings at Call Center after release, and verifying the patch to production. Everything that’s listed so far is managed also by teams without QA. What we have seen so far, is that a team without QA delivers the same quality as the team with QA in developing an FINN application.
Then comes the question, how do they manage to do it?
They have the same responsibilities as the “QA in a team”, but they have different practices on how they manage the tasks (some have rolling QA role, others have a fixed arrangement but they are NOT dependent on one individual person).
If we want to deliver a good quality code, testing must become a central pillar of the development process. When I say the role of QA is dead, but development and testing together provides quality for FINN, by that I mean 
that the whole team should focus on unit testing, integration testing, system testing and functional testing (as part of the pipeline). This will build and provide quality from top to bottom in the product stack.
Despite back-end test automation, front end problems with web applications are always discovered by human testers, including issues related to browser compatibility or CSS flaws. This can be covered by focusing on exploratory testing, which is also done in a team with no QA.
The QA testers should rather concentrate on the planning of tests within their teams. They should focus on three things.
-
Attributes: Describes the high level concept testing are meant to ensure performance testing, usable testing, secure testing, accessible testing and so forth.
-
Components: Define the major code chunks that comprise the product. These are classes, module names and features of the application.
-
Capabilities: Describes user actions and activities.
We know it very well that we cannot test everything so there is no pointing in investing too much time in documenting everything either? And we know as we start testing things the schedule, the requirements, the architecture etc are going to change. But the greater benefit is that whole team takes the responsibility for the quality, quicker feedback, tests documenting the code and not the least satisfied customers.
Written by Vivek Sharma Test Manager at FINN.no
Tags: quality testing