11–15 of 15 posts
- 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.
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 ve…
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.
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
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…
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.