These are activities you perform almost daily. You're tired of the monotonous work involved and yet its hard to realize that these are the activities that you must optimize in order to speed up your testing process. You would probably have these at the back of your mind.. Let me help you bring them to the fore!
We're all faced with this situation each time some piece of code needs to be tested. We look for the requirements, and frame our test scenarios and test cases. Have you ever thought what exactly are you doing by writing test cases? You're simply rewording the requirements!
Something simple for example:
Requirement = 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).
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
Now, each of these test cases will include Expected Results and Actual Results. Just look at the amount of text that's being created in order to test requirements as simple as the login page mentioned! You need a way to get test case writing optimized.
It's quite common now a days to see test phases begin even while the requirements aren't frozen. Although "No testing before finalizing the requirements" is a golden rule of testing, shorter timelines and rigid deadlines make such a scenario inevitable. Faced with such a situation, you would have to go back to your test cases, and scour to find the right test case(s) to update. Now this would be a very difficult task if you had a few thousand tests cases to look into. You need a way to get your test cases identified without effort.
Click the blue link.. A new page describing something should open up in a new tab... Click the button.. A modal popup should be displayed...
If this sounds like what you do, manually, day in a day out, you, my dear reader, are back in time. Testing UI is a prime candidate to reduce the overall time consumed by the test phase time. Simply move to an automation first model and you will see the gains almost instantly.
When it comes to creating data, the automation first principle states that truck loads of data sets must be created with the help of a tool before test execution begins. This will save you the time and effort of having to manually create data sets when you need it the most - during execution. Also bear in mind, that data creation is not a mindless activity. Designing data to finely test every line of code - providing 100% decision coverage - of the software component under test requires you to follow a simple set data creation of guidelines.
Let me know what you think of these and feel free to share your thoughts via comments.. I'll be glad to hear your views and will reply to comments / questions that you may need answering.
P.S. Please bear with me for not linking you to the principles I've outlined. I will do so in a couple of days.
Also, 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..
Adios,
Savio Saldanha
1. You derive your test cases from a requirement document:
We're all faced with this situation each time some piece of code needs to be tested. We look for the requirements, and frame our test scenarios and test cases. Have you ever thought what exactly are you doing by writing test cases? You're simply rewording the requirements!
Something simple for example:
Requirement = 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).
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
Now, each of these test cases will include Expected Results and Actual Results. Just look at the amount of text that's being created in order to test requirements as simple as the login page mentioned! You need a way to get test case writing optimized.
2. You struggle to rework your test cases whenever the requirements are updated
It's quite common now a days to see test phases begin even while the requirements aren't frozen. Although "No testing before finalizing the requirements" is a golden rule of testing, shorter timelines and rigid deadlines make such a scenario inevitable. Faced with such a situation, you would have to go back to your test cases, and scour to find the right test case(s) to update. Now this would be a very difficult task if you had a few thousand tests cases to look into. You need a way to get your test cases identified without effort.
3. You test user interface (UI) elements and create test data manually
Click the blue link.. A new page describing something should open up in a new tab... Click the button.. A modal popup should be displayed...
If this sounds like what you do, manually, day in a day out, you, my dear reader, are back in time. Testing UI is a prime candidate to reduce the overall time consumed by the test phase time. Simply move to an automation first model and you will see the gains almost instantly.
When it comes to creating data, the automation first principle states that truck loads of data sets must be created with the help of a tool before test execution begins. This will save you the time and effort of having to manually create data sets when you need it the most - during execution. Also bear in mind, that data creation is not a mindless activity. Designing data to finely test every line of code - providing 100% decision coverage - of the software component under test requires you to follow a simple set data creation of guidelines.
Let me know what you think of these and feel free to share your thoughts via comments.. I'll be glad to hear your views and will reply to comments / questions that you may need answering.
P.S. Please bear with me for not linking you to the principles I've outlined. I will do so in a couple of days.
Also, 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..
Adios,
Savio Saldanha
Comments
Post a Comment
Tell me what you think