Ten Things I Learned in Software Testing
1. If in doubt, ask.
This is my rule of thumb not only in software testing but also in life, never ever assume. It's not safe for your heart and for your job. If you're in doubt of the system's expected behavior, you can always ask the product team. If you are in doubt if your bug is a valid bug, file it anyway. The risk of not filing it and finding it as production bug is way more expensive than filing it and your Development team rejecting it because it's not bug.
2. Developers are not the enemies
Although sometimes, there are developers who made us feel that our job is to clean up their mess. I have worked with a handful of great developers who collaborate with their testers effectively and the outcome is rewarding.
3. Prioritize.
First it's impossible to test all the permutations of every testcase we created. Second we can only work this much, so design and prioritize your testcases that will give you a good coverage of testing in limited number of hours.
4. Document.
Documenting that agreed conversation in IM or stand up meeting can save your ass in the future when that issue explodes in your face.
5. It's not about the quantity of bugs but the quality of each.
6. There is no such thing as bug-free software.
But we can always deliver a functional, usable and acceptable software application that meets the specified requirements and sometimes exceeds the expectation.
7. Automation is not the solution to everything.
While automation can be the best thing you can employ in your project, sometimes it creates more work than mitigate your load. First you need to analyze WHY you need to automate, you don't just automate for the sake of reporting to the higher management that your team has automation coverage. Once you're settled with the why, decide on the HOW, which includes selecting the automation testing tool that will best fit in your process and application then establish best practices; and consider maintainability when designing the codes. Then evaluate WHAT to automate, 100% automation coverage can be your nightmare instead of a dream come true. Automate only those you think that needs to be automated, otherwise maintaining a large sloppy test suite will be your rebound.
8. Testing is a continuous improvement.
Testing does not end in when your Dev fixed the bug and you've verified it to close. It does not end either after certifying that the new build is a "Go" or "No Go." Testing encompasses improvement not only in testing per se but also in software development process as a whole.
9. Don't break the system to prove developers wrote crappy codes.
Or to show off you are a better tester. Break the system because you protect the end-users, its the main reason why we are testing anyways.
10. Requirements is not the only truth and nothing but the truth.
If you think that the feature does not make sense in terms of usability although it is developed as per requirements, this should not stop you in bringing this up to the product team or project manager in an objective way. You'll never know, your suggestion could be the breakthrough of your application.
Happy testing!
This is my rule of thumb not only in software testing but also in life, never ever assume. It's not safe for your heart and for your job. If you're in doubt of the system's expected behavior, you can always ask the product team. If you are in doubt if your bug is a valid bug, file it anyway. The risk of not filing it and finding it as production bug is way more expensive than filing it and your Development team rejecting it because it's not bug.
2. Developers are not the enemies
Although sometimes, there are developers who made us feel that our job is to clean up their mess. I have worked with a handful of great developers who collaborate with their testers effectively and the outcome is rewarding.
3. Prioritize.
First it's impossible to test all the permutations of every testcase we created. Second we can only work this much, so design and prioritize your testcases that will give you a good coverage of testing in limited number of hours.
4. Document.
Documenting that agreed conversation in IM or stand up meeting can save your ass in the future when that issue explodes in your face.
6. There is no such thing as bug-free software.
But we can always deliver a functional, usable and acceptable software application that meets the specified requirements and sometimes exceeds the expectation.
7. Automation is not the solution to everything.
While automation can be the best thing you can employ in your project, sometimes it creates more work than mitigate your load. First you need to analyze WHY you need to automate, you don't just automate for the sake of reporting to the higher management that your team has automation coverage. Once you're settled with the why, decide on the HOW, which includes selecting the automation testing tool that will best fit in your process and application then establish best practices; and consider maintainability when designing the codes. Then evaluate WHAT to automate, 100% automation coverage can be your nightmare instead of a dream come true. Automate only those you think that needs to be automated, otherwise maintaining a large sloppy test suite will be your rebound.
8. Testing is a continuous improvement.
Testing does not end in when your Dev fixed the bug and you've verified it to close. It does not end either after certifying that the new build is a "Go" or "No Go." Testing encompasses improvement not only in testing per se but also in software development process as a whole.
9. Don't break the system to prove developers wrote crappy codes.
Or to show off you are a better tester. Break the system because you protect the end-users, its the main reason why we are testing anyways.
10. Requirements is not the only truth and nothing but the truth.
If you think that the feature does not make sense in terms of usability although it is developed as per requirements, this should not stop you in bringing this up to the product team or project manager in an objective way. You'll never know, your suggestion could be the breakthrough of your application.
Happy testing!
Comments