A Road to SDET

You want to move on from manually testing code and features you barely understand and really put the Software Developer in SDET — but like so many others before you, where to start is utterly overwhelming.

Sounds familiar? Then read on.

The number of things you could spend your time learning is vast, so I’m going to narrow it down to how you might get started, using the technology Dunelm engineers use day to day and lay out some routes we can take to level up our testing, depending on where you are in your SDET journey. I won’t be teaching you how to use every one of these tools, but instead laying out the markers on your path to quality engineering — I suggest you skip around on this article until you find the sections that interest you.

When you want to start testing APIs, a good place to begin will be getting to grips with tools like Postman or Insomnia — which let you run the same calls to APIs at the press of a button. You won’t need to be able to code just yet, but you can get into the habits of DRY (Don’t Repeat Yourself) tests, making use of url variables and other useful features. You can run entire collections of these tests at once, at which point we’re already away to the races with automation.The next step would be to make use of the tool’s Export feature to get a snippet of code that you can use to run, try to follow what it’s doing to set the request headers and read the results. Once you’re comfortable here, you can start to create test suites in the tool itself or as part of your project’s code repository, often referred to as the ‘repo’. Doing this as part of the code repository itself means sharing tests is easy, we can run them automatically when engineers make changes (Automatic automated tests!) and opens us up to more advanced tools and techniques like PACT. If you’re not yet comfortable using the command line, there’s UI tools like Git Kraken.

From here we can add our tests to the deployment pipeline or pre-commit hooks, so that when engineers make changes to the code the test suite runs and generates us feedback. Once you feel comfortable with code I strongly recommend thinking about how APIs might be misused, beyond simply sending bad data. Malicious attacks like Cross-Site or SQL Injection require a little more technical knowhow to test for but are huge if you find them. At this point you truly are a Software Development Engineer in Test when it comes to APIs.

When you want to start testing front end such as websites, apps or other parts of a UI we can start out by using tooling to speed up our process. An excellent first tool in our kit is google’s own page inspector which we can use to look for errors, excess api calls, slow loading times and more. No code web automation starts with tools like Selenium IDE, where we can record ourselves stepping through the website and playing back that journey as a regression test whenever we need to. Robust UI tests branch off of this, using Selenium, Cypress, Test Cafe or others to write code that navigates for us, takes screen shots or records. Here you can start to think about how CSS Selectors work, automate testing in lots of different resolutions and more. True web automation however comes when we move these tests into a pipeline and leverage tools like Browserstack or pipeline containers to automatically test different browsers’ behaviour every time an engineer submits a change. Web Automation experts will start to know why tests are flakey, writing good selectors that grab the same UI elements even if superficial things like the order of buttons changes, reusable test steps that help the team test faster and knowing how to assess the validity, not just the accuracy of tests. SDET Innovators will start to introduce technology like Visual Testing, where we go beyond the HTML and CSS and actually assess the user’s experience, capturing test cases that simply can’t be handled by traditional HTML web selector tests.

When it’s time to reconsider your ways of working you may find yourself asking what more is there beyond a huge table in excel or a JIRA ticket. To start with, we can start to track our progress with tools like Testrail, where we can create re-useable regression packs. Quality in the code means we can add automated unit tests, track test coverage with plugins like Instanbul and help ensure code quality. Get involved with reviewing the Checkov reports generated by the pipeline, security vulnerabilities are an important part of the software we’re testing. Reporting and analysis can be done with tools like DataDog to review errors and throughput for our services, catching problems that would never show up during testing and software like Sentry can let us see the errors users are facing but not telling us about — meaning you’re ensuring quality for your team on a whole other level. Find the holes in your process with things like DORA metrics, understand what’s driving a loss of quality and where. If the team is shipping a lot of features and the Deployment Frequency is increasing, but the Change Failure Rate is also climbing, you need to step in and advocate for quality over quantity. The bests tests are the ones we never have to write so studying techniques by testing champions like Angie Jones and learning how to prioritise our testing is key.