Mindmap for Test Strategy

A test strategy acts as an outline document that describes the testing approach in the software development cycle. It is created to inform different stakeholders including project managers, testers, and developers about some key issues in the testing process.

A test strategy can be defined at organisation level or project level. If described at organisation level, the strategy is implemented in the projects in the organisation. Test Strategy document is not updated often and defines standards for testing activities and processes.

Below image shows the basic information about test strategy captured in a mindmap.

Please follow below excellent reference materials to understand the concept of test strategy:

• http:/www.satisfice.com/blog/archives/63

• http://www.softwaretestingclub.com/forum/topics/writing-a-test-strategy

• http://www.slideshare.net/monthisrael8/what-is-difference-between-a-test-plan-a-test-strategy

• http://cgi.csc.liv.ac.uk/~coopes/comp208/Test_Strategy_Template_.pdf

• https://strongqa.com/qa-portal/testing-docs-templates/test-strategy

• http://www.ministryoftesting.com/wp-content/uploads/2012/08/Heuristic-Testing-Strategy-Model-Master.png

Mind Maps: Add-ins in Unified functional testing

In this article mindmap for Add-ins in UFT is explained:

1. Web Add-in Extensibility extends Web  Add-in to customize how UFT recognizes  and interacts with different types of controls

2. We can add or remove add-ins associated  with test in UFT

3. UFT license enables the use of all UFT add-ins.

4. Add-ins in UFT are broadly classified as web  based and windows based application support

5. UFT add-ins help you to create and run tests  and business components on applications  in a variety of development environments.

6. We can define run and record setting for each  of the environment once the add-in is loaded

Mindmap explaining automation framework

In this mind map, we will discuss on automation framework in QTP explaining:

What is automation framework, what are different types of framework, what are key features of an automation framework and expectations from an automation framework:

Content in the mindmap:
Automation  Framework in QTP
1. Set of Guidelines
1.1 Coding standards
1.2 Structure of test Data
1.3 Folder structure
1.3.1 Test Scripts
1.3.2 Test Libraries
1.3.3 Test Data
1.3.4 Test results
1.4 Object Repositories

2. Decisions
2.1 Decide automation framework to be used
2.2 Decide object Identification technique
2.3 Decide on set of automation guidelines

3. Framework Types
3.1 Linear
3.1.1 Script created by recording on AUT
3.1.2 Script creation is simple, fast and require minimal knowledge
3.1.3 No reusability of code and  high maintenance cost
3.2 Functional Decomposition
3.2.1 Divide test into logical groups or functions
3.2.2 Reusability of code is better
3.2.3 Scripts cannot be run with multiple set of data
3.3 Data Driven
3.3.1   Test data stored in external files drives automation by executing scripts with multiple sets of data
3.3.2 Covers multiple scenario with same script and change in data does not require change in scripts
3.3.3 Additional effort of creating test data and good knowledge of tool for resource
3.4 Keyword Driven
3.4.1 Object, action and arguments are maintained in an excel sheet in form of keywords
3.4.2 Highly reusable code can be used across applications. Once framework is created, easy to create test scripts.
3.4.3 Initial investment in creating framework is high and understanding framework for new user is comparably difficult
3.5 BPT Framework
3.5.1 BPT Components linked together to create test script using Quality center.
3.5.2 Easier for business users to create scripts
3.5.3 License cost of BPT and dependency on QC
3.6 Hybrid Framework
3.6.1 Uses best features of various frameworks
3.6.2 Highly robust and maintainable if properly implemented
3.6.3 Require skilled automation experts.

4. Great Expectations
4.1 Framework should Support Versioning Controlling for files
4.2 should be executed in different environments
4.3 minimal change in script for object changes
4.4 Robust and easy to interpret reporting system
4.5 Should have strong error handling and recovery scenarios