A vast number of development projects and teams are now facing the challenges of having a sacred number of QA resources available, averaging at one tester to five developers per team.

As projects are being delivered at a rapid pace, along with changing project requirements, QA resources are becoming more and more valuable.

Today, there are still many delivery teams that are far too focused on the strict manual process of test requirements, planning, analysis, test case design, implementation, execution and closure with many manual and approval processes in place. Over time, costs increase and the quality of delivery decreases. Modern test lifecycles should now follow a leaner and rapid approach to accommodate the growth of automation test capabilities, to be embedded into agile and continuous delivery teams. Here are a few insights into implementing a smoother, cheaper and faster test lifecycle:

Test pyramid model approach

The test pyramid follows an approach as a model in modern test lifecycles while emphasising on finding bugs early, cheap and fast within the test lifecycle.

The biggest chunk is that 70% of tests written should be unit tests, which are primarily written by developers to test their own code and catch bugs early before reaching QA teams. These tests are crucial as they provide a fundamental of test coverage that reduces the number of major bugs found later in the test cycle.

When climbing up the pyramid, the next 20% should be allocated to integration test, which is usually written as systems are integrated with other dependency and third-party systems, where mock services and automated virtualised environments could be utilised to fully fill in coverage where unit tests may be missed.

As we reach the top of the pyramid, the last 10% should focus primarily on functional UI testing. These tests are brittle as any UI enchantments can easily break test packs, therefore, should ideally be automated on building pipelines, allowing maintainability and further exploratory test efforts as iterative builds progress. Through the test pyramid model, teams are able to save cost and time in their test cycle, by increasing test coverage at the lower end of the pyramid, as well as eliminating any bugs exposed as we move upwards into business-centric UI test layers.

BBD test lifecycle

Following on from the evolution of the ‘TDD’ test-driven methodology, the newly born ‘BDD’ behaviour driven development has transformed agile teams and is almost becoming an industry standard for many organisations. The methodology complements well and replaces the traditional way of writing test requirements and the analysis phase of the test cycle where business analysts, project managers, architects, developers, and testers are able to provide direct inputs and structure test acceptance criteria in ‘Gherkin’ language, as well as the ‘given’ ‘when’ ‘then’ format for agile user stories.

In essence, having BDD acceptance criteria/test scripts act as a replacement to the gathering test requirements and analysis phase, eliminating any misunderstanding between team members, as well as removing any unnecessary sign-off for approval processes creates an efficient test cycle.

Further to this, by leveraging automation test capabilities such as ‘Cucumber’ and ‘JBehave’, the potential of the methodology can be maximised, especially when writing technical test scripts. This ties in greatly with test reporting, where there are BDD reporting engines such as ‘Cucumber HTML Reports’ and ‘Serenity BDD’ which would take the pain away from traditional reporting and test closure as it creates manual test reports towards each test cycle. These reporting engines are user-centric professional test reports of test scenarios, steps, coverage, and execution, which should be shared with teams and stakeholders.

As you can now gather, using BDD methodology in the test lifecycle greatly improves the communication bridge between business and technical teams to improve test implementation, execution, and reporting processes through its simple common business language concept.

Continuous integration in test lifecycles

As development teams integrate into the continuous integration/continuous development space (CI/CD), this has now become the new catalyst to maintaining a productive and efficient test cycle.

CI/CD heavily focuses on the implementation of automated build pipelines, compared to a traditional test cycle, where most of the test and build pipelines requires tons of manual processes in place. CI/CD would not only tackle the challenges of QA resources but also frees up the time to enable functional testers to work on other activities such as exploratory testing to deliver and produce bug-free deliverables.

When diving into the traditional process of test lifecycles, we can see there are many test artefacts and documents created to support test activities and provide assurance to stakeholders. Some may think, moving to a leaner approach may require eliminating test artefacts and documentation – well, not exactly.

Living documentation

Creating a leaner test cycle does involve reducing unnecessary documentation and approvals, however, rather than removing these practices, we are creating a new breed of ‘living documents’. One where the traditional test documentation approaches of ‘word’ and ‘excel’ tables are impractical, which no one else reads.

The goal is to achieve sets of living documentation and artefacts that would utilise toolsets such as JIRA ‘Confluence’ to create dynamic test documents that, perhaps, can be linked to daily scrum backlogs with the latest status and updates from the team; along with intuitive macros and user tagging/commenting capabilities. Essentially, creating your own ‘Facebook’ page where anyone could contribute. Through the living documentation, it enforces teams and stakeholders to take part throughout the creation and modification of documenting the process in each iterative delivery milestones with the latest reporting status coming directly from the team, which could save hours of unproductive back and forth email communications.

Each team will be made up of different resources, goals, and processes. However, by following some of these principals, while leveraging market automation capabilities, there will be significant improvements in the long term, once a leaner test lifecycle has been shaped, transformed and achieved.

Written by Gabriel Ng, Senior Test Automation Consultant at UK Home Office