Welcome…

I use Agile & Lean principles through a quality lens to help teams improve communication, achieve closer collaboration & faster feedback.

Each of these helps increase throughput & smooth delivery of value to customers which enables you to validate your ideas & assumptions sooner.

I predominantly find myself helping development teams improve their Agile testing to remove bottlenecks. This includes training in testing ideas as well the soft people skills to help teams grow together.

Do any of these situations sound familiar to you?

Testing is squeezed in at the end of the delivery cycle

How do you test throughout the development cycle to bake quality in?

The wrong thing gets built

You wait for ages & when you finally get to see the requested product, its not what you asked for - how do we know what is the right thing?

Testers see themselves as the gatekeepers of quality

Why should they be responsible for “signing off” software? They didn’t ask for it and they’re not funding it therefore why should they give no/go decision?

Testing is a bottleneck & hindering our iterative development

We’re trying to be more agile in our approach, but our testing is preventing the short cycles & frequent delivery we’re striving for.

We don’t need Testers, we’re Agile

Yes, your development cycle may be highly automated but there is so much value a Tester can add to your time - let me show you!

Where can you discover more about me?

Come & take a look at my thoughts & ideas on Twitter

Why not get in touch to see how I can help you?

Duncs

- I test - I teach - I learn -

Establishing a Continuous Integration Pipeline Part 1

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.

Part 2 - CISIG Kicks Off!

Part 3 - Gaining Traction