Talking testing, automation... and anything else.



23
Sep 18

Fail Faster

The primary goal of automated tests is to find failures as quickly as possible. The general idea being that bugs found earlier in development are cheaper to fix. This is generally true, but automation isn’t the only way to fail fast. Here are a few tips for failing faster that have worked well for me, and may work for you too!

Get QA involved in planning

During planning, QA should be building a mental (or even physical) test plan. This is the perfect time to start asking questions about how to test this new feature. Perhaps you’ll need a special resource, like a third-party tool that you’ll use to aid testing, or maybe your tests need to run on an isolated server. Identifying these needs during planning can give you the time you’ll need to acquire them, and get them in place for testing.

This is also a great time to aid testing by baking things right into the app. For example, having a parameter flag in an URL, or an a/b switch, can make a feature much more test-friendly, and impact the speed of your testing effort.

Code review

The importance of meaningful code review cannot be overstated. Whether you’re pair programming or reviewing code before it’s merged, this is a great time to not just find bugs, but to prevent future bugs by gaining a shared understanding of the code, removing complexity and ambiguity, and ensuring code standards are being followed.

Write e2e tests while code is in active development

The best time to write e2e tests is while the dev is actively developing the feature itself. This can be done in a TDD fashion, whereby you create your tests and page objects, have them fail, and get them to pass as the feature is completed. This is also the perfect time to quickly find CSS bugs, and/or add CSS tags to make automating easier. I mean, who doesn’t love a solid ID to grab onto?

Additionally, writing and committing e2e tests directly in the app feature branch can help keep the app code and test code organized until they are both merged… together! It’s also great to have the dev writing the feature, review the e2e tests. Who better to review the tests than the dev that wrote the code! This has the added benefit of keeping devs acquainted with the e2e code.

Handoffs/desk checks

These short meetings are held after the app code is reviewed, but just before moving a story to QA. In this meeting, a dev visually runs through the feature for QA, showing off the feature and answering questions. The primary goal for this meeting is to ensure a shared understanding of the feature, including any changes since it was planned, and any testing tips the dev derived during coding. It’s also a great time to make sure your automated tests (unit/integration/e2e) are up to snuff.

Sluff off on this process at your peril; you WILL regularly find bugs during it. I promise.

Plusone Linkedin Facebook Twitter Digg Email

20
May 18

Unit tests vs. Integration tests

I’ve had to explain all of the points MPJ makes in this video, many, many times. Now I can just send a link to this video. And while I tend to call out e2e tests as their own thing, deep down they’re really integration tests.

Plusone Linkedin Facebook Twitter Digg Email

11
Jan 18

Cypress.io Review

If you’ve seen my github account, you’d likely note that I like trying all the automation tools, and see the value in most. And why would you not try ’em all? Case-in-point: today I played around with an interesting–SPOILER: if not tragically flawed–automation tool called Cypress.

Yeah, I don’t mean to be a downer; I say this hoping to save others the time I spent today… if you need to switch/handle multiple tabs/windows/iframes in a browser for your tests, Cypress will NEVER allow you to do this. They state as much on their website, in the Trade-Offs section. Given its massive ramifications, perhaps it should be stated more upfront?

Cypress is an interesting bit of tech; especially since it doesn’t require Selenium/Webdriver; has built-in implicit waits, and other goodies. The long and the short of it is, I don’t see how this tool could ever take the place of any webdriver-based tool, given its current limitations, but if those don’t bother you, take a look!

Plusone Linkedin Facebook Twitter Digg Email

14
Sep 17

It Never Fails…

The weather is always most beautiful… the last week of a sprint. I need a waterproof laptop, with wireless broadband, available everywhere on the planet (though I’d settle for just all of Wisconsin). Is that too much to ask?

Plusone Linkedin Facebook Twitter Digg Email

02
Mar 17

Accidental Load Testing

In my example test automation code, I generally setup the tests to run against my own server. I feel that it would be downright rude to have random folks running these tests against my digital neighbors. I’m happy to have them run against my server… I mean, it’s kind of the point of the thing.

The downside is when folks start tinkering with the code… and maybe change a locator within a loop to see what happens. Like my friend in India @ 202.88.222.186 likely did this morning (well… my morning, anyway), and started PEGGING MY SERVER :)

It’s fine… I do appreciate the accidental load testing

Plusone Linkedin Facebook Twitter Digg Email