
Ask HN - how to be a great software test engineer? - zxcvvcxz
Hey guys,<p>I am currently going for a position as a software test engineer at a big software company. I'm wondering what advice you guys would have for this type of position, as I would consider myself relatively new to it. Additionally, are there any resources anyone could recommend?<p>Cheers
======
tdicola
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.

~~~
Jacquass12321
One minor nitpick, working closely with developers isn't always an option or
necessarily a good idea. Working too closely makes it easier for assumptions
and to get transferred over. I really like having testers who can take a
completely fresh look at the application and find issues with stuff that I
just didn't think to try because I know how the page was meant to be used.

In addition certain industries such as medical require testers to be separate
from the development process entirely. On my current project for example we
aren't allowed to bring in the test lead to our code reviews, we've discussed
it.

------
zck
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.

------
hodbby
I must say most of the comments here are either irrelevant or bunch of crap:
You asked about software test and people wrote you about automation which is
irrelevant to your question. Tips from 4dr144n are very good.

I am doing QA for the last 13 years, so these are my tips: 1\. Do not take
anything as OBVIOUS. for example- People say the sun rise from the east. how
do you know? did you see it? you should test it and confirm it is true. 2\. To
find many bugs doesn't mean you did a good job, you should try and find the
quality ones. we call it 'Show Stopper' because they block the software from
being shown to the public. 3\. GUI bugs are as important as functionality
ones. 4\. Become a friend with the developers but let them eat shit with your
bugs. it will be easier for them to handle a shit from a friend. 5\. When you
report a bug- be as much as informative as can be (screen captures, logs,
debugging). the developer will appreciate it 6\. Be the best in the company
about the feature you are testing, make them feel you are the focalpoint of
that feature.

good luck man

------
4dr144n
I was a QA many years ago, for about 5 years. Here are my tips:

1) It doesn't matter which test suites you use - I wrote my most valuable
tests in straight Perl (ie no test suite)

2) The most important aspect of QA is communication with developers. Don't
just log bugs and let devs fix it in their own time. Have a chat with at least
one dev a day at their desk. Watch while they fix the bug - turn it into an
almost social, non-pressured action. Many bugs can be quite traumatic to
developers - your work is to soften this. Take interest in the code you're
testing.

3) When you find an issue, only then start testing the issue. For each issue,
try and find out as much as possible about the issue by testing it in as many
as possible states, with as many as possible input sets. Try everything you
can think of. Also try very hard to find a workaround for each issue. A lot of
information about an issue is embedded in the workaround.

4) Never stop hand-testing. Never stop refactoring results of your manual
tests into your suite. Treat your test suite as a product in itself, and log
bugs on it.

5) Mastering QA will turn you into a better developer. You'll pick up good
habits which you will never be able to shake again. You will write robust
code. Above all, you will be able to communicate with QA.

------
makecheck
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.

------
b0rsuk
I'm also looking for a job as a software test engineer (currently unemployed).
I have a small problem - I don't have a suitable project to test. I've heard
that software testing is largely a domain of large corporations, and you can't
really learn it if you don't work in one.

Could you suggest any places where I could find open-source projects in the
need of testing ? And how to select a project ? What kind of projects are
likely to need it, and when it's a waste ? Or - at least - where NOT to look
for practice in software testing ?

------
filenotfound
I've been a SDET for two months now, and I am fresh graduate. What I've
experienced so far is that you have to have a good understanding of the
product, the workflow and each scenario. Also you need to be a good dev for
automation purposes and troubleshooting should not be a pain in the neck for
you.

Communication skills will definitely come in handy since working based only on
specs can sometimes mislead you in a very bad manner.

~~~
mping
I second this, make sure you DO understand the underlying business and its
needs; also if you want to be friends with the devs, make sure you provide the
most helpful info about failing tests, not just "it is failing".

------
iworkforthem
Here's what I would do.

\- Set up a continuous integration server, I use this test server whenever I
want to test any test cases. Also, it allow me & the mgmt to always be in
touch with the development team.

\- Make sure Unit Test cases are present.

\- Semi-automate testing of GUI, using tools like Selenium, I will be cover
most of the testing on UI.

Optional: Find out more about the Top 10 OSAP, make sure I cover most of the
items listed.

------
aaronbrethorst
You'll be the first to be cut when the axe falls. Turn yourself into an SDET
as quickly as possible.

------
stephen789
What tools do you guys use?

Fitnesse? GreenPepper? Cucumber?

Is anyone into specification by example?

------
locopati
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).

