Testbash 2017 … something’s different?  Part 1

Testbash 2017 … something’s different?  Part 1

Testbash 2017 is here… and it looks different. Same faces (some new)… same logos…. same awesome talks and conversations… ah new venue!!!  We finally outgrew the Dome and have taken residence in the Clarendon centre. Sure it’s not as central as the dome but there is more spaaaace.

Anyway, I hope to live blog during the day so bear with me…. 

Vernon hosting again.. first things first all of us at Testbash send our thoughts  to those involved in the atrocities in London on Wednesday. 

the testers survival guide to joining a continuous delivery project – Amy Phillips (@itjustbroke)

This will be interesting as a few of the teams at Cambridge consultants are setting up CD, and in my experience, the struggle is always where testers fit in… 

Amazon deploy every second… not the whole system, most likely micro services etc. That’s extreme, but even daily or weekly can pose interesting problems for the tester. 

Amy shares the very cool diagram created by Dan Ashby in his blog post (https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/)

 where does testing fit in?  If the team is releasing, why am I even needed? Well it fits everywhere; at every stage of the process. Frequent releases are fine, but if they are low quality Fresno releases, then it will have an impact in customer experience.

Reading list – continuous delivery (jez humble & Dave Farley),  the Phoenix project.

One of the common issues for CD is the number of related terms. Continuous deployment (fully automatic), CI, continuous design, continuous improvement, devops… learn what your team  means by each… get a common understanding. Amy continues with some other definitions used in the CD world and again understanding these is very important as a tester to understand CD.

In the first week on the project, what’s your role? Find this out. Is there a deadline? This will very much affect how and what you test… how does the team work? Pairing? Branches? Trunk based?  This is all information that will affect how you prioritise testing, and your test approach.

If there are quality issues with the product, and the devs aren’t doing pull requests, branching etc… then maybe this is a good place to start!

Common mistake when joining a project is to change everything. Perhaps there is a story as to why they haven’t done that, and they are almost certainly in a journey. Find out what is annoying them and understand the issues before suggesting improvements. 

I’ve not heard anything new yet, but it’s really great to be reminded as we, at Cambridge consultants, join different teams or start new projects more often than a product company, so this is valuable.

Interesting, did you know that HMRC have open sourced most of their code… if they can do it, and deliver/deploy regularly… then why can’t you?  Very valid and compelling question!

Next tip, understand the users. In my experience this is VERY important for the team but especially the testers. What is important to the users, what issues are they hitting. Build up a picture.

Amy then suggests to read through the bug tracking system. I think this is a potential source of information but should be taken with a pinch of salt. There are often many many issues in the system that are just not important (to those that matter), but  cloud the issue. 

Assess the environment… is the test environment the same as production? If not, how different is it? Does that matter?  Understand the diffences and how they might affect your testing and potential issues in the product.

It is very important to adopt the right mindset when joining a team, especially as you are the test expert. Sure everyone on the team can do testing, but you are the test expert and can ask questions that no one has thought of. Go in with the right questions and the right mental model.

Like any journey, periodically check your route. Teams change,  views change; is CD right for your team? Or is it just buzz wordy?

Very interesting talk from Amy, and nice to have some important tips consolidated in one place. Good start to the conference…

Step back to move forwards: a software testing career introspective – Del Dewer

First we get a lesson on how to pronounce Huib Schoots name! Very funny….

Some diagrams of ‘test career’ showing test executor and test design as stages in your test career… must be test cases … how antiquated!

Moving from test lead to test analyst… recruitment consultant questioned why he took a step backwards, although he didnt think if it this way and was an opportunity. Recruitment consultants are not the best people to judge at career path, let alone testers. This is very interesting and I’ve gone ‘backwards’ a few times in my career, but always to unlock more opportunities. Also it’s often to get back to doing what I love, testing!

Del has just echoed this, as he moved into test management, it took him further away from testing.

He then talks about how skyscanner moved to remove all test engineering roles from the company … that sounds strangely familiar… trying to get test coaches implemented, piggy backing off the concept of existing agile coaches. One of the struggles was convincing the vP that the coach role was more than just a one shot deal, i.e. Once you’ve taught the teams to test, that’s it, you’re done… but it’s an ongoing role. Continually improving staff, developing, inspiring, engaging etc. But these are difficult to assess; difficult to prove progress.

Don’t let the role define you, you define the role!  So very true. It’s so easy to get into a rut, get influenced by your environment rather than sticking your head above the parapet (amen) and change it. Always do what you’re doing to the best of your ability.

Great talk, and way more content that I was able to write, but echoes a lot of the journey that I’ve had, and certainly relevant to the changes and situation we face at the moment.

Break… coffee… see you in part 2!

Leave a Reply

Your email address will not be published. Required fields are marked *