Changing market trends and demands provide the impetus for new business models. As business models evolve, fortune favours the brave, with bold strategies needed to take customer service and user experience to new heights. Software development and testing have come a long way as the technology has advanced from desktop applications to the web and mobile, and from the waterfall model to the ease of continuous development and release offered by Agile development.
The past decade has seen some major changes in testing. Just as the IT industry is evolving and software development is producing new ways to meet demand, testing is also keeping pace. Waterfall models of software development life cycle and requirement gathering were once a key part of the test process. Later, Test Driven Development and Behaviour Driven Development came into the picture as part of the Agile development approach. The process and strategies of testing itself have also changed with the introduction of new testing tools.
Let’s look at some of these new testing tools and explore how they enrich the testing process.
Selenium is the most popular tool right now to test web-based apps with user interface (UI). When we start adding more functionality to an existing app, automation is needed to eliminate human error and reduce costs against a backdrop of falling quality assurance (QA) resources. Then there are tools to automate apps installed on desktops, and others on the market such as SOAPUI and Rest-Assured to test services installed on remote servers.
The benefits include removing the need for additional resources via automation, with performance testing a must-have before launching heavy apps to prevent crashes and shutdowns, and faster, more accurate and more reliable testing for repetitive, large-scale tasks that would be challenging if attempted manually.
Putting QA into perspective
The quality factor is mainly governed by parameters such as safety of usage, the criticality of the product or the project, the importance of accuracy and precision, and finally, market competition.
Project size is another factor that determines QA and testing. Large projects might need larger testing teams with further subdivisions for manual, performance and automation teams. On the other hand, a small project might only require a single software development engineer in test (SDET), who can manually test the business-related functionalities, write and maintain test cases and automation scripts and may even lend a hand with deployments and releases.
For any upcoming business project, identifying the appropriate level of quality is of paramount importance – and this all happens prior to the QA process.
Identifying the appropriate level of quality is a job for the Product Owner (PO). How they do it boils down to a question as simple as “how critical is the product?” If a defect has the potential to cause major losses, the PO will allow more time for testing before a critical release. No QA manager should be involved while the PO is still trying to evaluate the need for testing. Should the PO decide there is a need for testing, the QA manager is consulted to discuss the process. At that point, QA resources are determined, and the test plan and strategies define at what stages and how much testing will be done, along with the tools to be used. These depend on the application technology, the size and scale of the application, the need for and extent of manual testing (both at the initial stages of the project and later on, too) and automation testing and performance testing, once the product has become fairly stable and starts to grow. The QA manager and PO can also discuss things like bug reporting techniques and tools and ways to test bug fixes before, during and after release.
This provides an idea of the acceptance criteria and the extent of testing required. This in turn indicates the testing strategies and methods that should be employed to meet requirements, deadlines and budgets. The final piece of the puzzle is how the QA and developer interact.
Reaching the right level of communication between a QA and a developer depends on:
1. Having the same understanding of the requirements – that is, how particular functionality should work and what it should do, as per the client’s requirement. This way, the QA knows what and how to test what the developer implements. QA and development team members can participate in requirement gathering sessions with clients or business analysts to achieve this.
2. Being on the same page with respect to the current status of the project and the future plans and action so that developer and QA are in sync to optimise delivery.
3. A shared understanding of bug reporting and fixing processes.
4. Synchronisation for product release. For Agile projects, where bug fixes are being released weekly, this becomes critical.
Anyone with spare capacity can play the role of scrum master. But if a QA takes on this responsibility, the nature of his role, asking questions and finding defects, will help them to become more reliable and open and develop other soft skills. It also provides a valuable strategic perspective on risk, since software projects’ risk mitigation programs largely rest on QA.
Having the right mix of QA (testing team, testing strategies, testing tools and methods) can be key to achieving the right level of quality.
Quality worth waiting for
Very often, the importance of the QA is not fully understood – not just by clients, but sometimes by QA teams themselves. The testing process can appear to be cumbersome and a barrier to the pace of development, but it has the power to uncover high-priority, business-critical bugs.
The art of communication is another domain where the QA should aspire to excel. The QA can play a vital role in avoiding communication failures, while a scrum master is an example of an approach that tries to bridge the intra and inter team communication gaps.
Can we help you with QA and software development? Then don’t hesitate to contact us.
