One of the most powerful reference points for automation engineers (especially on greenfield projects) is the Test Automation Pyramid concept. To summarize, the pyramid suggests that the lower-level application tests (unit, component, functional tests) should be the majority of an application’s overall test count. As tests become more high-level — covering end-to-end functionality, and possibly rely on systems outside of the application under test — it is a good practice to have fewer of these.

Here are a few reasons why:

• Unit tests are quick to create, especially for a team that is doing Test-Driven Development
• Lower-level tests (unit, functional…

The software tester’s kryptonite: test data. In a world where applications can serve millions of customers, it’s impossible to confidently say “we’ve tested everything”. Here’s the story of one approach I used to increase our coverage confidence.

Testing software can feel like a daunting, never ending task. As testers, we learn quickly that it’s impossible to test every scenario, every corner of an application, and uncover all defects. I have worked on applications that vary a lot in complexity. Some apps are simple: their functionality is set and every user consumes it as-is. For example, an application that shows your…

How to make user story estimation more valuable for your team.

As a Scrum Master, Agile Coach, and general development team member, one of the exercises I most frequently see teams struggle to conquer is story estimation (aka story pointing). Understandably, the concept of estimating work can be abstract, which is often not a technical person’s preferred way of thinking. The approach to teach teams how to estimate can involve lessons on the Fibonacci sequence or assigning sizes to pictures of random animals. Time is spent drilling the idea that points != hours into everyone’s heads. …

Unidentified problems could be impeding your journey to Agile nirvana.

Over the last five years, I’ve been lucky to experience the full spectrum of Agile journeys across small and large organizations. For two years at a large financial services org, I was a test engineer on a Scrum team that went through a few changes in Scrum Masters. …

So, you’ve set up a sweet automated test framework. You’re running it in your CI/CD pipeline, builds are rejected if tests fail, your regression tests are a fraction of the manual effort they once were, and you’re releasing to prod whenever the h*ck you want! Life is good. Except for that one darn test that fails every few runs. Oh, and the other one that takes a full 4 minutes to execute on Thursdays. Well, I guess there’s the few that have never, ever failed either…

There’s a ton of untapped info to gain from taking a holistic, tilt-your-glasses-down and…

A common conception about software testing is that QAs sit at a computer, enter random DROP TABLE statements and negative numbers into every web form they can find, draw up bug after bug, and call it a day. While this sounds kind of fun, a day in the life of a tester is generally not this glamorous. After 3 hours of meetings, 2 hours spent trying to fix the test environment, an hour re-testing bugs, the rest of your ???-hour workday in-sprint story testing, and regression, rarely is there time to sit down and focus on Breaking The App. …

As any SDET knows (or will eventually learn) — you can’t automate everything. Nor should you, as there are simply things that still require a human eye to sign off on. There’s an art to the manual software testing practice and our human ability to question things that automation tools can’t completely replace (yet…). When bringing test automation to the table for the first time, the main focus tends to be: “which of these manual tests can we automate?” And this makes total sense. This is usually a hefty time investment upfront with a promising long-term time savings. Manual testers…

An all-encompassing guide to SDET/QA interviews. Brush up on your coding, test planning, and whiteboarding.

Of the last four job interviews I’ve…endured, three of them really ran me through the technical ringer. Some questions felt lucky, with simple SQL queries and FizzBuzz-esque concepts. But traversing an imaginary random paragraph using a mapping function to count and return the most occurring word? Okay, haven’t encountered an automated test scenario needing to do that, but go off I guess. Some companies seem to have a better finger on the pulse of what SDETs/Test Engineers/QAs are actually doing, coding-wise, than others. As I…