In our January blog post, we talked about the importance of asking questions about new features and building shared understanding among the team. Shared understanding should extend beyond feature behavior to other concerns. For example, once we have built a feature, how do we get it into the hands of our customers?
Towards continuous delivery
Many agile teams are practicing continuous delivery (CD) or are working towards implementing it. The goal is to get changes and new features into production safely, quickly and sustainably. The backbone of CD is the deployment pipeline: all the steps a change needs to go through from the time it is committed to the code repository trunk or master, to the time it is deployed to production. There are many questions we can ask about our deployment pipeline to make it better.
One question testers or business stakeholders might ask is, "When we need to fix a critical production problem, how long does it take from when the programmers check in the code for the fix, to the time it's actually in production?" This is a great time to start drawing on a whiteboard or lining up cards on a table with team members who understand the process. Does the ‘hot fix’ go through the same automated tests as a normal code change? What about exploratory testing? What pieces are automated and what requires human intervention? Do we skip some steps to save time?
Understanding your team's pipeline to production
Of course, you also want to learn about the normal steps each code change goes through in your team's pipeline. Ask a programmer or operations specialist on your team to walk you through the process. The pipeline can consist of both manual and automated steps. For example, when a code change is checked in, the first step might be static code analysis to see if the code meets team standards. The next step might be running automated unit tests. Manual steps might include exploratory testing. Deployments to test environments could be automated or require human intervention.
Fast feedback is important, so ask what your team is doing to speed up the automated regression tests and deployments to test environments. Can you do functional, performance and security testing in parallel? What can we do in a virtual environment? If so, what does that require? If your process includes user acceptance testing, do the users have their own environment and is it done in a timely manner? Are there tests being done by testers or developers that are candidates for automation? You can help your team prioritize efforts to speed up those feedback loops.
Testing the pipeline
Another important question is "How has the pipeline been tested?" A common misconception is that pipelines are simple and execute the testing, but don't need testing themselves. In fact, automated portions of pipelines include configuration files and scripts that determine when and how one step triggers another step, how team members are notified of results, and how artifacts are stored or deployed. Like any software, we need to test to make sure it does what we want.
We may hear statements like "DevOps teams are in charge of pipelines," but don’t forget that testing is an integral part of DevOps. Teams benefit when all roles, including testing, engage in improving pipelines to production. Just like our feature code, pipelines require analysis and testing to validate and optimize them. It's one more area where, as testers, we can work with our teams to mitigate risk.
Check the website for scheduled classes!
All public classes for “Agile Testing for the Whole Team” are listed on the training page . You can find when and where (or if it is remote), as well as the language in which it is being taught, and how to register.
You can also contact us if you want an on-site course or check to see the Training Providers closest to you.