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
- 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.
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.
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 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
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.
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.
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 ?
Communication skills will definitely come in handy since working based only on specs can sometimes mislead you in a very bad manner.
- 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.
Fitnesse? GreenPepper? Cucumber?
Is anyone into specification by example?
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).