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.
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.
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
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?