I’m going to throw out what might be a challenging concept: You don’t need to know a ton of business logic to automate tests effectively.
The longer I do QA and automation, the further I actually get from having to slurp up a bunch of specific business logic.
While automation’s important to getting quality product shipped on time, the real high-value stuff comes from enabling those around you to work at maximum efficiency–providing something for the people that do have to know “how the sausage is made” to translate their thoughts into an automated test case.
There are some huge advantages to getting altitude on business logic like this:
- Takes less time to ramp up: The first… I don’t know, two weeks, are crucial when starting a new team or company. This is the best time to get a quick win, while you haven’t been indoctrinated or become numb to any business pain. Not having to ingest as much information will allow you to get productive faster.
- Brain doesn’t fill up as fast: I think peoples’ brains have a capacity for how much stuff they can hold. All the nuances of your industry, your company, your department, organization and team can really pile up. Focusing on just the stuff that solves particular problems takes up much less space, and frees up brain matter for harder problems.
- More of what you’ve learned is portable: If you stick mainly to learning things that help you automate better in general, it will travel with you to new teams, new industries and new companies. While learning the other stuff does help carve out new mental pathways, the specifics don’t come with you.
Here’s an example:
Years ago, I wrote automation for a web app. It looked and felt like the app itself. The directory structure was modeled after all the pages that could come up. There were layers of simple operations wrapped in more complex ones, all the way up to actual business logic.
It was difficult to wield, even for me.
More recently? My focus is heavily on usability. I don’t want anybody to have to think too hard about how to cajole the computer into testing this thing. Instead, I write automation frameworks so that people could just describe what they are doing as they’re looking at the app itself.
There’s a lot of logic built in to allow them to do that, but what I was thinking about the whole time was not business logic–it was, “what’s the best way to make this the simplest it can possibly be for my teammates?”
It can be tempting to think that knowing a lot of business logic helps you be more valuable. But it really just turns you into an information silo.
Some people do have to know a lot of arcane stuff about the business, but not everybody does. And I think that’s especially true for test automators.
Not having to think as much about business logic is very freeing. Freeing up those around you to be awesome is very valuable.