Across the industry of software development we’ve seen a shift towards companies asking for SDIT / SDETs in their teams instead of traditional testers. In this post I’ll outline the the discussions around this topic that I’d had with recruiter Daniel Erasmus at the iO Virtual Meetup in April.

What is an SDIT (Software Developer In Test?)

An SDIT – Software Developer In Test (sometimes abbreviated to SDET – Software Development Engineer in Test) is a team member with strong software development skills that can be used to support a team’s test automation capabilities.

Generally, an SDIT’s primary focus is on development; they may know multiple development languages and have an understanding of software design principles. However, this can mean that there is less of a focus on the testing skills that a QA or a Tester can bring to a team: championing quality, critical thinking, risk heuristics and exploratory testing skills. Usually these roles will play to the strengths of a developer: implementing automation frameworks and scripts for regression tests or supporting Test driven Development through the creation of Unit or Integration tests in Red-Green-Deploy delivery styles.

To a company looking to speed up their testing, or to implement Continuous Testing as part of their delivery pipelines an SDIT is seen as a Unicorn (a recruitment term for a mythical perfect candidate).

Why are companies looking for SDITs?

With the shift to Agile and continuous development testing needs to be able to provide faster and more reliable information on a system’s perceived quality. As such testing needs to start earlier and run faster; we talk about testing “shifting left” as it moves earlier into the development process, through design and development.

The view of many companies is that the traditional tester is manual only, that they cannot contribute or champion quality earlier in the development lifecycle as they are not technical enough. This is a viewpoint that has led to the term “manual testing” or “manual tester” being seen as something bad or undesirable due to the connotations of being less technical or skilled.

Hiring managers are frequently looking for a one man band, someone that can come in and implement an automation testing framework, a devops pipeline and maybe do some development on the side as a way to reduce costs. To this end we see job adverts looking for developers with “exposure to testing” as it’s thought that testing should be the developer’s responsibility. However, there’s the risk of hidden costs from a lack of quality championing that comes alongside this view.

The biggest risk is that there’s an automate everything culture in these teams and companies asking for SDITs, a prevailing view that testing equals automation. Automation is good for regression testing or checking, confirming behaviour we expect to be happening is happening, but isn’t as good at telling us what we should test. For that we need to compliment automated checks with exploratory testing that can find information about the product and what to test.

As teams need shift left testing, implementation of automation and be exploration of products and systems we need technical testers that blend the skills of an SDIT and a tester combined.

Becoming a Technical (or full stack) Tester

To be a technical tester means to blend together testing and SDIT skills, this will allow for engagement with the team during development as well as the ability to champion quality.

Testing skills (to know what to test):

• Risk Analysis
• Testing Heuristics
• Critical Thinking
• Exploratory Testing
• Communication of issues
• Championing quality
• Domain & Business knowledge
• Human factors

SDIT skills (to know how to test):

• Architectural Knowledge
• Setting up Automation Frameworks
• Tools
• An Object Oriented language like JavaScript (enough to be dangerous)
• Types of tests & how to review them

Developing these skills will take time and cannot happen over night. In my own journey from being a purely manual to a technical tester I followed a path over many years.

Starting by using SQL to get used to syntax and scripting.

Increase your information gathering through the use of APIs and exploratory testing. Use this testing to hone your critical thinking, risk identification and testing heuristics.

Start to use the developer console in the browser, specifically the network tab, to check information going from the front to the back end.

As an initial introduction to automation start to use your knowledge of APIs by adding automated test snippets in Postman.

Build your automation capability by working with developers to add tests to the code through paired TDD or BDD with developers. Then extend this out to learn more about software, architecture and code by pairing to review Unit tests and debugging issues (this means you can support the developers with adding to tests).

Learn an Object Oriented language like JavaScript using a great course like CodeAcademy. It’s not that scary and will help you be able to start writing automated scripts… just remember that you just need enough to be dangerous, you don’t need to know everything.

Once you know the basics of a language, try using Selenium to do some testing, I used the Evil Tester’s getting started with Selenium course and it’s a really easy to follow practical guide.

Then start to investigate more specific technical elements of testing. I looked at cloud based testing and the use of Docker, but why not look at penetration testing or performance testing?

So, do we all need to become SDITs?

No, but…

The modern testing market is increasingly more agile and more technical with the expectations being that a tester will be able to shift testing left and assist in automation efforts. You might not have to become a full developer with an “exposure to test” but you will need to be dangerous as a tester when getting involved in the technical aspects of a team’s work.

The same is true for existing SDITs, you need to be dangerous when it comes to championing quality and that means knowing where risks lie and how to explore to find and share more information about a product (in addition to checking for things we already know).

Think about it as being T-shaped where you have depth of knowledge in a specialism and a breadth of testing skills that can support championing quality in a team. An SDIT may have a deep depth of skill in automation or code but also wider knowledge in other areas of test. Likewise a more manual tester may have a deep depth of skills in exploratory testing or test strategy but will have a breath of shallower knowledge in technical aspects too.

It’s not bad to have a specialism that you’re especially proficient in, but that shouldn’t be your only skill. We need to ensure that we meet in the middle, neither SDIT or pure QA, to be more well rounded technical T-shaped testers. By doing this we:

• Meet market demands.
• Show that testing isn’t a low skilled or nontechnical job.
• Help integrate better with developers in teams by sharing language.
• Shift testing left and get to do loads of cool and interesting stuff.
• Help to change minds towards people wanting testers in their teams.

We don’t all have to become Software Developers in Test but we can’t ignore an increasingly technical job market. Become a Technical (or Full Stack) Tester and forge your own path of learning new skills.

A note for Recruiters

It’s tricky to push back with a client who thinks they know what they want. But gently prod to see if a developer is needed or whether we can challenge the ideas of hiring managers to see if they want someone technical that can champion quality. Help companies to see that testing is more than just manual script following and educate about the additional benefits a technical tester can bring to teams.

Also, when talking to potential candidates to fill a role or when sharing job specs the more that you can include the testing aspect of the role (over just tech and tools) the better. It’s awesome to know what the ask is of the role, rather than just a list of what they currently use.

Know that a developer in test may have a different set of skills and outlook to a tester when it comes to exploring a system and championing quality. Learn all you can about these differences so that you can be confident when talking to clients and candidates about what is needed in a testing role.

Let’s ensure that the industry knows that testing is a technical job and that Technical Testers can bring the benefits of technical know-how alongside powerful testing knowledge and skills.