Arinze Obikili

In any software organization, team or group, the ultimate goal is to produce and release quality software that has a benefit to the market. More importantly the software has to be user friendly, durable, and reliable. The latter is where QA comes in. There’s no use in producing a great software product in theory but is practically not reliable or user friendly. i.e. bug-free, and performs at the same rate at scale and over time.

For many organizations, testing software can quickly become a long and expensive process, and this ultimately could lead to delays in releases and lengthening release cycles. To avoid long release cycles, long hours testing, and reduce production defect leakage here are some QA best practices that from my experience can help mitigate these factors:

Think QA and Not Just Testing

Each QA’s role should be to think in terms of overall quality, which includes but is not limited to testing. This means QA should begin to understand and think of potential risks, and gaps earlier on in the software lifecycle. In an agile methodology this means attempting to identify gaps during story grooming sessions, analysis of acceptance criteria and sprint planning.

A popular saying in QA is that it’s cheapest to find a bug during requirements analysis, and most expensive in production. With Dev, QA and UAT getting progressively more expensive respectively. So identifying bugs earlier on in the the software lifecycle will ultimate lead to money saved.

Define Your Strategy Early

This goes without saying but having a high level Test Strategy, and process aids in the efficiency of how the QA team will perform overall. Included in this Test Plan should be what methodology your group follows (agile or waterfall), key contacts and stakeholders, test case repository and management system, bug tracking mechanism, integrations with other applications, functional and regression testing plan, performance testing needs/strategy and of course your test automation strategy.

Having this strategy defined earlier on in a project lifecycle helps anchor all QA engineers to defined strategy, and increases overall efficiency.

Implement Test Automation As Part of Regression

As features get developed/tested, the number of test cases created will continue to increase. This can make regression testing a challenge if tested manually as the team begins to look at hundreds/thousands of test cases to re-execute before any release. This is where automation gets its big return on investment.

Depending on the complexity of the application under test, define an automation strategy that is effective, and ultimately efficient. Ideally, test automation should be started while functional testing is also ongoing. In an agile set up, test cases will be automated within the same sprint as they are developed and tested. By the time you’re ready for a release, you should have a significant amount of your tests automated and already executing, thereby cutting your regression overhead significantly. In addition it’s a good idea to have your already automated tests run daily or weekly. I shared my ideas on automation strategies in a separate post here.

Use Analytics to Capture Trends

Multiple test management systems now have analytics capabilities built in them. Enabling these features can help the team determine key test metrics like bug distribution, how quickly bugs are resolved, test execution results over time, and in some instances execution time. Other analytics capabilities that can be used are log management systems like Splunk and Greylog that can capture the frequency of specific errors in an application over a certain period of time.

This data will help the team to highlight problem areas, frequent components that break, and develop specific tests to target them.

Don’t Forget To Engage Performance Testing

In the early phases of test planning, it’s a good idea to begin to map out what performance testing will look like. While performance testing typically doesn’t happen until the product is stable, early planning and understanding of the application by the performance testing team (you should have one) will make performance testing more efficient.

In more mature environments, the performance testing team can also utilize some of the API and UI test automation scripts for performance testing, thereby reducing scripting time and ensuring accuracy of scenarios.

Choose The Right Environment

This also goes without saying but choosing the correct environment for the appropriate phase of testing is a key good practice every organization should have.

That is to say, a QA environment for QA functional tests, a performance environment specific for performance testing and subsequently Stage/UAT. Most important, avoid testing in the same environment as Dev as the frequency of changes, and instability will lead to inaccurate test results.

Maintaining software quality while keeping up with the demand of frequent releases is a key indicator of how well a QA team is performing. A high performing QA team should think outside the box on how to improve processes to maximize efficiency. Additionally, engaging other teams members (Dev, DevOps & Product) in these practices to varying degrees improve the overall quality of software being delivered to customers. Following these best practices is a quick way to shorten development cycles for your team and your customers, and keep your team members engaged and motivated.