A friend and I were recently talking about the kind of common yet critical mistakes that are made quite unknowingly during the test phase of the SDLC.
Some of the points mentioned below are the kind of processes mandated by companies for ages! It is not uncommon to see that test managers, along with the test leadership within companies making such blunders. And if you see such practices being followed at your company, let them know that they should be ridding themselves of these common mistakes.
Not having an RTM puts you and your team at the risk of coming up with an incomplete coverage of the requirements and the possibility of leaking defects.
Here's how to design the RTM for your testing needs.
How do you prioritize your test cases? Please let me know through the comments section.
The login page will allow system access to the user by authenticating his/her username and password. The user will be allowed to enter the username and password through text boxes of not more than 20 characters (this does not mean the data type char).
And here's a test case to test the requirement (and this is not the way a test case should be written).
Test Case#1 = Verify the presence of the username and password text boxes having character length of not more that 20 characters upon whose authentication, the user should be logged into to system.
This is a classic example of a poorly written test case. A test case should always attempt to test a single, most basic function of the application under test (AUT). Doing so will help you clearly define individual elements / functions that need to be tested, and most importantly, will help you provide the adequate attention that every functionality should get. So in this case, the following is a better way of how test cases should look (and you could add to it):
Test Case#1 = Verify the presence of the username text box
Test Case#2 = Verify the properties of the username text box
Test Case#3 = Verify the presence of the password text box
Test Case#4 = Verify the properties of the password text box
Test Case#5 = Verify logging into the system with an authentic set of username and password
Here are a few concise guidelines to help you be better at writing test cases.
That's it for this post. Let me know what you think of testing and these points via the comments section.
Please note that my team is available to undertake software testing assignments. You may reach out to bureauofquality@gmail.com with your needs.
Till the next post..
Happy Testing!
Savio Saldanha
Some of the points mentioned below are the kind of processes mandated by companies for ages! It is not uncommon to see that test managers, along with the test leadership within companies making such blunders. And if you see such practices being followed at your company, let them know that they should be ridding themselves of these common mistakes.
1. Test cases are not traced back to the requirements
One of essential artifacts of the testing phase is the Requirement Trace-ability Matrix. What this matrix does is help you link your requirements to your test cases. As a result, you would be aware of the coverage your test cases provide to your requirements.Not having an RTM puts you and your team at the risk of coming up with an incomplete coverage of the requirements and the possibility of leaking defects.
Here's how to design the RTM for your testing needs.
2. Testers prioritize test cases independently
The requirements come in. The testing team begins their analysis charts out scenarios and cases. Scenarios and cases are prioritized by the testing team based on their experiences testing software. WAIT! This is certainly not a good way one could prioritize test cases. There's a business case to why priorities are given to test cases. The best way to determine the priority of the test cases is to let the business analyst (or any other member of the team who owns responsibility of what is being developed and tested) recommend it. This can easily be done during a test scenario walk-through. And be sure to get these recommendation of priorities in writing.How do you prioritize your test cases? Please let me know through the comments section.
3. A single test case verifies multiple features / functionalities
Consider this example of a requirement to be developed:The login page will allow system access to the user by authenticating his/her username and password. The user will be allowed to enter the username and password through text boxes of not more than 20 characters (this does not mean the data type char).
And here's a test case to test the requirement (and this is not the way a test case should be written).
Test Case#1 = Verify the presence of the username and password text boxes having character length of not more that 20 characters upon whose authentication, the user should be logged into to system.
This is a classic example of a poorly written test case. A test case should always attempt to test a single, most basic function of the application under test (AUT). Doing so will help you clearly define individual elements / functions that need to be tested, and most importantly, will help you provide the adequate attention that every functionality should get. So in this case, the following is a better way of how test cases should look (and you could add to it):
Test Case#1 = Verify the presence of the username text box
Test Case#2 = Verify the properties of the username text box
Test Case#3 = Verify the presence of the password text box
Test Case#4 = Verify the properties of the password text box
Test Case#5 = Verify logging into the system with an authentic set of username and password
Here are a few concise guidelines to help you be better at writing test cases.
That's it for this post. Let me know what you think of testing and these points via the comments section.
Please note that my team is available to undertake software testing assignments. You may reach out to bureauofquality@gmail.com with your needs.
Till the next post..
Happy Testing!
Savio Saldanha
Good !
ReplyDelete~Iyer