TestBash World 2022 - From SDET to SRE with Cristiano Cunha

In this talk, @cristiano.cunha takes you down the journey of how a central test automation team is responsible for:

  • producing and maintaining an automation framework
  • helping define the standards and tools
  • evangelising and training testers and teams
  • contributing to the pipeline definition
  • and ended up being converted into a full-blown SRE team.

We’ll use this Club thread to share resources mentioned during the session and answer any questions we don’t get to during the live session.

1 Like

Get connected with Cristiano Cunha:
Twitter: https://twitter.com/Melioth
LinkedIn: https://www.linkedin.com/in/cristianomcunha/
Website: https://cristianomcunha.com/

Questions answered in the session:

  1. What kind of experience background mix is the best for an SRE?
  2. what/who is SRE ??
  3. I get that devops is not SRE as its more development focus but on practical level what is SRE doing different ?? and Can a team have both Devops and SRE ?
  4. where is testing team (manual) lying between SRE. Automation testers and dev team ??

Unanswered questions:

  1. Reducing tickets it’s a dream of any team. Can you share a your own an example that was a success?
  2. What other teams do you think could be merged?
  3. If you’re not able to get experience as an SRE in your current organization, how would you suggest to get your training and getting hired?
  4. Given the product-centric approach on SRE, what are your thoughts in using let’s say Scrum in organizing SRE delivery?
  5. SDET to SRE is interesting but I would also be interested to know more about becoming an SDET (maybe seperate talk in future as im sure its a long conversation)
  6. I’m vaguely curious what happened to the people that left his company and if the other company may also change to have those same processes (having SREs)

Some Important Links

2 Likes
  1. Reducing tickets it’s a dream of any team. Can you share a your own an example that was a success?

On my case the bigger change I saw happening was when we started looking more closely at the tickets and the tickets catalogue, we needed to know what were the areas that needed more support (with more tickets) to identify where to invest first (we did not had much time and resources so we needed to make wise choices).
So, redefining the catalogue was key to identify troublesome areas or areas with poor documentation (because sometimes it just missing information) or even areas that have recurrent requests that if we manage to replace those by a service we did not get bothered again (well unless maintain that new service, but ticket wise they should disappear).

Resuming: Revise catalogue, invest in documentation and automate away!

Another huge difference was to have open post-mortems (most of the time Infrastructure takes the blame of what happens in production) where we have all teams, that were presented in the incident, represented to reach a conclusion on what happened and how to prevent it (we followed weekly those post-mortem actions to make sure they were addressed).

The last big change was to have the development teams making support of the production environment, this has triggered a major change in the development teams, that now did not want to release on Friday or were fighting to have better live probes to understand what is going on in production and most of all they do not want to be woken up at 4 a.m. because something was crashing in production.

1 Like
  1. What other teams do you think could be merged?

I would say anyone that has interest in Infrastructure and in producing products/services that are reliable and fast in production.

It is a technical role for sure, focused in Infrastructure but that requires the teams to understand good practices on how to deliver software and a deep knowledge in Infrastructure and a mindset focused on reliability and maintainability.

1 Like
  1. If you’re not able to get experience as an SRE in your current organization, how would you suggest to get your training and getting hired?

This will depend on your starting point, how much do you know from the SRE role already and how much do you need to invest. And what is your goal? If you want to create this position in your company I would suggest to start understanding the challenges of Infrastructure or Operations and see how you can help them, of course you need to invest in understanding those areas. If you want to learn a new craft I would say to start looking into what is asked for the role your are aiming for and learn from others (tutorials, training, etc), from reading and from blog posts.

At the end it really depends on you (your context) and your goals, but I believe that we can all achieve what we define for ourselves if we keep a steady course and not give up.

  1. Given the product-centric approach on SRE, what are your thoughts in using let’s say Scrum in organizing SRE delivery?

I think it makes perfect sense, at the end of the day you have to deliver new features to your product each sprint. Nevertheless do not forget the other type of work you have to do, like closing tickets or providing support, we handle it by allocating time in the sprint for these, we begin with 60% of time closing tickets, training new members and identifying opportunities to automate and 40% of time for product related features. The objective was to invert this tendency as we advance in time. Keep an eye on these times to understand if they are feasible or not and keep readjusting to what better works for your context/team/organization.

  1. SDET to SRE is interesting but I would also be interested to know more about becoming an SDET (maybe separate talk in future as im sure its a long conversation)

Indeed this subject is enough for a new talk :slight_smile:
I would be happy to share with you how it happened for me so reach me and we can talk about it :slight_smile:

  1. I’m vaguely curious what happened to the people that left his company and if the other company may also change to have those same processes (having SREs)

The ones that have left in the beginning were searching for roles in the testing space, SDET, Automation Engineer, etc and for what I know they continue their career in the automation testing space. The ones that have converted into SRE continue their path in SRE and some have shifted to other companies in SRE roles.