Project 1 - V&V SW Analysis - I

Answer:

1. TEST PLAN DEFINITION:

• The Test Plan means the detailed document which gives the test strategy, objectives, schedule, estimations deadlines and the resource required for completing that particular project. It is just like a blueprint for running the tests needed to ensure the software is working properly and controlled by test managers.
• It is detailed documentation that provides information about all the necessary and activities that will be a part of software and hardware testing.
• Test plans are necessary documentation used in both black box testing and white box testing.
• It has a various attributes detailing the test objective, Scope of testing, Roles and Responsibilities, schedule of tests, Assumptions Risks, Mitigation/Contingency Plans, In-scope features, Out-of-scope Features, Test Methodology, Test Approach, Entry criteria, Exit criteria, defect tracking, Test environments, Test Automation, Effort Estimation, and Test Deliverables.

2. TEST CASE ATTRIBUTES:

TEST CASE:

• It is a systematic procedure of executing a set of instructions to validate a particular software requirement either at the unit level, components level, module level, system-level, or customer acceptance level.
• A systematic procedure of designing a test case takes into account various dependencies, ranging from the test case ID, test steps, identifying the test setup, pre-condition, test procedure, expected results, actual results, pass/ fails etc.
• In a real-world scenario, we will deal with more attributes to execute a test case at various levels of software Testing.

TEST CASE ID:

• This is an ID that denotes the linkage between the test case and software requirements.
• An ID is generated automatically and is unique.

Verification method:

This verification method specifies the verification method according to requirement. In this, integration test, hardware test and module/unit test were done. It may be mandatory/optional.

Testing status:

This attributes is used to show the coverage status of the requirement. This attributes can have the following values- Not Applicable, Not covered, partially covered and fully covered. This attributes can be mandatory/ optional depending on the team to decide.

Maturity:

It provides the status of the requirement. To get whether is it read for review or in creation stage or is it accepted or is it received by stockholder or invalid requirement etc. It may be mandatory/optional.

Responsible Team:

It defines which development team is responsible for the SW test. It can be mandatory/optional depending on the decision of the team.

Module name:

It is used to name the module to which it belongs. for example: it under goes 10 unit test i.e, 10 modules in the list.(like wheel, seat, pedal etc in cycle).

Pre-condition:

It is define the pre-condition for the software test to execute. This attributes is recommended to be mandatory.

Test Procedure:

It indicates the procedure in which the test shall execute. Eg: Test inputs, actions and sequential steps to be performed while executing the tests.This attributes is recommended to be mandatory.
Expected Result:

It is used to anticipate the expected result from the test we execute using the test procedure and it is recommended to be mandatory.

Actual result:

Once we designed and run the program according to the procedure at last we get the actual result of the test. It is mandatory.

Test method:

It generates the test cases and check the method is adequate. it denotes the method whether we are using ECT, CTM,STT,EQ etc. It is mandatory.

Test Responsible:

It indicates the person(s) responsible for the test. It is recommended to be mandatory

Test Designer:

It indicates the name of the responsible test engineer who has designed the test for the test. It is recommended to be mandatory.

Manual Automation:

It determines whether the test case can be automated or not. It has the following values: Manual and to automate. This attribute is recommended to be mandatory.

Safety Integrity Level:

Based on the highest SIL level of the linked requirement to which the test case belongs, this attributes is considered for Risk-based Test strategy. It can list various SIL levels according to the industry. This attributes is recommended to be mandatory.

Priority:

It gives priority of the test within one release cycle.

Release:

After which release case, the test case is applicable.

Valid Until Release:

It determines the validity of test case we are writing. It basically determines until which release is the test case valid.

Customer-Demo:

The test cases which should be a part of the customer-demo are defined under this attribute. This attribute is recommended to be mandatory.

Hardware Variant:

This attribute is used to defined for which variants this test case is applicable ( based on requirement definition).This is a multi-select field. This attributes is recommended to be mandatory.

Reuse:

Check whether the test cases are reusable or not. It is recommended to be mandatory.

Test suite:

The definition of test suite is done in test strategy or test plan. it can have regression or integration tests.

3. TEST DESIGN TECHNIQUES:

The ways in which we design the tests based on the understanding of requirements.

Different Test Design Techniques

1. Equivalence classes and Boundary checks
2. Classification tree method(CTM)
3. Elementary comparison Test (ECT)
4. Control flow Test (CFT)
5. State Transition Techniques(STT)
6. Error Guessing(EG)I) Equivalence classes and Boundary checks:

The boundaries are the values on and around the beginning and end of a partition. If possible, test cases should be created to generate input or outputs that will fall on and to either side of each boundary.

This would result in three cases per boundary.

Boundary value analysis is testing at the boundaries between partitions. Equivalent Class Partitioning allows you to divide set of test condition into a partition which should be considered the same.

II) Classification tree method (CTM):

It consists of the following steps:

• Determining the start situation
• Constructing physical test cases
• Establishing the test script
• Portioning input domain according to aspects
• Specifying logical test cases
• Identify aspects of the test object
• Defining test actions
• Defining checkpoints

III) Elementary Comparison Test (ECT):

Elementary comparison testing (ECT) is a formal white-box, control-flow, test-design method. Its purpose is to implement the detailed testing of complex and important software. Software pseudo code or code is tested to assess the proper handling of all decision outcomes.

IV) Control flow Test (CFT):

Control flow testing is a type of software testing that uses program’s control flow as a model. Control flow testing is a structural testing strategy. This testing technique comes under white box testing. For the type of control flow testing, all the structure, design, code and implementation of the software should be known to the testing team.

This type of testing method is often used by developers to test their own code and own implementation as the design, code and the implementation is better known to the developers. This testing method is implemented with the intention to test the logic of the code so that the user requirements can be fulfilled. Its main application is to relate the small programs and segments of the larger programs.

Control Flow Testing Process:
Following are the steps involved into the process of control flow testing:

• Control Flow Graph Creation:
  From the given source code a control flow graph is created either manually or by using the software.
• Coverage Target:
  A coverage target is defined over the control flow graph that includes nodes, edges, paths, branches etc.
• Test Case Creation:
  Test cases are created using control flow graphs to cover the defined coverage target.
• Test Case Execution:
  After the creation of test cases over coverage target, further test cases are executed.
• Analysis:
  Analyze the result and find out whether the program is error free or has some defects.V) State Transition Techniques (STT):

State Transition Testing is basically a black box testing technique that is carried out to observe the behavior of the system or application for different input conditions passed in a sequence. In this type of testing, both positive and negative input values are provided and the behavior of the system is observed.

Steps Involved:

• Event(test stimulus)
• guard(precondition of the test stimulus)
• action (system reaction)
• state(resulting area)VI) Error Guessing:

It is used in black box testing. It is the non formal test design technique.

Procedure:

• Nominate experienced test engineer
• specific documentation evolution

4)TESTING:

Types of testing is classified into functional and non functional testing

Functional testing:

If we do testing for testing the functionality of the software for the specified requirements is called functional testing.

Non functional testing:

If we want the non functional aspects of the software with respect to the software component is called non functional testing.

Methods of testing:

1. Black box testing:

A method of testing which tests the functionality of the system without disturbing/looking the internal structure of the system.e.g:testing the lock and unlock status of phone

2. White box testing:

A method of testing which may or may not test the functionality of the system by deep into the internal structure of the system.e.g.Testing an embedded prototype.

3. Unit Test:

The unit test is an example of white board test where the functionality is not considered. In which each unit is tested.

4. Regression testing:

It is a method of testing that test both function and non functional system after the integration of the all the unit is made.

Test plan to test the new device(For example: phone)

if(owner long press the power button)

{

printf("open the company logo at centre");

}

else if(customer press the power button)

{

printf(" open the apps in grid");

}

else if(owner power on the phone)

{

printf("shows call the phone icon on first position at bottom");

}

else if(owner power on the phone)

{

printf("shows dictionary icon on second position at bottom");

}

else if( owner click on call the phone icon)

{

printf("contacts appears in chronological order");

}

else if(owner click on dictionary icon)

{

printf(" search bar appears at centre");

}

else if(owner long press power on button)

{

printf("displays Good-Bye and gets switched off");

}

else if(owners phone font)

{

printf("always in calibri with size of 12");

}

else if(customer requirement touch responsive)

{

printf("reflects on touch");

}

else (customer requirement no hard buttons)

{

printf("touch screen sensitive");

}