Showing posts with label Automated Testing. Show all posts
Showing posts with label Automated Testing. Show all posts

Tuesday, January 17, 2012

Good Attributes to be kept in mind for designing 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.

Some fundamental attributes of good automated test cases which can be followed,
  • Simple
  • Modular
  • Robust
  • Reusability
  • Maintainable
  • Documented
  • Independant
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, May be depending on the process steps may increase. However 10 to 15 steps note a good clarity test case. 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.

2) 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. However we can’t expect all test cases to have set up and cleanup process, it may vary accordingly.. The test steps are building blocks from reusable libraries that are put together to form multi-step test cases.

3) Robustness and Reliability: 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(Data Tables). 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. Author name, date of creation, and the last time it was modified must be documented. There should be traceability matrix 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.

Know More About: Automated Test Cases

Monday, January 16, 2012

Manual Testing (Vs) Automation Testing


As the world is moving toward a new era in Technology and business with respect to Testing, we will just have a walkthrough on Manual Testing and Automation testing.

1. Manual Testing is Boring
• No one wants to keep filling the same forms
• There is nothing new to learn when one tests manually
• People tend to neglect running manual tests
• No one maintains a list of the tests required to be run if they are manual tests

Automated tests on the other hand are Code
• They are fun and challenging to write
• One has to carefully think of design for reusability and coverage
• They require analytical and reasoning skills
• They represent contribution that is usable in the future

2. Manual Testing is not reusable
• The effort required is the same each time
• One cannot reuse a Manual Test

Automated Test are completely reusable
• Once written the Automated Tests form a part of the codebase
• They can be reused without any additional effort for the lifetime of the Project

3. Manual Testing has a high risk of missing out on something
• Each time a developer runs manual tests it is likely he will miss out on an important test case
• New developers may have no clue about the battery of tests to be run
Automated Tests have zero risk of missing out a pre-decided test
• Once a Test becomes a part of Continuous Integration – it will run without someone having to remember to run it

4. Manual Tests do not provide a safety-net
• Manual tests are run post-facto and hence only drive bug-patching
Automated Tests provide a safety-net for refactoring / additions
• Even New developers who have never touched the code can be confident about making changes

5. Manual Tests have no training value
• Manual Test are a mechanical process and does not have defined training values
Automated Tests act as documentation
• Reading a set of Unit Tests clarifies the purpose of a codebase
• They provide a clear contract and define the requirement
• They provide visibility into different use cases and expected results
• A new developer can understand a piece of code much more by looking at Unit Tests than by looking at the code
• Unit Tests define the expected behavior of the code

Read More: About Manual & Automation Testing