In DevOps, the ability to release software fast, sometimes multiple times a day, is imperative. Developers must be ready to conduct and complete testing in minutes, sorting out whether software is ready to advance to the next phase or if teams should move on from the project. Detecting and resolving bugs before a release enters production is critical to the software development life cycle (SDLC) — and so is incorporating a test phase in your processes.
Automated testing tools are needed for this, though the type varies based on the app being built. For example, tools like Newman are great for testing API public methods. JUnit or Jest are best for unit testing of code and components. Playwright or Cypress is ideal for those full E2E (end-to-end) test implementations. You can also bring in test management tools like TestRail, which can provide reporting that’ll keep stakeholders aware of progress and an application’s maturity.
Regardless of which tool is being used, an organization’s singular focus must be on quality. Testing is no longer the sole responsibility of quality assurance (QA); the entire engineering department should be involved and accountable. This shared responsibility model produces the most reliable results, correcting problems before they take root and waste investments down the road. It also speeds cycles for more continuous software delivery, with automated testing reducing the chance humans will fail to catch and address issues.
The Test Pyramid
A popular concept in software development is the test pyramid, a framework used to guide processes. It consists of various testing layers that address aspects of functionality, performance and reliability. The following list looks at the key layers, widely used test types and the benefits they offer.
- Unit Tests: These tests focus on a single unit of work, typically a method or component. They are easy to conduct, inexpensive and offer a first line of defense when it comes to code quality. Ideally, these tests should be done during the build stage.
- Integration and API Tests: These tests validate the ability of the software being developed to integrate with systems, otherwise it will be unusable. This usually sits in the realm of developers and QA but can vary based on company structure.
- UI E2E Tests: These are the most comprehensive tests, necessitating the full integration of your systems including the frontend, backend, database and networking. These are typically written by those in QA, working closely across business lines and product owners. They are the costliest of the tests and require more time and maintenance, especially as business needs and test scenarios evolve. Focus must remain on the E2E tests — if overprovisioned, teams can slip back into API or unit tests and the pyramid could flip, which will dramatically increase overall costs.
Assigning Automation
It is not easy to test applications manually. Ensuring it is done right over and over again while preventing human error is next to impossible, never mind consuming a lot of time and expense. This is why automation is now used throughout the testing process, right from infrastructure orchestration through testing code.
Developers should be tasked with writing unit tests and integration tests. Quality pros should handle the writing of UI E2E tests. Test scenarios should be created by product owners. The test discovery phase, usually done manually, would be a prerequisite to the automation phase.
Implementation in Action
The test phase can be conducted with various tools and services that exist today. For the sake of an implementation example, let’s look at one of the most popular offerings available, Amazon Web Services (AWS).
This entity offers AWS CodePipeline, a fully managed continuous delivery (CD) service for creating pipelines, orchestrating and getting updates into your infrastructure and apps. Not surprisingly, it works with their other DevOps services including AWS CodeDeploy, AWS CodeCommit and AWS CodeBuild. It also plays well with third-party action providers like Jenkins and Github.
As a result, AWS CodePipeline functionality includes such capabilities as:
- Detection Option: This begins a pipeline based on the source location of the artifacts — a by-product of development used for tasks ranging from function descriptions to risk assessments. AWS recommends using Github webhooks, as well as Amazon CloudWatch Events for stored artifacts.
- Disable Transition: A transition feature links the stages of a pipeline and can be enabled by default. If you don’t want to automatically proceed to new stages, simply click the ‘disable transition’ button to halt the ongoing execution of the pipeline.
- Adding Stages: With AWS CodePipeline, you can edit a pipeline to introduce a new stage, provide updates to an existing one or remove a stage entirely. An edit page enables you to add actions serially or in parallel to existing activities. This functionality makes a pipeline more flexible and easier to expand.
- Approval Action: Using this functionality allows management of the pipeline stages. For instance, if you are waiting for someone’s approval during deployment, this will put a hold on the pipeline until approval has been granted.
No Resting for Testing
No app should ever be released into the wild without a test phase. When developing this, minimize human interaction in processes, enlist automation and research the tools that will make it all happen. Remember, the entire development ecosystem — coders to engineers to QA personnel — should be involved and have some stake in testing. It is up to everyone to ensure the test phase is in place, flexible and that outcomes are bulletproof.