Ask HN - how to be a great software test engineer?

It largely depends on what they're expecting. The position could range anything from executing manual tests to setting up and running a continuous deployment infrastructure and coding tests to run against every commit. As you're on HN, you probably want something like the second.

I started as a Test Automation Engineer about a month ago, and I'm using Selenium to write tests for all sorts of things -- do password changes work? Does the logout button work? Can a user edit another user's profile? Selenium is proving to be incredibly versatile. Grab it and try it out. Create your tests as actual code; don't rely on Selenium IDE.

Feel free to message me (email in profile) if you have any questions.

Some general thoughts (I was a software engineer in test for a few years):

- Be a good developer--all the advice and best practices for software developers still applies to you. Much of your job will be coding automation, test suites, integration tests, etc. All the best practices of writing solid, readable code will definitely be useful to you.

- Work closely with your fellow developers. Have them code review their checkins with you so you understand how their code works. Find out what they think are risky areas to target. Help them understand how they can write more easily testable code. Don't fall into a trap of developers throwing code over the fence at test, and test throwing bugs back at them. Everyone is in it together to ship a quality product.

- Understand how your customers use your product and make sure their usage is covered in your tests. It's easy to look at a spec and start trying to test all of the inputs, edge cases, etc. It's better to understand how your customers/partners will use a feature and make those your highest priority tests.

- Try to catch bugs as early as possible. Automate your test execution, run test passes against changes/checkins, and alert yourself when changes cause new test failures. If you let too many bugs get into a build you'll waste tons of time sifting through hundreds of failing tests to find the bugs.

If it's a Unix-like environment, learn as much as you can about at least one Unix shell (try "zsh" or "bash"; just stay away from "csh" or "tcsh"). You should understand things like process management, e.g. "&&", "||" and subshells. You should also understand file management, e.g. ">", ">>", ">|", and the program "tee". These help with testing because you frequently have to write scripts and organize output files, and you have to understand how the system handles things like failed programs.

When testing it's quite common to have to deal with lots of files and do filtering. Think of how you'd organize data. Reuse things like scripts for driving tests. Learn tools like "grep" and "diff" and "sdiff" and a scripting language like "perl" or "python". For example, it's very common to need to automate test audits by filtering out volatile data such as time stamp lines and comparing the remainder against a set of golden results.

Learn at least one widely-used testing environment, such as the "unittest" and "doctest" modules of the Python standard library. It doesn't matter if your company will use something else, it's useful to pick up on some terminology (e.g. the concepts of setting assertions and creating standalone testcases) and to see how at least one framework does things.

Practice being pessimistic. For any given system, don't let yourself only test the "easy" stuff; try to think about weird things that could happen. Boundary cases are often very useful, e.g. what happens when -1 or 0 are given as values, or very large numbers.

Practice editing. Tests should be extremely focused because when they fail you want to know exactly what went wrong. This kind of focus also helps outside the world of testing.

Learn to automate. If you have a language you enjoy, learn the popular test automation tools in that language. Someone who can automate testing is far more valuable than someone who can only do manual testing. Along with automation goes all the usual best practice of writing software.

Read about testing - lots of inspiration and ideas to be had. Anything by James Whittaker. O'Reilly's Beautiful Testing.

(Please fellow HNers add your favorite books in response - would love to know what others recommend).

These are some great tips. One thing to be aware of is that there will be a natural tension between your and the dev team, as devs tend to be a proud bunch and your job is to point out deficiencies in their code so many won't appreciate that. Accept this tension as part of your job, and be sure to always represent the customer as tdicola mentioned.