Part of my personal remit as a Tester is to ensure Testers can always test.
This post is the first in series of posts about my progress in setting up a Continuous Integration (CI) pipeline in my organisation
One of the teams I am working with is transitioning to the Scrum methodology to apply Agile principles. There are obviously several hurdles to over come, but the primary problem I have observed is the classic anti pattern of Scrum being a mini waterfall model.
Code is still being developed & delivered in stages, with the test integration phase being squeezed at the end of the 2 weeks sprint.
My primary approach to tackling this problem is getting the Testers proactively involved sooner. Some tactics I adopt include:
- Start by asking more pertinent & relevant questions in the planning meetings
- (Politely) asking Programmers for demos of the code on the Programmers machines
- Its OK to see the code before it is complete - so long as you understand what part of code is ready / testable & what isn’t
- Asking questions of the Business Stakeholders as & when questions arise
- Generally have more confidence in the value you, the Tester, provide in the sprint
I’ve laid the groundwork for these ideas with the team & relationships between the Testers & Programmers are improving, but we are still having the staged development & squeezed integration testing phase.
Another problem I’ve noticed is the length of time & the amount of effort it takes to get a build into a test environment.
We don’t currently have automated Continuous Integration. I have seen the advantages it has over the manual process of moving code & config changes between environments.
The greatest advantage for us Testers is that the “thing” that gets built at the beginning of the pipeline is the same “thing” that gets released into Production, having been through the Test environments.
If you want to know more about Continuous Integration / Delivery, I’d recommend you watch this video of Jez Humble, author of “Continuous Delivery”
Obviously there is the discussion over the value of the regression checks that get run in the CI pipeline which I don’t plan to go into here.
What I do know is that running a raft of automated unit, integration & GUI checks for core business logic (and understanding what those checks are doing) really adds to the Test Strategy & enables the Tester to spend more time exploring the darker corners of the system in a way a user/customer would.
So now I am tackling the problem of large time & effort needed to deploy code into an integration environment by exploring the use of CI.
I don’t have answers to the many, many questions I have & I know there are some people far smarter than me in the organisation so I have set up a Continuous Integration Special Interest Group (CISIG) to see if there is value in implementing CI.
This is going to be a long journey. I intend to record my experiences in this blog & also day to day thoughts in my journal - a new idea I’m trying out, like a series of micro blog posts.
My initial thanks go out to Amy Philips, Rob Lambert, Richard Bradshaw for their input in order to help me get this experiment off the ground.
Watch this space.