DEV Community

Cover image for Raise->Fix->Deploy mindset
José Carréra
José Carréra

Posted on

Raise->Fix->Deploy mindset

As a software developer in test, it is part of your job to maintain the test frameworks, alongside many other tasks, which eventually involve raising issues. On the other hand, fixing issues is not expected of you, but why wouldn't you be able to do that?

Implementing bugs fixes and getting them deployed can have a great impact on your team's attitude towards quality. In this article, I'll explain why I believe having a Raise ➡️ Fix ➡️ ️Deploy mindset might help you succeed as a software developer in test (SDET).

Alt Text

What do I mean by Raise ➡️ Fix ➡️ Deploy mindset?

As an SDET you shouldn't repeat the pattern of raising bugs and waiting for them to be fixed by the developers. You can take action on it, by joining the developers on fixing issues and deploying those changes. 

It is a change of behaviour and not a skill. Frequently, we tend to isolate ourselves in our job title and description, missing out on opportunities to enhance our skills and to add value to our teams in different ways.

You already have the skills, so why restrain yourself to creating/maintaining test frameworks?

Alt Text
unsplash-logoBaciu Tudor

Let me then describe to you in a bit more detail what each "phase" entails:
Alt Text

Being an SDET means you are expected to be the quality expert in your team, helping drive its processes and the team's practices to deliver software that meets user expectations.

As part of your day to day job there are going to be issues raised from different sources, like:

  • Test automation suites
  • User feedback
  • Monitoring/Alerting
  • Exploratory testing

Hopefully, if your whole team is responsible for software quality, this is not going to depend only on you. At this phase, nothing really changes, tickets are raised, which will then be prioritised and fixed.

Alt Text

This is where the bigger mindset change comes to place. Especially if you are from a more traditional QA/manual testing background, you probably always felt the existence of a barrier, where your responsibility would stop at the time the bug was raised. At that point, you would wait for the developers to fix the issue, so you could re-test it later on.

To be able to fix issues, the main constraint is your knowledge of the codebase. One way to address this is to start pairing/mobbing with developers on either bug fixes or feature development. By doing this, you'll enhance your understanding and therefore feel more confident to take on features/bugs on your own.

Do not assume you need to fix them on your own. Instead, try to take advantage of pairing with developers or at least asking for help if you get blocked when trying to fix/change something in the code.

Getting involved with fixing issues, also means you are getting the opportunity to double-check the test automation coverage for that fix. Together with the code fix, you'll be able to review the existing automated tests in place, and change/enhance if they were not properly set for the existing area.

Alt Text

As any code change, your fix should go through your internal team's process. Code review, pull requests, etc. are also going to present interesting opportunities for you to deliver proper fixes and learn.

This also means, that you should understand how your team's deployment process and pipelines work, so you can also do all the necessary steps to a successful release.

Some of the benefits

😃 Developers and SDETs working more closely.

😃 Increased trust and shared knowledge of existing challenges

😃 Increased knowledge of the codebase and coding skills

😃 Opportunity to improve testability

😃 Constant reviewing and improvement of the existing automated test set

😃 Helps eliminate the "role" barriers, where you are not limited by what is expected by your job title

😃 Focus on getting things done and help the team deliver value to customers

Watch out 

😟 Requires a well-established development process otherwise, it might lead to software in a worse state

😟 Might be tempting to just fix what matters to you, but remember that the team or product owner should still be the one setting the priorities. You can influence it, but you should not bypass it.

So, what is stopping you from fixing some of the issues you have raised?

Top comments (0)