Blog

30 Days of Agile Testing! Day thirty.

Day 30:
What action does your team take on a red build?

I had to google the term ‘red build’ - but I can’t find anything relevant!
I guess it means, automated tests have failed (i.e. they’re red, not green).

Every time we release, a bunch of automated tests run. It’s all driven by Slack.
If everything’s good, there’s a whole lot of green ticks for each set of tests, and some really happy green emoji!

slack1.png

Each letter in that block stands for a suite of tests. Some are obvious - UT = Unit Tests, AT = Acceptance tests - et cetera. I’ll let the others remain a mystery :)

If something fails, then you don’t get the green emoji - and you’ll see some red X’s too. Here’s an example:

Slack2.png

In this case the ‘B’ suite of tests has failed (a visual regression). 


At this point, here’s what could happen:

A developer will chime in and say “that was me, I expected that to fail!”
Which is great - he can then go and update the test or do whatever he needs to do to make it green again.

If that doesn’t happen, one or more (most likely all) of the developers will look at the results of the particular test that failed.
At this point, it’s usually pretty clear which piece of work made the test in question fail.Once that’s been figured out, the developer can take corrective action.
Either - ship a fix on top of what they’ve already done, to correct the behaviour. Or, revert their changes and go back and fix it before trying again.

The alternative is the test failed for some other reason - resourcing issue, timeout - these things happen sometimes. If that’s determined to be the case, the test can just be restarted.


What does the tester do while this is happening?
Well, from my own experience:

  • sometimes I’m first on the scene. I can investigate the failure first, alert the right people or restart the tests as needed.
  • help assess the risk. Can we ship something quickly to correct this? Or is that too risky, should we pull out?
  • analysis - what was the cause of this failure - why didn’t it get picked up earlier in our pipeline?
  • finally, testing - if we decide to fix it on the spot, I need to make sure - it’s actually fixed, and - we didn’t undo the work we were shipping originally!

And that, I think, is what our team does on a red build.

I hope that’s been useful!

- JE

30 Days of Agile Testing! Day twenty-nine.

Day 29:
What columns do you have on your work tracker or kanban board?

Yeahhhhhhh.

Prompted by this days exercise, I looked at our Jira Kanban board for the first time in months.
To answer the question, these are the columns on it:

  • To Do
  • Requirements & UX
  • In Progress
  • Ready To Test
  • Verifying
  • Done
JIRA.png

But it says a lot, to be honest, that I’ve not looked at it for so long. In fact, I don't think anybody has - I notice our last two projects are completely missing from the board.

Simply: I don’t think you need a kanban board or scrum board to be agile, and having one certainly doesn’t make you agile.

I already know what our implementation plan is - even just a rough idea in my head is enough. I know what my team are working on currently, and I’m pretty sure they know what I’m working on.

The only reason we might need an up to date tracking board is if an external stakeholder wants some visual indication of what we’re doing - but - they seem happy with the feedback they’re getting.

So - 30 days of testing, my question in return is - do you need your work tracker or kanban board?

- JE

30 Days of Agile Testing! Day twenty-eight.

Day 28:
What learning culture exists in your company? How can you contribute to it?

Learning's a huge part of our culture, for those that want it to be. We offer heaps of opportunities, and I think most people seize them - you'd be crazy not to!

We have regular brown bag sessions, that introduce new features or concepts.
Every team member has access to LinkedIn Learning (better than Pluralsight, in my humble opinion)
We also get a pretty generous training budget.
It's my training budget that'll be sending me to TestBash in Manchester this year. Too choice.

But this culture also means giving back!
In fact, part of my job description reads:
“Volunteers for knowledge sharing or 1:1 sessions to teach new skills”

So far this year, I’ve run sessions on using web hooks, third party integrations, and how to use our visual regression tools.

My favourite session though, was a Hawaiian detective themed two-part session on using our API called…

wait for it…

magnum.jpg

MAGNUM API
(sorry that’s terrible)

After starting this 30 days project, I was inspired to put my hand up to run a brown bag session too - I’m not exactly sure what I’m going to talk about yet! Maybe how to get testers involved in the development pipeline earlier.

But any suggestions welcome - I know some of my co-workers are reading this…! ;)

- JE

30 Days of Agile Testing! Day twenty-seven.

Day 27:
Look into zero bug tolerance, is this something your team could do?

I’ve spent the last fifteen minutes really quickly researching the term zero bug tolerance!

postit.JPG

Which simply means - fix any bugs before writing any new code.
So if a bug is found, fix it before continuing with any feature work.

Researching this has brought on feelings of guilt as I realise I have a post-it on my monitor with work (bug hunting) I really should have followed up by now.

Zero bug tolerance is something we value, and it’s hard to implement sometimes, especially with deadlines. Fortunately we’re reasonably good at it.

Even when business reasons mean a bug can’t be fixed straight away, it’s never there for long.

But it’s super important. For the simple reason that the longer a bug exists, the more expensive it is to fix!

So - I’ve got some work to prioritize!

- JE

30 Days of Agile Testing! Day twenty-six.

Day 26:
What does your Test Plan look like, what format do you use?

Welp, September is officially over, but I'm determined to see this thing through. Only a few days to go, I don't think I've done too badly?

TestPlan.jpg

Anyway.

Test plan - really, I just work by a note / series of thoughts and go from there.

For a small project like the one we're working on currently, this is probably it.

For a larger one, this might be a higher level set of notes, and then be transferred to Confluence or something later to be shared with others.

Really, I think that's all I need - as things get done, I'll probably tick or cross out items on this page. 

It will get very messy.

- JE