Becoming a fantastic Software Engineer in Test and Automation

The kinds of "test" and "verification" automation I've done in the past are vastly different from the kinds you'll be doing. Though I've never personally faced the really extreme needs (read: "requirements") of diving physical test equipment with a Real-Time OS to get sub-millisecond resolution, or need to resort doing the testing (read: "verification") through simulation for even faster resolutions, the general concepts of "Quality Assurance" will still apply to your situation.

1.) Always show up with solutions, not problems.

With good reason, Rule #1 is the first thing to always remember. You never want to be the person who impedes development or release. You always want to be the person who improves development and release. By the nature of you job, you will be the person who often needs to deliver the unwanted bad news, but if you gain a reputation for delivering the bad news with some good news, like ways around a problem, then people will seldom dread talking to you. Take responsibility for improving the product, offer fixes, and still offer fixes when it's not your job to fix the bugs.

Never utter the words "show stopper." Even if you are right, it may not be your decision, and you can easily make enemies of the people you need to work with every day. Instead educate others on the potential harm to customers, potential loss of customers, and if that doesn't work, the potential harm to the viability of the company as an on-going venture. When you need to do this, and you will need to do it, be prepared with multiple paths for working around or fixing the issue along with a cost estimate for fixing the issue. In other words, lead others into uttering the fateful words "show stopper." Surprisingly, you job is to make the risks and consequences known, as well as provide alternatives to mitigate the risks and avoid the consequences.

Pointing out mistakes is always a touchy situation. Many people react poorly to being told that something they did is wrong, so try to memorize the secret formula, "We can improve X by doing Y to avoid Z." The "we" is important and you can even toss a "probably" in there somewhere for added effect.

If you can reliably remember the secret formula even when your scalp is sore from pulling out all of your hair, then please tell me how. ;)

2.) You will always have constraints, so know and memorize them.

When an executive spends $200K on a piece of test equipment, and the other engineers want data at some super fast resolution beyond the capacity of the equipment, you are the person responsible for knowing the constraints of the test equipment. This has actually happened to me, and it's a whole lot of no-fun. You get stuck between a rock (the other engineers) and a bad place (the exec who doesn't want to look bad for buying the wrong/cheap equipment). Sure, it may seem anecdotal, but you'll be surprised how often you are asked to do the impossible.

When you know the constraints of your test system, then you can show up saying, "We can do X with what we have currently, or you can push upstream for more investment in test infrastructure. We try doing X to see if it will suffice for your needs?"

In your situation with web apps, particularly mobile-ready web apps, testing will require a big investment in test infrastructure. If your web app is using any of the newer direct-to-hardware (WebGL, AudioAPI, ...) features, just using emulation (system/browser images with VMware or similar) may not suffice to give proper test coverage. Emulated hardware is never perfect, so you'll often need access to real hardware. Of course, you can often do tons with just emulation, but knowing where emulation will fail in strange and unexpected ways means knowing the constraints of emulation.

Knowing your constraints is knowing what you can actually test. When others have unrealistic expectations, knowing y...