Joining a CD Team the experience report

Today is my last day at Songkick. It has been amazing. Unfortunately I am in no position to move closer to the office, which means commuting! Commuting has taken its toll on me and I decided to call it a day and cried a lot.

When asked during recent interviews what my dream job would be, I did honestly say, my current role at Songkick. It obviously had its challenges but I don’t think a role has pushed me and enlightened me as much. Thanks for giving me the opportunity to experience it.

With joining Songkick came the experience of joining a CD team. Amy did a great talk about the survival guide of joining a CD team at Testbash Brighton this year.

But what was my actual experience?

I cam from a scrum team. We had bi-weekly releases and a comprehensive suite of selenium tests that ran through the browser. By comprehensive I mean, we had 64 hours of selenium tests that when run in parallel took 4 hours. So if one test failed because it found a bug, is flakey, you name it, you lose another 4 hours.

This meant there was a 3-5 day code freeze before the release date as well. We also used a typical scrum board with columns including a testing column. Some were even so granular that there was a “Ready for test” and “In test” column.

scrum-task-board-template-powerpoint

Any bugs that were raised during the sprint ended up in the to do column and needed to be fixed and regression tested before the sprint could be closed off.

Typical problems I had at this job were:

  • Testers become the “bottleneck”
  • Convincing team to help test rather than start new work
  • Defining acceptance criteria
  • Everything had an acceptance test
  • No unit tests

 

When joining CD teams it is worth understanding what the CD stands for. At songkick we have both products working in Continuous Delivery and Continuous Deployment.

At the very basic level both have an automated test and release pipeline but the Continuous Delivery approach still has a manual step to deploy to production, whereas Continuous Deployment would deploy the code straight to production.

This environment came with many learnings for me.

Ready for test:

Being used to the “Ready for test” column it was quite a shock to join Songkick and its continuous delivery and deployment approaches. Don’t get me wrong I joined because of these approaches as well. In conference talks this often appears to be a mystical world of software development where you test your code on production and developers have relatively good dev environment set ups that they can test well themselves.

But when do I test? Also where do I test?

There was something like a complete loss of control. In certain work environments (not Songkick at all) when a bug is found in production, the test team gets blamed. “Why wasn’t this tested?” is a common phrase. If you have worked in such an environment and then go to continuous delivery you can initially feel panicky because things move so fast and you may not be, or are very unlikely to be doing the testing.

What helped was understanding what is actually going on when new features are being developed. A thing that helped was that testing is happening everywhere all the time.

So discovering that everywhere testing is happening and can happen is invaluable. So you (not you personally but the team) can and probably is testing all the time everywhere. This starts with Kick off conversations. Here you get the chance to test the idea, the problem and the ideas around implementation. It is also a good place to state how you would test the feature.

A great tip from Amy was that in previous roles she learned that telling people what you will do for testing the new feature meant it would already get done by the person developing it and hence there will be less bugs.

So overall these kick off conversations become the most valuable part of testing for a tester at Songkick. They help inform what is just enough testing for this particular release.

Forget about “Ready for test” columns. Everything is continuously being tested and not necessarily by you. Think about how you can integrate your tester mind-set to be heard.

 

Ultimate shift left:

Get in on the planning discussions, requirements, stories, kick offs, whatever you call them, just invite yourself to the meeting and ask questions such as:

  • What is the problem?
  • Who is having the problem?
  • Why are we fixing it now?
  • How will we test it?
  • What is the risk of shipping bugs?
  • Do we need to consider non functional testing such as performance or security?

 

Team and trust:

Build good relationships in your team, because you will be on holiday for a week and there will have been 50 small releases to catch up on that were not tested by a tester.

For me this was about letting go and trusting your team members. Remember no one wants to write bad code and ship broken features.

Like I mention above I felt lost in the beginning, where do I fit in? Who is testing all of this?

A lot of that was about letting go of control issues. Discuss things you care about in a team setting, such as quality features and processes so you all feel comfortable. We did a great session on what quality and quality features means to us and how we define “just enough” testing. This can vary across products and teams but is so valuable to talk about.

 

Mindset change:

Testing becomes more of a proactive role, where you do the testing early on by pairing with developers, or going through unit tests, or liaise with the business to make sure you have the right acceptance tests in place.

Some of this mindset change may be to embrace more of a coaching mindset and sharing experiences and testing knowledge with team members.

At least at Songkick you are an expert in your field and can leverage this to help the team get better at testing in general.

 

Forget a “release date”. Communication is key:

If something is ready to go it will be released. Establish good communication with teams affected by changes. Release log emails, cross functional team updates in slack or regular catch ups.

This was an awesome change for me, to see how much the team is communicating with other departments to let them know about changes.

 

Test in production

g1361999261125710696.jpg

Get to know your production data really well, as a lot of testing will be done in the live environment. This has great advantages as the code is being tested where it is being used with real data but it can be daunting, as you could be affecting real reporting. Liaise with the relevant departments to help sort this and avoid any confusion.

I was always worried I would notify people about fake events. Liaising with the relevant teams and setting up data in a way to not disturb real fans was fun and scary at the same time and we actually found a bug that we could then fix asap.

Joining Songkick was one of the best things I did and I am super sad to be leaving today, but I am also excited about sharing what I learned and bringing this to a whole new role on the near future.

Have you had any experiences joining CD teams? Any learnings to share?

 

Advertisements

Thoughts: Accessibility testing for the web

screen-shot-2016-10-23-at-21-58-16

 

Myself and Emma recently organised an intro into accessibility testing with the awesome people at Test Partners.

They are really up for doing talks or tutorials with companies and are super friendly and knowledgeable. Do reach out to them if you have any questions on how to get started.

Why is accessibility important?

Up to 20% of the UK population has a disability but moreover research shows that 57% of the UK population benefit from accessibility features:

    • 20 million people over 50 in the UK – diminishing eye sight
    • 6 million + people with dyslexia in the UK
    • 1.5 million people with arthritis in the hand or wrist – use keyboard shortcuts over a mouse
    • Anyone can have a temporary accessibility need – like breaking an arm or hand

 

I have been aware of accessibility testing and really enjoyed the talk by Michael Larsen on the subject at the end of last year but did not look into it anymore.

This is a shame really because the internet is meant to be for everyone and therefore be inclusive but many websites are not.

Do we as testers do enough or even know enough about accessibility testing to point these things out? Are we knowledgeable enough to have these conversations on why we are excluding certain members of the population on using your website or services?

Have you ever had these conversations?

One place I worked at, I had just hired a new tester who came from an external testing services provider. He knew quite a bit about accessibility and started to raise bugs against our website for the images missing alt text for example.

On the one hand the things he was raising were just good practice to have really. But why did we not raise this before?

I never knew what to look for. I was more focused on functionality for able bodied users, maybe because I could easily be that sort of user.

The positive effect the other tester had, was that the designers and front end developers became more interested in how to make the website more accessible and started to reform from within. They started to design good patterns in accordance with the Web Content Accessibility Guidelines (WCAG) 2.0. I think this is the hard thing when it comes to accessibility, you can raise bugs and therefore awareness against accessibility features missing or keyboard navigation not working but if the designers and front end developers and maybe more importantly, the product team are not considering accessibility from the start then it is really hard to add it back in.

Why do we not learn about these things when we start our testing career? Was I just blind to it? The ISTQB certainly did not tell me about it.

If you are on the dojo there is a great resource to get you started. Maybe there will be a 30 day testing challenge for accessibility testing soon as well. I would love that.

One thing that Steve and Paul from the Test Partners showed us was this tool. You can add the bookmarklets to your browser bookmarks toolbar and then click on them to get visual feedback on how your website is built.

This helps with understanding the semantics of your page. How it is built and structured. For example headings are usually large and lists usually have bullet points. However, the semantic structure also need to be conveyed programmatically by means of tags in the source code. And these bookmarklets highlight where something has been tagged as a list or image for example.

This is a good starting point I feel, to understand what flaws your page may have for screen readers. Screen readers use the tags in your source code to tell the user what the item on the page is and does.

I would love to pair with some users of accessibility related tools at some point. On a similar note this podcast on a blind architect was incredible to find out how blind people actually use screen readers. TL;DR at a way faster setting than you think.

Have you ever paired with a blind user? Or someone who cannot use a mouse? Or maybe someone who uses a magnifyer?

 

 

Don’t get stuck, try something different

 

view when trying a new running route I saw a double rainbow!


If you don’t know by now, 5 months ago (5 months!!!) I joined Songkick.

One of the many things that appealed, apart from working with Amy of course, was to experience another way to develop software, namely Continuous Delivery.

So this post is a bit about, not getting stuck in your job, routine, thought processes, try something different when you can or if what you are doing doesn’t feel right!

How did I get into this topic?

Songkick has had quite a few new hires in the tech team over the past few months and as part of the on-boarding there is a an intro into how we test at Songkick.

For 2016 Amy has been mixing this up by making the session super interactive and it really works.

As part of this we spoke about exploratory testing over test plans and how your emotions can drive your journey through the system when you are hunting for information and bugs.

All this “huh!?”, “oh!”, “OH!?”, “ah”, and “erm” moments can drive your test journey through the application as a tester and developer.

On the flipp-side to this is boredom. Boredom is another emotional state to avoid. Question why you are bored. Have you exhausted your testing journeys, do you need to mix it up by using different devices?

Boredom and feeling a little stuck was what drove me to try something different.

First a quick back story.

As part of a merger in early 2015 Songkick is doing some re-aligning of technologies. To keep it as vague as possible. I have been part of one of those teams working towards one platform. This has been super exciting and provided a great learning experience as I could learn about both companies technological history.

But this means we have some (or a lot of) manual regression testing we do as a team. This is generally unusual for projects there but a way of providing confidence for the team and whole business.

Now where am I going with this?

My boredom (don’t tell my team, I keep telling them that all testing is fun) came from the fact that I was regression testing something that we did have confidence in, over and over again on different devices and browsers, but it is quite a risky project so we rather test twice and in person alongside automation.

In the retrospective I was surprised how concerned everyone was that the testing was left to one person while the rest of the team tries to finish off other tasks before the release date. 

One of our team members had the great idea to block out some time and get everyone to test for an hour together.

Go with the energy.

Straight away I jumped at this and expanded on the idea. We discussed that this 1 hour session will involve all team members and we will test on different devices and browsers.

I was however not keen on providing a list of testing tasks or test plans as I wanted everyone to feel free to explore, so I created some user scenarios for everyone to have and try. They were meant as inspiration of what to test and a way of visulaisin how the software may actually be used.

 This seemed to work well, although the volume of scenarios I supplied was frightening some initially, but by emphasising that these were ideas and did not have to be ticked off we got somewhere really quickly.

Make it as easy as possible.

One major thing with testing systems can be the test data. This can be time consuming to create and manage, putting people off spending time on testing. I took this away from the team and provided them with different test data options for the various scenarios. These were the same selection of test data meaning we had a mini performance test of several users, accessing the same data. Being in ticket sales though we generally deal with short and high spikes of data which we are testing using automation. 🙂

Entice them

This can be as simple as buying jaffa cakes or bringing in some home made cookies. Always works a treat!

 

Trying a new recipe!


Results?

We had a focused testing session and logged several issues. None of which will block our release, thank god, but some which would have taken ages to find for one person.

Also we logged improvements on usability, as our designers and usability experts took part and got to experience the app first hand in a repetitive situation.

Overall this was a success, we got many eyes and devices to be used at the same time and it was a great team experience!

So don’t get stuck but do try something new! You never know what you may achieve. 

Real Life: How to survive commuting?

 

Picture taken on the commute home


I watched a presentation by @medickinson on presenting/public speaking for introverts. She makes a great point on how introverts get over stimulated more easily than extroverts.

There is actually some science behind it in terms of how we actually have different tolerances to the stress hormone dopamine.

During the presentation of this data I realised that maybe I am not imagining that going to big cities makes me really tired. Big cities can be really overstimulating.

We are presented with tonnes of adverts, it is noisy, there are tonnes of people, there is less space than in the countryside. Just now I realised that me being an introvert means that it is no wonder that this tires me out.

This gave me the idea of the introverts survival guide to commuting.

To put into perspective I have commuted locally in all sorts of ways, by bus, walking whenever I can, cycling, driving etc.

But what I had never done before was travel really far and do that by train.

This changed 3 months ago, when I joined Songkick in London.

With no intention of moving to London I knew this meant tackling the commuter train.

 

My platform at 6:30am


The commuter train to and from London is sort of special. You get different types of people at different times.

The earliest I have managed is 6:31 to London and it is full of snoring people and zombies.

Today someone was asleep opposite me with his eyes open! Scary!

I am also a sleeper even at 7am, but I wasn’t initially. I think the actual commuting and being in the city has made me so tired that I need the morning to myself sleeping.

In case sleeping in carriage full of people worries you, here are some other survival tips:

1. Noise cancelling headphones – Great for those noisy snorers, loud eaters, or blocking out the ones that actually talk to each other!

2. Kindle – light, easy to hold and read. A book will do as well but can be bulky to carry around.

3. Tablet/Phablet – download videos onto your tablet or phablet. This can be some great distraction, or even learning experience. I download Ted talks on a regular basis. 🙂

4. Podcasts –  my new favourite! Podcasts are a must for at least the morning if not evening as well. My general favourites are: Criminal, Your are not so smart, Serial, This American Life and Welcome to Nightvale.

5. Music – maybe even try new music! You will hardly ever get an hour to yourself to just listen to something new. Then when you like them and want to see them live near you, why not download the songkick app.!? 😛

6. Good backpack – What do I mean by good!? Well it depends on your use cases but I need one that is cushioned, has a laptop compartment that is cushioned, big general compartment for running gear, lunch, water bottle and other bits and pieces. Waterproof is a major win as well, especially if you walk around London a lot like myself. I also like wide and well cushioned straps that you can also fasten across your body. I know the look sucks but if you are late and need to run you don’t want the bag to jump all across your back.

7. Water – I have broken out water separately here because recently I have been feeling faint on the train, especially when I have had to stand up. It is very important to keep hydrated during your commute, kids!

8. Snacks – In similar vain as water, you never know how long your commute may be. In three months I have had 4 or 5 trains be on time. Carry some snacks with you in case you don’t make it home in time for dinner.

9. Notepad and pens – The commuter train can be a great place to unwind and let your thoughts wander! You never know what great ideas you will have. Make sure to have pen and paper to hand to write them down!

10. Knitting – Now I unwind with crafting. I can’t really sew on the train (I don’t do hand sewing) so I knit. I have so far made a cowl, a hat and working on a jumper. It can be really nice to not feel like you are wasting your time by just waiting.

 

This has been knitted 80% on a train


11. Coffee – Now a good coffee can make the day! Make sure you are friendly to your coffee provider so they start recognising you and make you your usual! This saves time in those moments where you got out of bed a few mins later than usual and you can still catch your normal train!

 

Coffee! (although I have since given up – no coffee for a while now)


Also keep your stamp cards. Commuter train coffee can really drain your pockets!

12. Apps and Social Media – make sure your trainline’s twitter account and news page is easily accessible! You never know when there may be too many leaves on the tracks causing a delayed or cancelled train! You will be thankful for making checking these part of your morning routine, because they may enable you to have another half hour snooze!

These are some ideas to get you started. I left out actual work here, but do feel free to do some work on the train or write your next blog post up, as I am doing. 🙂

But let me tell you it was not easy! Now after three months of commuting it is getting better, but I struggled with exhaustion, travel sickness, leg cramps (suddenly walking 8-10km a day) and I even passed out on the train (this showed me that commuters can be nice and helpful).