I have a wall-paper on my desktop which says: – “Why Do You Do The Things You Do” which forced me to write something like this which i feel should be considered before testing any application: –

1. Learning: – Analyze your test results thoroughly. Do not confuse yourself with ‘pass’ or ‘fail’ but finding the root reason of ‘fail’ or ‘pass’ will give you an idea for the solution of the problem. Testers knowledge increases by sending solutions for the problem

2. 100% of anything is not possible so having 100% test coverage is not possible but we can try to touch 99% of perfection.

3. Break your complete application into modules, sub modules, sub-sub modules and have independent test cases for each. Remember the story you cannot break a bunch of sticks but diving the bunch to single sticks it breaks easily. Not a good one though 😉 but yes true to some extents. Have a summary matrix sheet linked to all the testcases showing the status of each Testcase to gain knowledge about each part of the application by just having a glance on the summary sheet.

4. Testcase Writing Strategy: –
a. Cover all the basic business rules the application is meant to work for them.
b. Add steps to cover Data transparency.
c. Add steps to cover extraordinary scenarios.
d. Finally negative testing scenarios. Most Probably the unseen features hidden with XSS and SQL Injection which makes me remember of the modified by me words said by one of the apple co-founder: – Users don’t know what features actually they have. 😛 😀

5. “This Works Fine” is a statement made when we are short of scenarios :). Even i say it sometimes but that should not be my attitude. The required attitude forces me to say the bug is still inside. Thinking of ways to break down the system. There is nothing 100% perfect in our lives so it implies with the software’s also. Have a mindset of the application not working fine and start testing.

6. Scenario based not true with every project but few things to consider to gain maximum coverage in testcase: – Don’t wait for the UI. Start writing the testcase from the time of requirement analysis and design process. If not then don’t look into the UI and write testcase understand the functionality write the TC and then fine tune it by looking at the UI.

7. We never know we all stay in an uncertain world: – Allow your developer to read your testcase once, might be there is a mathematical function inside the logic of the program and he can add more scenarios. Might be he got an idea from your testcase and he can improve the current logic. Motto of both are same: – “Having a bug free app” or “We want to stay in a certain world”

8. Smoke – Bad for health Good for Software: – Prepare a smoke testcase preserving all the major and basic functionality of the application. Regress it regularly to cover the basic functionality of the complete application. Can you think of a day when you login into gmail and the after login page crashes. No We wont like it. Might be we don’t test the login page everyday.

9. Any application we see and use in our daily life – Do we like it to be slow enough to use? Test the performance of each functionality everyday, we as few users don’t like waiting for something – how can we give assurance about the uncountable visitors outside our reach. Performance Tuning is a MUST.

10. Remember the first UI of Gmail which was good that time, would you like to switch back to that ? 😀 Someone shouted “No Way”. Requirements are there to be present but application is not only with requirements. Test Beyond Requirements is the only key to have a excellent Usable Application that everyone would like.

11. Maintain your last test results in the testcases you execute. It maximizes the coverage of your testing ability. You know what was the bug earlier and what has been fixed and may be what bug new would be introduced.

12. Everyday we encounter problems, think, plan, do new things. Sometimes we do not realize it but we do. My Personal Feeling – Document your encountered problems, thinking, plan, done things. There are holidays Read it once won’t take 5 minutes even- Might look funny but yes It is obviously going to help you think in a better way. I bet Next time you wont write funny things – You Improve.

13. Plan your approach, your work and your day. Know your priorities – Never let time ruin your testing efforts. Time is a clock that always rotates doesn’t waits for you, Sometimes i think i grew older much faster because of the clock. 😛 😀

14. Bug Writing: – Always write bugs that a normal user also can perform the steps and find the real problem.

Software Testing might be a creative and challenging task. But it depends on how you handle this challenge.

And YEAH  We are the game!

Author – Priyadarshan Mohanty