I am stopping this activity as i am preparing for PMP and interested in it firstly.

V model

V- model means Verification and Validation model. Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes.

Each phase must be completed before the next phase begins. Testing of the product is planned in parallel with a corresponding phase of development.

The various phases of the V-model are as follows:

Requirements like BRS and SRS begin the life cycle model just like the waterfall model. But, in this model before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.

The high-level design (HLD) phase focuses on system architecture and design. It provide overview of solution, platform, system, product and service/process. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

The low-level design (LLD) phase is where the actual software components are designed. It defines the actual logic for each and every component of the system. Class diagram with all the methods and relation between classes comes under LLD. Component tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Coding: This is at the bottom of the V-Shape model. Module design is converted into code by developers.

Advantages of V-model:

• Simple and easy to use.
• Testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model.
• Proactive defect tracking – that is defects are found at early stage.
• Avoids the downward flow of the defects.
• Works well for small projects where requirements are easily understood.

Disadvantages of V-model:

• Very rigid and least flexible.
• Software is developed during the implementation phase, so no early prototypes of the software are produced.
• If any changes happen in midway, then the test documents along with requirement documents has to be updated.

When to use the V-model:

• The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed.
• The V-Shaped model should be chosen when ample technical resources are available with needed technical expertise.

High confidence of customer is required for choosing the V-Shaped model approach. Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.

Decision Tables

The techniques of equivalence partitioning and boundary value analysis are often applied to specific situations or inputs.

However, if different combinations of inputs result in different actions being taken, this can be more difficult to show using equivalence partitioning and boundary value analysis, which tend to be more focused on the user interface. The other two specification-based software testing techniques, decision tables and state transition testing are more focused on business logic or business rules.

A decision table is a good way to deal with combinations of things (e.g. inputs). This technique is sometimes also referred to as a ’cause-effect’ table. The reason for this is that there is an associated logic diagramming technique called ’cause-effect graphing’ which was sometimes used to help derive the decision table

Decision tables can be used in test design whether or not they are used in specifications, as they help testers explore the effects of combinations of different inputs and other software states that must correctly implement business rules.

The first task is to identify a suitable function or subsystem which reacts according to a combination of inputs or events. The system should not contain too many inputs otherwise the number of combinations will become unmanageable.

 It is better to deal with large numbers of conditions by dividing them into subsets and dealing with the subsets one at a time. Once you have identified the aspects that need to be combined, then you put them into a table listing all the combinations of True and False for each of the aspects.

Don’t just assume that all combinations need to be tested. It is always better to prioritize and test the most important combinations. Having the full table helps us to decide which combinations we should test and which not to test this time. In the example above all the conditions are binary, i.e. they have only two possible values: True or False (or we can say Yes or No).

TABLE 4 . 5 Decision table with additional outcomes:
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Repayment amount has T T F F
been entered:
Term of loan has been T F T F
entered:

Actions/Outcomes
Process loan amount: Y Y
Process term: Y Y
Error message: Y


Ref: http://istqbexamcertification.com/what-is-decision-table-in-software-testing/

State Transition Technique

State transition testing is used where some aspect of the system can be described in what is called a ‘finite state machine’.

Any system where you get a different output for the same input, depending on what has happened before, is a finite state system.

A finite state system is often shown as a state diagram

One of the advantages of the state transition technique is that the model can be as detailed or as abstract as you need it to be. Where a part of the system is more important (that is, requires more testing) a greater depth of detail can be modeled. Where the system is less important (requires less testing), the model can use a single state to signify what would otherwise be a series of different states.

A state transition model has four basic parts: State, Transition, Events and Actions.

 

 

Hence we can see that in any given state, one event can cause only one action, but that the same event – from a different state – may cause a different action and a different end state.

 

Test conditions can be derived from the state graph in various ways. Each state can be noted as a test condition, as can each transition.

 

Ref: http://istqbexamcertification.com/what-is-state-transition-testing-in-software-testing/ 

Websites

1. http://istqbexamcertification.com/what-is-decision-table-in-software-testing/  --ISTQB certification
2.

Activities in Testing(UAT)

UAT Prep:

Requirements

1. Requirement Review with Business
3. Requirement Sign-off
5. Upload Requirements to QC

Test Strategy:

1. Create Test Strategy
2. TMO Test Strategy Review
3. Test Strategy Walkthrough and Updates
4. Test Strategy Sign-off

Test Conditions:

1. Create Test Cases and Map to Requirements (end of analyze)
3. Business Education - Mapping Doc Review & Finalization
5. "Finalize Test Cases, including Test Data Parameters"
7. Test Case Review/Classification
9. Upload Test Cases to QC

Test Data:

1. Test Case Inventory (Analysis of Data Attribute Sources)
3. Fabricate UAT Positive/Default Test Data
5. Fabricate UAT Negative Test Data
7. Create and Deliver UAT Positive/Default Test Data Package
9. Create and Deliver UAT Negative Test Data Package

UAT Testing

UAT Execution:

Positive/Default Test Package Validation:

1. Validate Positive/Default Test Package
3. Send Positive/Default Test Results and Defects to AET
5. Upload Positive/Default Test Results and Defects to QC
7. Remediate Defects
9. Send Updated Package with Defect Fixes
11. Retest Failed Test Cases

Negative Test Package Validation:

1. Validate Negative Test Package
3. Send Negative Test Results and Defects to AET
5. Upload Negative Test Results and Defects to QC
7. Remediate Defects
9. Send Updated Package with Defect Fixes
11. Retest Failed Test Cases
13. UAT Execution Completion

Promote Code:

1. Raise CMR(s) to Build Databases and Move Code from E1 to E2
3. Build E2 Databases and Move Code from E1 to E2
5. Test Code in E2
7. Raise CMR(s) to Build Databases and Move Code from E2 to E3
9. Build E3 Databases and Move Code from E2 to E3
11. Verify E3 Databases and Code

Test Report:

1. Create Test Report
3. TMO Test Report Input (graphs etc.) and Review
5. Create EPMO Milestone Closure Reports
7. Test Report Review and Sign-off