4 ms·
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 st
by tdicola 15y ago
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.
- twelve45 15y agoThese 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.
- Jacquass12321 15y agoOne 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.