Typical Attributes of Good Automated Test Cases
Programming remains the biggest & most critical component of test case automation. Hence designing & coding of test cases is extremely important, for their execution and maintenance to be effective.
Seven fundamental attributes of good automated test cases, as per the following picture are being described below:
1) Simplicity: The test case should have a single objective. Multi-objective test cases are difficult to understand and design. There should not be more than 10-15 test steps per test case, excluding the setup and cleanup steps. Multipurpose test cases are likely to break or give misleading results. If the execution of a complex test leads to a system failure, it is difficult to isolate the cause of the failure.
Modularity: Each test case should have a setup and cleanup phase before and after the execution test steps, respectively. The setup phase ensures that the initial conditions are met before the start of the test steps. Similarly, the cleanup phase puts the system back in the initial state, that is, the state prior to setup. Each test step should be small and precise. One input stimulus should be provided to the system at a time and the response verified (if applicable) with an interim verdict. The test steps are building blocks from reusable libraries that are put together to form multi-step test cases.
3) Robustness and Reliablity: A test case verdict (pass or fail) should be assigned in such a way that it should be unambiguous and understandable. Robust test cases can ignore trivial failures such as one pixel mismatch in a graphical display. Care should be taken so that false test results are minimized. The test cases must have built-in mechanisms to detect and recover from errors. For example, a test case need not wait indefinitely if the software under test has crashed. Rather, it can wait for a while and terminate an indefinite wait by using a timer mechanism.
4) Reusability: The test steps are built to be configurable, that is, variables should not be hard coded. They can take values from a single configurable file. Attention should be given while coding test steps to ensure that a single global variable is used, instead of multiple, decentralized, hard-coded variables. Test steps are made as independent of test environments as possible. The automated test cases are categorized into different groups so that subsets of test steps and test cases can be extracted to be reused for other platforms and/or configurations. Finally, in GUI automation hard-coded screen locations must be avoided.
5) Maintainability: Any changes to the software under test will have an impact on the automated test cases and may require necessary changes to be done to the affected test cases. Therefore, it is required to conduct an assessment of the test cases that need to be modified before an approval of the project to change the system. The test suite should be organized and categorized in such a way that the affected test cases are easily identified. If a particular test case is data driven, it is recommended that the input test data be stored separately from the test case and accessed by the test procedure as needed. The test cases must comply with coding standard formats. Finally, all the test cases should be controlled with a version control system.
6) Documented: The test cases and the test steps must be well documented. Each test case gets a unique identifier, and the test purpose is clear and understandable. Creator name, date of creation, and the last time it was modified must be documented. There should be traceability to the features and requirements being checked by the test case. The situation under which the test case cannot be used is clearly described. The environment requirements are clearly stated with the source of input test data (if applicable). Finally, the result, that is, pass or fail, evaluation criteria are clearly described.
7) Independent and Self-sufficient: Each test case is designed as a cohesive entity, and test cases should be largely independent of each other. Each test case consists of test steps, which are naturally linked together. The predecessor and successor of a test step within a test case should be clearly understood.
Following three important rules are to be kept in mind while automating the test cases:
Rule-1: Independent of data value: The possible corruption of data associated with one test case should have no impact on other test cases.
Rule-2: Independent of failure: The failure of one test case should not cause a ripple of failures among a large number of subsequent test cases.
Rule-3: Independent of final state: The state in which the environment is left by a test case should have no impact on test cases to be executed later.
We must take into consideration the characteristics during the development of test scripts. In addition, we must obey the syntax of the test case defined in the next section while implementing a test case.
Many More Articles on Test Automation
Excellent article Yogindernath.. For me the most important factor is Maintainability. I have been involved in numerous regression runs and I have seen that it can become a nightmare if its not easily maintainable.
Kudos to you.
Thanks for the feedback Jeewan. I am glad you find this article useful.
Characteristics of a good automated test case are:
1) A test that takes too long to execute from manual testing perspective.
2) A test that can be run without any complications in recognizing the system objects, giving the input and analyzing the result.
In addition to these the characteristics of a good automated Testcase include but are not limited to the following:
1. It should be easy to maintain.
2. It should be properly structured.
3. It should run with no human intervention.
I Would like to know how we can designing various automation frameworks through QTP.
It would be good if I design the framework at free will without worrying about my tools and then bring in QTP in picture. This helps in keeping my framework and model robust.
I will request you how about a quick tutorial on Global Dictionary as it is a very powerful feature in QTP.
Expect on article on Dictionary very soon 🙂
I am looking more about BPT Frameworks, what is Business Process Testing and how to implement it with real time examples. Apart from that I want to learn all undocumented features of QTP at one place, Internal Architecture of QTP(Engines, Utilities, etc). Can anyone help me in this regard?
Can anyone please tell me if QTP 11 supports multiple tabs in Chrome using the patch QTPWEB_00088.EXE. Also Is there any ways we can disable the tabs in Google chrome browser so that we record steps on chrome browser using QTP 11?
I want to know more about QTP certification exam and also the below things:
1) What is the cost of the exam
2) what kind of questions will be asked like is it a multiple choice or theory or practical exam?
4)How much knowledge do you need in qtp to clear this exam.
As I am a beginner in QTP, I want to know what is the best way to write an automation script in QTP. I dont have any programming experience.
Sorry to disappoint you but QTP 11 has a very limited support for Google chrome with the same patch which you have mentioned. You cant disable multiple tabs.
Let me know if you have any other questions on QTP.
Thanks for the reply Yogindernath. Chrome is my favourite browser and I hope QTP 11 starts supporting Chrome fully.
Can anyone please answer the following QTP questions:
1. What are the differences in QTP versions.
2. What is the differnce between Test Director and HP Quality Center.
3. Briefly explain about QTP frameworks and which is the better QTP framework.
It is really urgent if someone explain me database migration testing.
QC is modified version of Test director with more better look and feel. Authentication is Necessary in Quality Center . Authentication is not Necessary in Test Director.
Can anyone provide me QTP interview questions? Its really urgent. I am looking to switch job.
I would like to appreciate you Yogindernath for this wonderful website.I would say keep on posting such material. I really like the way you write these articles on QTP. Honestly speaking I am a person who used to run away from technical stuff especially coding part but now after reading your articles, it has really inspired me to read about QTP. But your QTP blog is really a gem.
I am a manual tester working in Indore and my experience is 2 years. I have never used a test tool before. Now, I want to learn QTP for enhancing my skillset but I am clueless where to start from? Could you please guide me the steps learn QTP sufficiently? Please help me.
Hi Rajeev, Well learning QTP is not a 1 day journey. I would suggest you do the following in order to learn QTP. 1. Learn QTP’s language which is VBScript. Read all the details of VBScript. Try to write code yourself. This is the first step which I will call the foundation to learn QTP. 2. Install the QTP trial/demo version. You can install QTP 11 trial version for upto 31 days. [Please dont ask for QTP cracks or any illegal stuff here]. After installing QTP, go through the QTP tutorials from the Help menu in QTP. This will give… Read more »
5. There are so many forums on internet dedicated to QTP. You can post your queries there and you can also see what problems people have faced. Staying active on these forums is very important as you will get to know lot many issues and how to resolve them.
In case of any issues with QTP, you are most welcome to ask me.
I have downloaded QTP 11 from HP website. However I am facing some issues while installing QTP. During the installation it gets stuck in “Registering Modules” stage. How to proceed further.
Has anyone else faced this issue before? I have tried installing QTP 11 multiple times but every time I get this error.
How to upgrade QTP 10 to QTP 11? Is it possible without QTP 10 uninstall?
I want to know if QTP 11 supports Internet Explorer 9 on Windows 7. I have been trying to record on IE but no script is generated.
I want someone to answer my question on priority basis. Does HP QTP 11.0 supports silverlight 4.0 version? Thanks in advance.