Skip to main content

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 

For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.

I was wrong…

Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.

Our team work in one of several delivery groups and with this comes multiple challenges;
  • Silos 
  • No single environment strategy 
  • lack of communications
  • Varied ways of working. 
And thats just to name a few, which is interesting when all delivery groups have the same end goal.

Maybe it’s just to my ignorance but there are still a number of delivery groups that work in linear sequential life cycle model with extensive upfront planning and in-depth documentation ‘Waterfall Approach’ meaning each phase must be completed before the next phase can begin and usually ending with a large exhaustive test phase at the end. For these delivery groups this is made increasingly harder as there are no CI tools in use.

I want to give an overview in to the ways in which we work throughout our cycles from my perspective as the Tester. 

Firstly, all organisations view testing as a role within their teams, and let’s be honest if it wasn’t a specific role then I wouldn’t have a job! However, I view testing as an activity that is encouraged by the individuals in those roles.

I will always encourage testers to ‘shift left’ and by this, I mean testers should be involved as soon as possible because this is not always evident in other areas:

Shifting left is, cost effective, increases test coverage, saves time, is beneficial to the team’s relationship and contributes massively to the reduction of bugs introduced to the production environment where issues are expensive to fix.

I was at a conference in Brighton 2017, Amy Phillips did a talk on where testing fits within Continuous Delivery and I believe her diagram illustrates this perfectly:

I wanted to give you a view of some of the practices that me and my team ‘endeavour’ follow:

Tracking workloads - In our team we track our workload using Jira, creating tickets and moving them across the board as appropriate. We have the following columns:
I don’t for a minute believe our board is perfect but at the moment it works for the team and demonstrates progress to people outside of the team on features. But if it was solely up to me, I would change this:

I feel this demonstrates a more collaborative approach and we could utilise our agile ceremonies or regular demos to communicate progress which would involve our stakeholders and be more effective. 
99% of our tickets that go on JIRA in our work space are elaborated by the team and acceptance criteria for business functionality is detailed in the following format:
Scenario Successful cash withdrawal:
GIVEN my bank account is in credit, and I made no withdrawals recently,
WHEN I attempt to withdraw an amount less than my card's limit,
THEN the withdrawal should complete without errors or warnings

Pairing - is encouraged... We create pull requests, but we try to avoid having end of Dev/Test code reviews as a task as this slows us down and creates barriers

Test Driven Development - Tests are written both by developer and tester, preferably in conjunction with each other, throughout the development of business functionality, never an afterthought!

Regular Delivery – We strive to start by building the smallest unit of value possible and release to production as early as possible but with usable functionality. For us this is made possible by our build/deploy/test/release pipelines. 
We have the ability to build, deploy and test in multiple environment in minutes rather than hours or in some cases days like some of the other delivery groups are challenged with.
At the moment we have downstream dependencies that holt us from promoting code immediately across environments, but this is ok, it’s just the click of a button for us to deploy when the rest of the program are ready. Being able to deploy multiple instances of a service without any impact is a huge benefit.
We also utilise monitoring and alerting to help us find problems which allows for rapid resolution.

Continual FeedbackWe regularly update on all types of testing we planned to do at the start of a given cycle and as you would expect, this changes regularly. We also use our agile loop to continually adapt working methods and feedback on progress daily rather than at the end of a cycle, our cycles being every 2 weeks.

Culture over Governance – We create an environment where
people “do the right thing” and if a law is needed then we see that
as a sign of failure of that culture. For us this creates self-managing teams, shared learning and understanding.
We also use feedback mechanisms above with cross-team activities such as community sessions to reinforce the message.
We still have ‘platform readiness’, ‘security assessments’ and approvals checkpoints prior to releasing but we aim for these to be more of a formality through good practice.

“We test in Production” – For us this isn’t a physical test but the utilisation of monitoring and alerting. We gather statistics from Grafana to indicate whether or not we have any performance related issues, we have alerting in place that fires emails and slack notifications and also use Kibana that gives us more granular details which allows us to react quickly. Use of such tools educates the team and highlights whether our services are fit for purpose. 

So as testers, what I would challenge you to take away from this is:
  • Shift left and be involved as much as you can
  • Make sure you track your work in an effective way, every team will work differently. But that’s ok
  • Be the service to provide information regularly
  • Make your life easier and implement pipelines
  • Use Production and learn from your services
  • HAVE FUN! 
I hope this gives a good indication of how the team and I are trying to encourage ways of working… It would be great to know your story too!


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…