DevOps Enterprise Summit 2019: what went down

DevOps Enterprise Summit 2019: what went down

For many, the word DOES means nothing more than the third person singular present of do. No further thought is required. No light bulb moments. No slight gleam of excitement in the eye. Nothing. Does is does.

Unless, of course, you’re one of the few skirting around the outside rings or smack bang in the middle of the DevOps world.

For those within this world, DOES is the much-anticipated DevOps Enterprise Summit – a unique glance into the inner workings of DevOps. Everything from the latest tools and technology to product demos, data science and keynote speeches that left tech enthusiast’s hearts rekindled and fired up for the rest of the year. Although to be fair, the sock swag might have had something to do with that …

DevOps Enterprise Summit Stickers

Whilst we could spend the rest of the blog talking about the free mini chocolate macaroons, copious amounts of free stickers and CloudBees rather epic prize giveaway (every tech fan’s wet dream), let’s instead dig into the ten key messages that ECS Digital took away from DOES 2019:

1. Eisenbahnscheinbewegung

Eisen what now?! No, this isn’t another legendary word plucked from the creative geniuses over at Disney. Eisenbahnscheinbewegung is in fact a German creation (no surprise there!), pulling together “Eisenbahn” – a railway, and “scheinbewegung” – a fake movement into an impossibly accurate description of an influential constraint in digital transformations. Essentially, it is the fake sense of movement you get when you’re sitting on a train, watching another train moving next to you, and you gain the illusion that you are moving too.

In the context of DevOps, Eisenbahnscheinbewegung is a dangerous assumption during any transformation striving for a high-performance, collaborative organisation. The essence of DevOps is that you create a guiding coalition with shared responsibility at the core, enabling continuous learning and a behaviour change – not the easiest of tasks. But what if you didn’t need to change your behaviour, wouldn’t change be so easy then! By watching other teams begin to show new behaviours, people can gain the impression that they themselves are moving too and initiate the start of their own fake movement. Avoid the inertia this can cause by calling out Eisenbahnscheinbewegung and nipping it in the bud before the movement gains momentum.

(Eisenbahnscheinbewegung is also a fun word to try and get your colleagues to repeat really fast, multiple times…)

2. DevOps confessions

Holly Cummins‘ talk on the “Tales from the DevOps Transformation Trenches” did exactly what it said on the tin. It drew on the stories from attempted DevOps and CI/CD implementations, looking at common mistakes and the dangers of remaining too headstrong on what we believe to be the only way. Learn to take controlled risks, leveraging the benefits of a/b testing and continuous improvement to limit impact, learn and deliver incremental value.

DevOps Enterprise Summit

You don’t have one chance to get it right – unless you’re the Ariadne/Cluster 5 spacecraft, in which case once chance is really all you have… There is also argument to suggested that customers don’t necessarily have the appetite for continuous releases. Instead, ensure you are building a roadmap and bringing your customers on your journey – focusing on value-add and product improvement. If in doubt about when to release, remember the wise words of Reid Hoffman:

“If you are not embarrassed by the first version of your product, you’ve launched too late”

3. Employee engagement should be your competitive advantage

According to Richard James, your key business enablers are your culture, organisational agility and people. Employee engagement bolsters all of these, but championing employee engagement is about more than getting some bubbly in the office for ‘Fizz at Four’. It is about creating a culture and environment that fosters a mutual respect across all teams, strengthening your offering and providing something that your competitors will struggle to compete with you on. In the words of Joe Aho from Compuware:

“take care of your employee engagement and the cash flow will take care of itself”. 

4. Culture and calling out success

During DOES19, attention was drawn to Nike’s own transformational success, looking specifically at the impact of advocating a “thank you” culture and how this drove positive results in their distributed squads.

In the words of Chris McGinnis:

“culture eats strategy for breakfast”.

DevOps is a movement rather than a methodology which means that people matter more than technology. Recognise and celebrate the success of your teams / individuals and you’ll see a culture of collaboration ensue, because at the end of the day, “you have a far better chance of winning in life as team than as individuals” – Mehnaaz Abidi.

5. Data based thinking, because assumptions still make an ass out of you

Ultimately, data-based thinking gives you the information you need to make more informed, impact-controlled decisions. In the words of Gene Kim, “you do not want to be an organisation where information is hidden”.

Make your organisation transparent to encourage a culture where information is actively sought, messengers are trained – not shot – and teams can begin to learn from previous mistakes.

As well as transparency, make sure you have the tools in place to deliver the data you need to successful drive transformation. In the constantly shifting landscape of technology, continuous testing and a/b testing is a must. If you’re manually testing, you’ll only be able to pull data from the last time a test was made – and with the complexity of technology stacks and organisations as a whole, this could be months old. You also want to be giving yourself more data through experimentation. Not only will this help you know which pilot projects to scale, if an experiment shows your hypothesis is wrong early on, you have succeeded at reducing risk.

Last but not least, monitor your own transformation so you can begin to work smarter, not harder. You want to be continual measuring so you can support decision-making, enable better outcomes and remove blackholes created by unforeseen or futile tasks. In the words of Dominica DeGrandis:

“if you don’t track unplanned work, it’s invisible. It would be the perfect crime”

6. New kids on the block

 “At the current rate of disruption, 50% of the Fortune 500 are going to be replaced in the next 50 years” Mik Kersten. Whilst this predication can feel a little open ended – realistically, anything could happen in 50 years – the sentiment was mirrored in a statistic that came up at the Women of Silicon Roundabout:

“1 in 6 businesses will fail in next five years because they can’t keep pace with change”.

…an unsettling risk for those not willing to invest in an agile / DevOps way of working. With the pace of change in the technology sector, even those who have survived and profited from legacy technology stacks, a time will come – and has arrived for most – where this technology is no longer fit for purpose. Whilst some are on the front foot, many don’t realise quite how far behind their technology is until they see their competitors unsubtly eat into their market share. If these stats are trying to tell us anything, it’s that now is the time to change, because a few of you will be left behind.

7. Burnout – you work with canaries, not robots

Dr. Christina Maslach led what was perhaps the most relatable but least spoken about part of the technology sector: burnout. Given its high costs to employees and organisations, burnout has become an increasingly high topic in the workplace. While some believe burnout is self-imposed, empirical findings show that it is largely a function of the social environment in which people work – and is a warning sign that businesses should take very seriously. In the words of Dr. Maslach “our approach is to try to create more resilient canaries, instead of trying to figure out what is wrong in the coal mine.” Rather than setting unrealistic expectations on your team, address the toxicity of the environment and save multiple birds with one stone.

If you’re interested in this topic, our very own Ali Hill recent published a blog on his experience with burnout which you can read here.

8. IT might be Merlin, but there’s always a king Arthur

Whilst IT is the enabler, the digital wizard, the innovator, it rarely operates in isolation of the business. For IT to be successful in an agile transformation initiative, it needs the full buy-in and support of the business. Not only to enable cultural change, but to empower different teams to change at pace and scale successful products.

But there’s one hurdle. You won’t get this support until you can frame your ideas in terms that your business leaders can understand. Involve key stakeholders from the very beginning of the transformation to open up communication channels, then focus on outcome and value so they have something tangible they can buy-in to.

DevOps Enterprise Summit

9. Better Value Sooner Safer Happier

Jonathan Smart’s talk did one of two things. It delivered a clear explanation for the metrics we should be measuring the success of DevOps on. It also asked attendees to rethink their approach to DevOps. Rather than focus on scaling agile, Smart suggests descaling your work. Want to do an agile transformation? Don’t. Focus on outcome and value.

Essentially, Smart was talking about looking beyond the transformation, to the point that your language should change to adopt a more outcome-focused initiative. By changing milestone to outcome, project to product, plan to roadmap, you can begin to change the mindset of your organisation as well as the physical changes to your technology.

DevOps Enterprise Summit

10. Unicorn Project

We couldn’t do a summary of DOES19 without talking about one of the key influencers behind the event: Gene Kim. Not only is Kim a multi award-winning CTO, researcher and DevOps enthusiast, he has authored books with instrumental impact to the DevOps community including The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win and The Visible Ops Handbook. 

And now he’s thrown another book into the mix: The Unicorn Project: A Novel about Digital Disruption, Redshirts, and Overthrowing the Ancient Powerful Order. Focused on introducing the ‘five ideals’, Kim takes you on a journey, following Maxine – a senior lead developer and architect – as she faces rebel developers, dangerous enemies and a ragtag bunch of misfits in a race against time to innovate, survive and thrive. With many of our engineers still reminiscing aboutThe Phoenix Project, we can’t wait to get stuck in…

Those who attended DOES19 were given exclusive access to an early edition of the book – as well as a matching pair of the #UnicornProject socks. If you missed the DevOps Enterprise Summit, save those unicorn tears. You can pre-order your version of the Unicorn Project on amazon.

Concluding thoughts:

Feeling fired up by the DevOps Enterprise Summit to start driving your own successful DevOps transformation? Harness that energy, consider your roadmap, but be mindful of jumping in with both feet.

If you swung by ECS Digital’s stand during the conference, you will have noticed something rather unusual. This year at DOES19, we decided to focus on you. In particular, how we can successfully help you journey through The Great DevOps Rabbit Hole.

 

 

Designed to be challenging, agile and sometimes delves into spaces that nobody has ventured into before, The Great DevOps Rabbit Hole is not for the faint hearted, yet it is a journey any business can take. Our latest feature showcases the typical DevOps journey, flagging common areas where businesses stumble, struggle or succeed. It also gives businesses the confidence they need to make the leap into a new transformative future.

Wherever you are on your journey,and whether you’re a heavily regulated enterprise, or an agile start-up looking to scale, your digital transformation will benefit from a partner who’s been on the journey before…

Download your copy of The Great DevOps Rabbit Hole and learn the secrets of mastering your DevOps journey.

 

Eloisa ToveeDevOps Enterprise Summit 2019: what went down
read more
Don’t Be a Hero: My Experience with Burnout

Don’t Be a Hero: My Experience with Burnout

Burnout is an issue which is becoming more widely recognised and discussed within the technology industry. The more I have spoken to colleagues openly about this topic, the more I am surprised how common the experience is. A recent statistic identified that a shocking 57% of technology workers suffer from burnout.

Earlier this year, I gave a presentation titled ‘Don’t be a Superhero’ during the the Ministry of Testing’s conference, TestBash Brighton. During my presentation I discussed my own experiences with burnout, how I recovered and what individuals and employers can do to prevent experiencing something similar.

Burnout Talk

If you would like to watch the full presentation, then you can sign-up for a free Ministry of Testing Dojo account and find the video here.

The following is a summary of that talk.

Background

I began my software testing career in January 2014 as a Games Tester. Since I started that particular role with no prior technology experience, I had a deep desire to improve my skills and prove myself.

I moved into my first Agile testing role in May 2016 and began to learn how to code. I knew I was entering the role at a fairly junior level, but I wanted to keep growing my career and began to push myself harder and harder in order to do so. It was this and wanting to improve my testing skills, that eventually led to me burning out.

How did I fall into the burnout trap?

Over time, I used to love being the go to person when a critical situation arose in our production environment. Working late was something I enjoyed doing because it meant I was saving the day. Having people treat me as a fountain of knowledge on the area I was working on was addictive. In hindsight, I simply cared too much about what my colleagues thought of me and compared myself to them.

I wasn’t just focusing my ‘free time’ on work projects, I was self-learning and wanted to learn new technologies, programming languages and skills that would make me a better tester – time I should have spent unwinding and resting. But instead of resting, I was watching YouTube tutorials on the latest technology trends.

Slowly, I began to realise the impact of the hero role I had forged for myself. I became sick of being the hero in the team, but still had managers approaching my desk at 5pm to tell me something in production was on fire. My holidays were routinely interrupted by colleagues asking me how to technical questions. I was even once asked to work on something critical on the same day I had phoned in sick.

As a result, the quality of my work also suffered. I found that even when I was working on a new project, people involved in the previous project were frequently asking me questions. I hadn’t shared my knowledge with anyone else as I was preoccupied with putting out fires and not preventing them.

What was burnout like for me? 

I was stressed. I never felt at ease at work as I felt I had too much work to do and not enough time to complete it. All of the work I had committed to in my ‘hero’ role came to a head at the same time and I began to feel overwhelmed.

I used to be extremely enthusiastic and passionate about my work, but at the point of burning out I couldn’t care less about the work I was doing. Every day, I was simply going through the motions.

My work relationships also suffered. I had previously made a lot of effort to form good working relationships with people in my team, but due to burnout and demotivation I was turning down offers of collaboration indiscriminately.

One of the worst symptoms was physical as well as mental deterioration. I was finding it difficult to sleep some nights because I was worried about how demotivated I was at work. I was no longer performing as well as I should’ve been because I was fatigued. 

Burnout Talk

How did I recover?

It wasn’t until I read a blog I found on Twitter that I realised I was suffering from burnout. It was here that I began to take some actions to improve my work-life balance. Here are three recommendations I hope you takeaway:

  1. Learn to say no

The first thing I did was to learn to say “no” to any excess work which was coming my way. This was a difficult thing to do as my managers were used to me taking on every piece of work, but they mostly understood why I was saying no.

  1. Go back to normal working hours & mute notifications

For the most part, I also stuck to my normal working hours. In our industry, overtime can be a common occurrence. I learned to question the need to do overtime when I didn’t believe it was necessary so that I was working a reasonable number of hours each week.

I also muted Slack and work email notifications on my phone outside of working hours. Having these apps active all the time can really blur the lines between personal and work life. Please don’t be the person whose downtime is on the couch watching TV but also replying to a work email at the same time – it doesn’t help anyone in the long run. 

  1. Prioritise & realistically plan workload

Learning to delegate and share knowledge on a daily basis was difficult but incredibly important. It allowed me to plan my workload, knowing the critical tasks I personally had to tackle each day.

Planning my workload now included any study and research outside of working hours too. I was able to be realistic when it came to setting targets for learning and development.

*****

I’m now fortunate enough to be on the other side of my burnout experience and have found ways of addressing my work/life balance for the better.

A large part of this is that my current employer, ECS Digital, actively plan catch-up weeks once a month. This ensures I have the time and flexibility to upskill and explore new technologies within my contracted hours.

Having the support of a talented team when learning new skills is also extremely important. I don’t feel as if I am learning in isolation as the team is always available to collaborate with me on solving problems.

Why businesses need to take note

According to a recent Kronos study, one of the top causes of burnout in 2017 was unfair compensation packages that lend themselves to employees working too much overtime and having an unreasonable workload. The same survey reported that 46% of HR leaders believed employee burnout was responsible for up to 50% of their annual workforce turnover.

Another aspect is that organisations frequently reward hero behaviour but fail to recognise the consistently good work of their employees who can achieve a high standard of work within their nine ‘til five.

At a time where businesses are struggling with the IT skills shortage and employee engagement is a competitive advantage, businesses can’t afford to ignore burnout within their teams. In the words of Charlie DeWitt, Managing Director of ANZSEA at Kronos:

“Employee burnout has reached epidemic proportions. While many organisations take steps to manage employee fatigue, there are far fewer efforts to proactively manage burnout. Not only can employee burnout sap productivity and fuel absenteeism, it will undermine engagement and cause an organisation’s top performers to leave the business altogether. This creates a never-ending cycle of disruption that makes it difficult to build the high-performing workforce needed to compete in today’s business environment.

Organisations should seek out and implement technology solutions that provide a proactive approach to mitigating burnout, such as the scheduling of rest during rolling periods as long as a year. Workforce analytics can also identify and alert managers to trends in scheduling and absenteeism that may indicate an employee is on the path to burnout so changes can be made.”

Lessons Learned

Since I began to become more aware of my burnout symptoms I have achieved a greater work-life balance and now take a lot more time to relax. I take more time to spend with friends and family. My stress levels have reduced as I don’t work nearly as much as I used to and the self-learning that I now do is something that I’m truly passionate about.

The main thing I took away from the experience is that whilst enjoying what you do at work is extremely important, nothing happens in a vacuum and there are a lot of things in life more important than your career.

Just released!

To see the talk that inspired the blog, head to Ministry of Testing’s website for Ali Hill’s presentation on burn out at this year’s TestBash, Brighton here.

About the author:

Ali Hill is a passionate and motivated software tester at ECS Digital with a specific interest in improving teams’ processes to assist them in delivering quality software. Not only a test consultant, Ali is also heavily involved in the testing and tech community through my co-organising of Edinburgh Ministry of Testing Meetup and public speaking at various conferences – including a recent visit to the Nordic Testing Days conference.

Ali HillDon’t Be a Hero: My Experience with Burnout
read more
Women of Silicon Roundabout: Key Takeaways

Women of Silicon Roundabout: Key Takeaways

This week, Women of Silicon Roundabout opened its doors to over 5,000 incredibly passionate, brilliant and career driven individuals looking to explore all things business – from gender diversity and inclusion, to pushing boundaries and inspirational anecdotes from the rather Marvellous Karren Brady OBE…

And ECS Digital were right in the middle of the buzz! 

Proud to be silver sponsors, we set up shop in the middle of the conference – close enough to the fro-yo but sensibly out of reach of the specially brewed ‘DevHops’ beer on the other side of the room. With tote bags in hand and the DevOps Playground Panda for extra company, the team did an incredible job talking about the unique DNA of ECS Digital and the incredible DevOps / QA culture we have helped create for our clients. 

What was particularly refreshing about this event – other than the vibrant spectacle of business fashion which you never quite seem to get at male-dominated events – was that it solely exists to inspire, up-skill and give individuals the confidence to go out and do great things. Every speaker was rightly celebrated, with rooms packed to resemble the recent Spice Girls gig and audience members cheering like wildings for their admired colleagues. Every talk spoke to either the head or heart, or both. And every person who came by our stand was an absolute pleasure to speak with.

How spectacular is that! In light of all that is currently in flux (Brexit, Gender Pay Gap, Positive Discrimination, the number of CEO’s named David…) this conference boldly pushed through the negative noise and created an event filled to the brim with positivity, determined to set a few things straight. Including giving the audience the knowledge they need to make more informed decisions.

With this in mind, we couldn’t pull together a summary of this great event without drawing attention to the incredible job Marie Cruz and Samer Naqvi did on delivering their own talk on Software Testing Trends in 2019. Both QA and Continuous Delivery Consultants at ECS Digital, their talk looked at delivering less yawn, more Elvis in software testing, focusing on the tools and technology that help create valuable solutions. Here’s a little sneak peek…

 

 

It was also a great opportunity for both to showcase their expertise. In the words of Marie, 

“Speaking at Women of Silicon Roundabout has given me the boost of confidence in my career and I wouldn’t have done it without the support of ECS Digital. Networking with a lot of respectable women in technology and listening to the other speakers talk about their experiences just means that the technology sector is empowering women and we all have a role to play”

Whilst there is a recording on Facebook already, we hope to release the event exclusive version of their talk our YouTube channel very soon.

With so many speaker sessions over the two days, we could only catch a handful of talks, so here’s our Women of Silicon Roundabout key takeaway iceberg – with the hope that others might add some quotes or titbits of what we may have missed. Enjoy! 

Eloisa ToveeWomen of Silicon Roundabout: Key Takeaways
read more
Top 5 takeaways from Nordic Testing Days 2019

Top 5 takeaways from Nordic Testing Days 2019

Nordic Testing Days is the leading testing conference in the Nordic region, held in Tallinn Estonia. This year, our very own Continuous Testing & Delivery Consultant, Ali Hill was one of the speakers. Here’s his take on the experience:

The conference took place on May 30th–31st 2019 (and May 29th if you took part in the tutorial day). It was a truly great experience to both speak and attend over the two days. Here’s what happened:

Speaking Experience

Having arrived in Estonia on the afternoon of May 29th – and having spent a couple of hours exploring the beautiful city of Tallinn – it was time for The Speakers Dinner. The evening started with drinks by the sea before we were surprised with dinner on a boat as we sailed up and down Tallinn’s coastline.

This dinner really characterised how Nordic Testing Days look after their speakers. If you are accepted to speak, then travel costs and two nights accommodation are covered by the conference. The organisers and volunteers were great at replying to any questions I had in the lead up to the event and I truly felt valued as a speaker.

The stage, mic and presentation equipment all made life very easy and the attendees were engaged and asked some really thought-provoking questions.

My talk was titled ‘Let’s Share the Testing’ and focused on a journey I went on with my previous Agile team – after we identified testing was a bottleneck in our attempts to continuously deliver software. I discussed how we removed the testing bottleneck by collaborating on the testing effort, and how sharing testing knowledge improved productivity and communication within the team. I also shared my ideas on how to involve non-test specialists in testing activities in the hope these help others in their own projects!

Ali Hill Nordic Testing

Conference Sessions & Key Lessons

 The conference format provided plenty of variety. Each day started and ended with a keynote attended by all delegates. In between the keynotes were two parallel talk tracks or a longer workshop.

As the name suggests, Nordic Testing Days is primarily a conference about testing and attended by software testers, but not all of the sessions focused on this and there were presenters and attendees from a whole range of disciplines present at the event.

Key Lessons from the Conference

Below are five key sessions/takeaways from across the two days of the conference, in no particular order: 

  1. Don’t Take It Personally

One of the most valuable sessions I attended was delivered by Bailey Hanna whose workshop title was aptly named ‘Don’t Take it Personally’ taught me how to turn potentially negative comments into a positive conversation. The workshop covered a number of linguistic behaviours which may be exhibited by a person acting negatively. We practiced in groups by exhibiting these negative behaviours and turning the conversation into a positive one during this session. As well as teaching me how to handle these situations it also led me to reflect on how I should provide feedback to colleagues. 

  1. Ask Questions About Accessibility

Ady Stokes’ presentation on Accessibility was really interesting. Accessibility is, unfortunately, not an area I have spent much time focusing on in my career. Ady dispelled the myth that developing with accessibility in mind only benefits those with disabilities. He showed us a graphic which is part of this Inclusive Design Blog and highlights the difference between permanent, temporary and situational accessibility issues.

My main takeaway was that it’s important for all members of the development team to ask questions about accessibility, and get the conversation started in their workplace.

  1. STRIDE, Elevation of Privilege, Threat Modelling…

Gwen Diagram’s energetic presentation – ‘Security by Stealth’ – was a late addition to the conference schedule, but an extremely valuable one. It covered two main themes:

  • How to organise well-attended workshops in your workplace (hint: provide food!)
  • The tools Gwen used to get her teams interested in developing with security in mind.

Gwen’s workshops used models such as STRIDE, activities such as Elevation of Privilege and Threat Modelling and tools such as OWASP Juice Shop and ZAP.

Like accessibility, security is an area I haven’t explored in any great depth. All of the terms I’ve used above are areas I’m now interested in learning more about.

  1. Explain Exploratory Testing

Alex Schladebeck kicked off day two of the conference with an excellent Keynote called ‘Why Should Exploratory Testing Even be the Subject of a Keynote?’. It’s an interesting title, but Alex explained why she believed exploratory testing is important (potentially the most important activity testers perform), and why testers need to be better at explaining what it is we’re doing when we’re exploring our products.

Alex stated that testers often talk about ‘intuition’ and ‘experience’ when it comes to finding bugs, but this isn’t useful in explaining what we are doing to developers or other members of our team. My main takeaway from this talk was that I need to pair and mob more with my team and explain what it is I’m looking for when I’m exploring the system under test. 

Exploratory Testing

  1. Cynefin

Towards the end of the second day (actually immediately after my talk) was Lucian Adrian presenting ‘Choose your Test Approach with Cynefin Help’. Cynefin is something I’ve seen come up quite frequently on Twitter and in blogs but not something I’m overly familiar with. Lucian did a great job of introducing Cynefinas a sense making framework consisting of five domains: obvious, complicated, complex, chaotic and disorder – and how he uses this framework to create his test strategies.

I still find Cynefin difficult to fully understand, but it’s something I want to explore more and I’ll definitely be watching Lucian’s talk back when the recordings are made available. 

Post-Conference Activities

As well as a dinner for speakers, there was also a dinner and party after the first day for all speakers and attendees.

An area of the venue was transformed into a dancefloor, but there were also lightning talks and Powerpoint Karaoke for those who preferred a quieter night. If you’re ever at a conference that does Powerpoint Karaoke then I’d highly recommend attending. It’s extremely entertaining watching brave volunteers try to make random slides tie into a topic they have been provided at random.

After 10pm, those who wanted to continue the party could head into Tallinn’s Old Town until the small hours.

Venue

I couldn’t write about Nordic Testing Days without mentioning Kultuurikatel, the venue itself…

It was a power plant in its previous life but has been repurposed into an event centre. It was the perfect size for the 500+ attendees to the conference and was only a five-minute walk from Tallinn’s Old Town.

There were two fantastic presentation rooms and a number of smaller areas for workshops and tutorials. There was also plenty of space to network during the breaks and a nice area outside to sit in the sun.

I think any conference would struggle to get a venue as great as this one.

Concluding thoughts

Overall, I thoroughly enjoyed my time at Nordic Testing Days and highly recommend the event for anyone in the testing and developing space. It was great to meet so many other testers from around the world and discuss challenges we are facing and solutions that we have created.

I’ve got plenty to reflect on over the coming weeks and I look forward to applying some of what I’ve learned in my day to day work.

Keep an eye on the Nordic Testing Days YouTube channel where the recordings of all talks will shortly be made available.

Nordic Testing Days

Ali HillTop 5 takeaways from Nordic Testing Days 2019
read more
Take your testing to the Cloud

Take your testing to the Cloud

There are lots of reasons why companies choose to make the transition to the Cloud, but it’s safe to say that improving the speed and accuracy of your testing is rarely one of them. In fact, the benefits to your testing after moving to the Cloud often go unrealised. This is not because getting to those benefits is hard (it isn’t), or because there are clear reasons for keeping testing on-premise (we would argue that in most circumstances there really aren’t any), but simply because the focus tends to be elsewhere.

In this piece we are going to play out some of the key benefits and also address some of the misconceptions there are around potential barriers.

The benefits:

  1. It’s easy to set up and provision testing environments

Traditionally, getting an environment up and running is a process that takes days, potentially weeks. This means it’s intensive, both in terms of time and resource (which equals money). It also means that in some instances, test environments may not be set up because the cost is seen as too high. Take for example testing your code changes once you have raised a pull request. Creating a test environment for your pull request can have significant benefits when it comes to speeding up delivery and feedback. On-premise it would be highly unlikely to spend the time setting up test environments for pull requests. Testing would be done locally, with issues often missed creating further problems down the line.

In the Cloud, Infrastructure as Code tools like CloudFormation or Terraform can go up in a matter of minutes. You can create a new test environment as you need it and then simply take it down when you are done.

  1. Consistency

By using tools like Docker, you can get a far greater level of consistency between environments. This means you can be more confident you are testing like for like. On-premise there will almost always be small, but potentially important, discrepancies between environments.

  1. Data creation and manipulation

Poor quality data is always an issue when it comes to testing. The worse the data, the fewer issues you will be able to uncover. It is also hard to know whether the test data you have is any good until the testing is underway – and by then it’s too late. Tools like Docker can again be very useful, because the quality of data will be far more consistent.

  1. Scaling

In the on-premise environment, running tests in parallel rather than sequentially would be almost impossible. This is where Cloud comes in.

Because creating and provisioning environments is so much easier in the Cloud, parallel testing is much more doable. You can run the same test across multiple scenarios or run multiple test cases at the same time. Running tests in parallel not only saves a considerable amount of time, it is also far easier to validate different permutations such as browser types and versions.

  1. Faster time to market with reduced risk

Not only does the Cloud enable you to move through test cycles faster, it also enables you to do it with less risk. Tools like Docker and Heroku enable you to release in much smaller chunks which means it is far easier, and faster, to deal with points of failure and then move forward. The fully automated release process also means less manual interference, which in itself reduces risk further.

The barriers:

While the benefits of testing in the Cloud are clear, there are still some concerns / perceived barriers that might hold people back:

  1. Cost

The cost of Cloud is something that is at the top of a lot of people’s minds. Some of those that have already made the transition are finding the cost is substantially higher than they imagined. A lot of this is down to how it is managed, and the same applies to the testing piece. Because environments can be spun up so quickly, there is a danger that they will just proliferate, and numbers will get out of hand. It is important that there is clear governance and process in place to ensure environments are taken down when they are no longer needed.

  1. Security

A few years ago, security was considered the biggest barrier to moving to the Cloud full stop. These days, most will admit that security is often better in the Cloud than on-premise, but that is not to say that security problems don’t exist. In essence, the same rules apply in both environments. Do a good job and follow the right processes and security shouldn’t be an issue. One clear benefit, however, is that in the Cloud environment, it is much easier to test just how good the security is.

  1. Disaster recovery

There have been a number of high-profile instances of Google and Amazon outages affecting customers. The most high-profile causing data to be rerouted to China – which is tricky as Google doesn’t do business there!

The fact is, although these are high profile, they are usually pretty low impact and actually far less likely than on-premise. However, in the case of security, one major benefit of the Cloud testing environment is that it gives you the ability to test your disaster recovery far more effectively.

It is pretty clear that for almost everyone, moving their testing into the Cloud will deliver significant benefits. Although it might not be the thing that is driving Cloud adoption, it is certainly a substantial value add.

To find out about how you can successfully move your testing to the Cloud, talk a member of the ECS Digital team to discuss how you can start reaping the benefits mentioned above.

_______________

Image credit

Kouros AliabadiTake your testing to the Cloud
read more
Behaviour Driven Development in a nutshell

Behaviour Driven Development in a nutshell

If you’re new to Behaviour Driven Development (BDD) and don’t understand the jargon surrounding it, this is the article for you. This article will explain the most fundamental concepts as well as the basic implementation of this agile methodology.

Let’s start by clearing up the misconceptions. BDD is not limited to test automation and it is not about tools. Fundamentally, BDD is actually about great communication, where an application is specified and designed by describing in detail how it should behave to an outside observer. In other words, BDD is about working in collaboration to achieve a shared level of understanding where everyone is on the same page. That’s the basic understanding you need to know. Easy enough.

So, what does this ‘great communication’ mean for software development?

Great communication means:

  • A usable product first time round, which allows you to get your product to market faster
  • A lower defect rate and higher overall quality
  • A workflow that allows for rapid change to your software
  • A very efficient and highly productive team

How is it done?

Meet our key stakeholders/teams:

Developers • Testers/QA • Project Manager/Scrum Master • Product Owners/BA

 

To illustrate what happens when you implement BDD, here are the before and after scenarios:

Before implementing BDD

Traditionally, software is designed in a waterfall approach where each stage happens in isolation and is then passed along to the next team. Think conveyor belt factory style:

  1. First the Business Analyst defines requirements
  2. Then the development team work on these requirements and sends for testing
  3. Then testing discovers lots of bugs and sends back to the development team
  4. Things are miscommunicated in transit so repeat steps 2 and 3 back and forth until you run out of time or budget
  5. Release software

The problem here is that everyone is in isolation, interpreting the requirements differently along the way. By the time code is handed in for release, resources are drained, and people are frustrated as there are issues that could have been avoided had everyone just been working together initially.

After implementing BDD

  1. Business and PO/BA have a set of requirements ready to implement
  2. BA, Developers & QA work collaboratively to refine these requirements by defining the behaviour of the software together. Thinking from the point of view of the user, they create detailed user stories. Throughout this process they address the business value of each user story and potential issues relating to QA that may crop up
  3. Each story is given an estimate of how complex it would be to implement
  4. The whole team now has a strong shared understanding of the behaviour of the software and when it will be considered complete
  5. Begin Sprint: Developers & QA then work together or in parallel to produce a product that is ready for release

 

BDD

 

This process saves time and money and is incredibly efficient. The core element of this efficiency is the team’s clear understanding of scope and what the fundamental features and behaviours required are. Because of the collaborative nature of BDD, issues are brought to light that otherwise would be an afterthought. For example, how a feature might behave differently on mobile or how a feature might deal with a large number of users. These are considerations that should be addressed from the outset.

What is the best way to implement BDD?

Just because people are in the same room or present at the same meeting doesn’t mean they will collaborate effectively. Each of the stakeholders play a crucial role and some teams/individuals may need to change their way of doing things to make sure that collaboration actually happens. The image below outlines the key deliverables for everyone involved when adopting BDD:

 

BDD

 

An example of BDD in practice

BDD is a risk-based approach to software development; it mitigates the likelihood of running into issues at crucial times. Teams at ECS Digital have been using the BDD process effectively, including  implementing a website feature for a popular media client. The client wanted to create a swipe feature where more mobile users could swipe to see different articles and move through the sections easily. Everyone was collaborating from the initial stages and the team was able to ensure high quality on the website throughout the process of implementation.

With a clear and shared definition of what the website would be like when completed, they were able to innovate further to mitigate the risk involved. They decided that during times of low traffic they would send users to the new website with the new swipe feature and get feedback. Then during risky times of high traffic users would have the usual website without the new feature. This allowed the team to ensure that when they made the feature a permanent part of the entire website they were taking as little risk as possible.

If this team was not utilising BDD techniques by defining the website’s behaviour in detail and involving each team in the development of requirements, they may have released the feature without such precautionary measures or run into many issues when approaching the release date.

If you’re interested in understanding more about BDD and delving into some of the jargon surrounding it – “gherkin syntax”, “the three amigos”, “impact mapping” & “living documentation” – read our previous article here: Behaviour Driven Development: It’s More Than Just Testing

Kouros AliabadiBehaviour Driven Development in a nutshell
read more
Helping Developers Become Testers

Helping Developers Become Testers

As software development practices evolve, the line between developer and tester has becoming increasingly blurred. As testers, we are now expected to know how to setup test automation frameworks, code different types of test (e.g. integration, functional, performance) and even understand and contribute to the build and deploy pipeline process.

Traditionally, there has always been a clear distinction between development and testing. In older software lifecycle models such as Waterfall and V-Model, testing only starts when development work is finished, with few if any automated tests put in place.

Over the years, companies started to adopt a more collaborative and iterative way of working where the testing process is often championed to start as early as the requirement gathering stage.

Even though development practices have evolved throughout the years there is still, from my experience, this misconception that developers cannot write tests. This is why specialist roles such as SDET (Software Development Engineer in Test) were created – to bridge the gap between developers and manual testers. Developers are more than capable of writing tests – they already write most of the unit tests for their own code. So, then …why do some developers not test?

From the different client that I have worked with, I have observed the following reasons why this might be the case:

1. No one asks them to test

If management don’t push for them to do this, they will think that automating tests is not part of their responsibility. This initiative has to come from the top. Test architects and SDETs, that feel developers should help out with test automation, will not be able to convince them on their own.

2. They don’t want to test

Most developers still assume that features should be automated solely by testers. Once their ticket passes peer review, they believe that their work is finished. Some developers hate writing end to end tests because they believe the process is slow and flaky. Those developers who have tried to help out find tools such as Selenium difficult to set up and work with.

3. They lack the necessary guidance of looking at their features from an end to end perspective

Most developers work on single components, so they can lack an understanding of how their components will integrate with the rest of the systems. Also, the requirements provided to them often ensure that all positive scenarios are working as expected, leaving negative scenarios missed or neglected.

How do we then help our fellow developers become testers?

How do we bridge this gap and ensure that we maximise everyone’s potential?

1. Get support from management

Support needs to come from the top. Make sure that you communicate what the business benefits are if developers help the testers. Quality should be owned by everyone and not just by the testers.

2. Regular knowledge sharing with the business

Developer should be told how the application they’re working on is used by the business or its customers.  A simple yet effective idea is to have regular knowledge sharing sessions with the business. Another good idea is to have these sessions documented on Confluence or something similar.

3. Documentation on how to contribute to the automation framework

There should be clear guidelines on how developers can help contribute to writing tests. If someone has not used tools like Cucumber and Selenium, make sure a “how to” guide is created.

4. Introduce pair programming when writing tests

Pair programming is a common way of working amongst developers and this can also be used when writing tests. Experienced SDETs need to pair with developers to share this knowledge.

5. Be a teacher and educate

Point them to resources that will help them with writing tests and show them best practices. Guide them on how to do it but don’t write their tests on their behalf. Peer review their code. Be patient.

6. Modify your process to include testing as part of a developer’s workflow

Before changing your ticket to done, make it a habit of including automated tests. This is especially useful for new features. Rather than writing the tests after the feature is deployed, write it during the development stage.

7. Include automation tests as part of the CI/CD pipeline

The more diverse tests that are added to the pipeline, the more visible the results will be to everyone. Utilize an effective test reporting dashboard so results of all the test runs can be easily displayed. By having these tests in the pipeline, developers will have visibility if they break existing features.

8. Evaluate testing tools effectively

To encourage developers to write tests, the testing tool should be somewhat familiar to them. If you work on a team where JavaScript is the language of choice, there is no point trying to implement the automation framework in Ruby or Python. Speak the same language as the developers. If you work in a company where you’re tasked with setting up the automation framework, ask everyone’s opinion on which tool to use. More and more testing tools are emerging these days, such as Cypress, which aims to provide an easy on boarding process for developers to start testing.

So, what happens when developers become testers?

I’ve seen the benefits first hand. At the client where I’m based, we’ve introduced this approach where developers write the automated tests for some of the new features. Not only are we releasing new features quickly, but knowledge sharing and collaboration between developers and QAs is better than ever before.

Developers should know about testing the same way automation testers know about coding. By getting developers involved with the testing process, we begin to utilise everyone’s knowledge and potential, as well as avoid scenarios where bottleneck occurs.

If you’d like more specific advice around how to help your developers become testers, you can get in touch with us here.

Marie CruzHelping Developers Become Testers
read more
Solve your test data woes with GraphQL & schema introspection

Solve your test data woes with GraphQL & schema introspection

While highly technical in places, this article goes through some solutions ECS Digital has been able to provide for a client to improve testing strategies and reduce costs. Although, not for everyone, we hope that sharing our technical expertise in this area can benefit the community at large.

Tech stack: React | GraphQL | Apollo GraphQL | Javascript | Typescript | Cypress

One of our clients has been going through a change period where we are re-platforming their whole tech stack. As part of this process, we felt that now was a really great time to address an underlying issue that we have experienced with the old tech stack.

That problem is test data.

When I speak of test data, this applies to not only the unit and integration tests, but also our functional UI tests.

We had two fundamental problems we wanted to solve:

Problem one

It was the responsibility of the developer to test his component with any unstructured data they saw fit. If a developer creates a component that expects data of shape A and creates a test with data shape A, the test will pass. If, however, over time the real data that is passed to the component changes to shape B we have no idea if our component will still work until quite late in the development process, which introduces a long feedback loop.

Problem two

Our functional UI tests ran on a long living full stack. There was a known data set that we could reset to, which was all stored as json in its own repository – completely separated from the rest of stack and its tests. To update the fixture data on the full stack you would need to understand what test cases were already using the json, then manually change the json, create a PR, get it reviewed, merged and then run the mechanism to reset the data on the long living stack.

At the start of the project this fixture data was very useful. It allowed our functional UI tests to be robust and repeatable. As a result, when all our tests passed we had high confidence our site was releasable.

Unfortunately, over time and as software naturally adapts our fixture data started to become harder to update and maintain. Some parts were updated inconsistently, we had no clarity on what tests were tied to fixture data and shouldn’t be updated. Eventually our fixture data became unmaintainable or would break other tests as it was updated. 

We spent a lot of time thinking about how to solve both of these problems and after quite some time and several approaches we finally achieved something that we felt was clean, and maintainable.

Solution

Like a lot of the industry we are migrating to a GraphQL back end.

This opened an interesting opportunity as GraphQL uses types and fields to develop a `query language` for your API. You are only ever able to query for fields that exist on their corresponding types, otherwise GraphQL will complain.

GraphQL also supports something called schema introspection, which provides a mechanism to pull down a schema for any enabled GraphQL server. This can be useful to see what queries your API will support.

https://graphql.org/learn/introspection/

Another tool called GraphQL code generator can take a GraphQL schema as an input and will output all the type definitions of your GraphQL schema as a typescript file, along with any type descriptions present on your schema. (shown below)

https://github.com/dotansimha/graphql-code-generator

Problem One Solved

Now that we had the capability for translating our production GraphQL server types into typescript definitions, we were satisfied that we could start to build a fixture generator package matching our production GraphQL server. A key part of building this package was to provide a consistent API for all clients of the fixture generator package. We also ensured that whenever the logic for building fixture data started to become complicated unit and integration tests were baked in.

Once the generator package was in place, the workflow used was anytime a client of the fixture generator package is run, the schema introspection and generating our type files comes as a precursor. The whole process takes around a second and once completed the fixture generator typescript package will build. If the schema has changed, and the fixtures no longer adhere to the types, the build will fail and you are alerted straight away.

This provides huge benefit to our tests as it now means that our tests ask for the data they require. The complexity around managing test data is no longer the responsibility of the tests. We also know that the data will be correct as per the production schema even over time. Finally, if the types do change, we only need to fix it in one place for all our tests to be updated.

You can see an example of how you would use the fixture generator below

Problem Two solved

The fixture generator brought us closer to solving problem two, but we still had no way to run our functional UI tests and somehow pass our fixture generator data to our front end. The front end was still querying the long living GraphQL environment.

Another tool Apollo GraphQL provides some powerful tools around stubbing whereby you can pass your GraphQL Schema, as well as overrides for type definitions in your resolver map. Once you have defined what data you want to return when you query a type you can start a local GraphQL server.

https://www.apollographql.com/docs/apollo-server/features/mocking.html

Once running we could point our front end to our local stubbed GraphQL server.

The final piece was to have our tests once again define the data they required and then spin up the local GraphQL server.

We have also been using Cypress as our new functional UI test tool.

Cypress as a tool is groundbreaking and is revolutionising UI tests. It runs in the same run loop as your application in the browser and provides new features for UI testing such as playback mode. I’d really recommend looking if you haven’t already

In our tests we run a Cypress task to start up our short living mock GraphQL server and provide the fixture data that we want GraphQL to run with straight from the test.

Once again this means that our tests explicitly ask for data. Previously if we wanted this test to work with 4 related articles, we would have had to edit a separate repository. Try to understand if the data we want to edit is already being used by other tests. Create a pull request, get it approved, merged, then run the reset data mechanism.

Now it’s as simple as updating the variable inside the test and it is clear what data the test needs to run and practically removes the previous feedback loop.

If you want to understand at a deeper level how this works, it’s all open source.

Take a look at the repositories below:

https://github.com/newsuk/times-components/tree/master/packages/fixture-generator

https://github.com/newsuk/times-components/tree/master/packages/mock-tpa-server

Or alternatively, find out how ECS Digital can help improve your test strategy by contacting us.

Matt LowrySolve your test data woes with GraphQL & schema introspection
read more
Xin’s Story as a QA and Continuous Delivery Consultant

Xin’s Story as a QA and Continuous Delivery Consultant

My name is Xin Wang, I am a QA and Continuous Delivery Consultant as ECS Digital. I recently published a blog explaining how I went from delivering presentations on Fashion Week 2017 fashion trends, to writing functional tests as a software developer engineer.

Working in a male dominated industry has been very different to what I was used to – the approaches that some male engineers take are sometimes very different to the approach that a female would take. But these perspectives combined give you a much valuable overview which is why I really enjoy working on coding challenges with my colleagues.

Take a look at my video if you are interested in understanding why I switched my career around and how I am continuing with my journey as a software developer engineer.

Xin WangXin’s Story as a QA and Continuous Delivery Consultant
read more
Day In the life as a Technical Test Engineer

Day In the life as a Technical Test Engineer

Hi there, my name is Marie Cruz, and I’m a Senior Technical Test Engineer at ECS Digital. I’m responsible for providing test services to various clients with the focus of implementing BDD processes. I recently published a blog explaining how I balance being a mother and a woman in technology.

Having a family and an active career in tech, people tend to ask me how I manage to keep up with both. My answer is making sure you understand what’s important, but also ensuring that you are happy with the choices that you are making.

If you’ve ever wondered how a female can handle both a career in tech and a family life, feel free to take a look at my “Day in the Life as a Test Engineer” video. I hope it inspires you to take the leap into technology too!

Marie CruzDay In the life as a Technical Test Engineer
read more