Ask HN - how to be a great software test engineer?
11 comments
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.
- 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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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 ?
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 ?
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.
Communication skills will definitely come in handy since working based only on specs can sometimes mislead you in a very bad manner.
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".
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.
- 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.
You'll be the first to be cut when the axe falls. Turn yourself into an SDET as quickly as possible.
What tools do you guys use?
Fitnesse? GreenPepper? Cucumber?
Is anyone into specification by example?
Fitnesse? GreenPepper? Cucumber?
Is anyone into specification by example?
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).
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).
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?
Cheers