The Importance of Words: Waterfall vs Agile
Waterfall methodologies are often seen as the antithesis of Agile, and therefore ‘bad’. But what does it really mean for something to be ‘waterfall’? Are you...
Should SDETs Write Unit Tests?
Recently I was asked if SDETs should be expected to write unit test, and I feel the answer I gave at the time wasn’t sufficient, so I wanted to write a quick post to provide a better answer.
Sometimes other engineers don’t write the best tests. Your job is not to write tests for them. Writing valid, and effective tests at the levels they’re responsible for is part of their job. They should be capable of doing that on their own.
As an SDET, or QA Automation Engineer, you’re job is to make sure there’s sufficient and effective automated tests at every level (be it unit, integration, end-to-end, or any other level) to build enough evidence in the quality of the code to feel confident in pushing it out to production, or to prevent it from going out because there’s too many problems.
Your job is to think about how the desired behaviors of the product play out as a whole, and to think about what level a test can be performed at. Your job is to consider how these behaviors will play out when an actual user uses the product. Your job is to consider the big picture.
You’re there to make sure the other engineers don’t lose sight of the forest for the trees.
Should you be writing API and end-to-end tests? Yes. You are the owner of those tests, and they’re your responsibility.
Should other engineers be writing API and end-to-end tests? Yes. Quality is their responsibility too, and if they identify a test that you don’t have written, or you don’t have the time to write all the necessary tests, they are more than welcome to help add those tests.
Should you be writing unit tests? Yes. For the same reason a developer would write an API or end-to-end test, you should be equally as welcome and comfortable writing unit tests in the code that they own.
It’s all about collaboration.
You’re a software engineer, and should be comfortable working with someone else’s code. You don’t have to start off being able to write a backend server or a frontend, though.
If you find it difficult to understand or work with the code other engineers have written, then it’s a perfect opportunity to pair program with them. You’ll get more exposure to other kinds of code logic and structures, and they’ll potentially find out about a test case they may not have considered, and also get some feedback on how to improve their code.
The goal is to speed things up and improve not just the quality of the product, but also the quality of the code itself. Having more eyes on the code means more feedback, and more opportunities to make the code more usable, readable, maintainable, and extensible. This goes for their code and yours.
If we work together, everyone wins.
2022
The Importance of Words: Quality
We care a lot about the word ‘quality’ in the software industry. But what actually is quality? How do we use the word in our day to day life?
The Importance of Words
It’s natural (and inevitable) for words and phrases to change in meaning over time. But what if they were chosen for a purpose, but their meaning changes eno...
2020
Prisoner’s Dilemma in Testing: A Mini-Waterfall Simulation
A sustainable development process needs checks and balances to ensure we move forward as quickly as we can safely. But what happens when there are none?
“What would QA do all day?”
If the developer wrote the tests for their tickets, what would QA do all day? More importantly, what are the implications of that question being asked in the...
The Harmful Obsession With DRY
The intent of DRY is to help us find potential opportunities for abstraction. Many take it to mean we should never repeat a block of code. However, this inte...
Grey Box Testing: Less Is More
What is grey box testing? How can it benefit us? How is it different from white or black box testing? Are they all required? Do they dictate how we design ou...
1 Assert Per Test
You’ve heard it before, and probably many times. But why exactly is it the rule that should only have 1 assert per test?
Should SDETs Write Unit Tests?
Whose responsibility is it too write unit tests? Should SDETs know how to write effective unit tests?
Let’s Talk About Cypress
There’s some fundamental issues with the claims that Cypress makes of themselves that need to be acknowledged. Let’s take a look at their claims and see if t...
Is Selenium Actually Flaky?
We’ve all gotten frustrated dealing with flakiness once we start involving Selenium in our tests. But is Selenium really the problem? What can we do to solve...
Grey Box Testing - React Redux Part 2: Cutting the Fat
The usage of React and Redux together creates fantastic opportunities for refining tests. Let’s go over one of those opportunities and the benefits it provid...
Grey Box Testing - React Redux Part 1: A Primer
Before we can refine our tests to take advantage of React and Redux, we first have to understand what they do for us, and a little bit about how they do it.
Scientific Testing Part 3: Leveraging Confidence
Now we know how to maximize test validity. But how can we leverage that in other ways than just providing test results to someone else?
Scientific Testing Part 2: Validity
The validity of tests helps build our confidence in them and determines the value they add to our test suites. But what does it mean for a test to be ‘valid’?
Scientific Testing Part 1: Getting Back on the Right Track
Software tests are a form of scientific research and should be treated with the same scrutiny. To show this, let’s go over what ‘science’ is.
2019
Building Good Tests
A collection of testing maxims, tips, and gotchas, with a few pytest-specific notes. Things to do and not to do when it comes to writing automated tests.