The Testing field (and the development) in Software is in the midst of a great transformation. The phases of writing test plan, test scenarios, and test cases following the traditional waterfall model is all passé. Now organizations are not only expecting shorter development and release cycles but also increased stability - functional, usability, performance and security. Applications (especially retail ones) increasingly have widgets seeking user feedback on the application which further results in frequent and unexpected UI prioritization. The new model now requires faster and lossless conversion of product ideas into deployment.

With the significant lowering the cost of deployment of applications (available over cloud), and need to support both web and app versions simultaneously, both QA and Development models are metamorphosing. Due to rapid deployment and lower cost of marketing digital products, the applications now aim to target a wider customer base in a shorter time-frame. This has changed the mode of development to API based development, i.e. write an API first and then build the front-end (Web and App) to call the API. Likewise, a lot of QA activities are focused on API testing (covering, functional, performance, and security).

The Test engineers are expected to address multiple areas simultaneously: UI Usability, Security Vulnerability Testing, API Performance. This has significantly amplified the scope of QA from before and also mandated them to participate in all phases of SCRUM cycle and Security Provision primarily addressing the OWASP top 10.

Open Source Tools To the Rescue!

With the increasing expectations on the entire Product Engineering team on faster and greater quality, at a low cost, the open source framework has come to the rescue of the entire Development and QA teams like never before.

API Testing

The goal of the API Testing is to test the Business Logic Layer of the application thoroughly, inspect the response, latency in various conditions and various loads. API testing includes 4 parts: Functional API testing, Performance, Load & Stress Testing, and Web Application Debugging.

Functional API testing

This can be done manually or through automation. But with Sprint duration coming to typically 1 or 2 weeks, QA is typically expected to automate the key APIs so that this can be tested as part of Continuous Integration during check-in as well. If the code is also instrumented, then we get coverage results post check-in of a branch. It is easier to automate API, as their signature and business logic, do not change as much as the front-end.

Web Application Performance, Load Testing, and Stress Testing

No API testing is complete without checking the processing time of the API. Typically in Web Application testing, you would inspect the latency under varying concurrent conditions (called as threads). For key APIs performance, testing is done as part of the routine release. Load and Stress testing are done in all the releases, but during a major feature sets release, they would be tested.

Web Application Debugging

Many times QA is the first party to confirm a production issue. Just being able to reproduce the front end bug is no longer sufficient. QA increasingly goes the next step. Is there anything wrong in the Request sent to an API? Are the responses as expected? These issues are debugged by QA and the analysis along with RCA, then passed on to the developer

Security and Vulnerability Testing of Applications

Security Testing is typically done by a specialized team. The key areas that are tested are on Data, and API security, and typically stress on top 10 OWASP (Open Web Application Security Project).