Project 1 - V&V SW Analysis - I

TEST PLAN

  Definition:

• It is detailed documentation that provides information about all the necessary and activities that will be a part of SW/HW 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.

TEST CASE:

Definition:

• It is a systematic procedure of executing a set of instructions to validate a particular SW 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 SW Testing.

Test Case ID:

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

Verification Method:

• This attribute specifies the verification method of the requirement.
• This can be system test, Integration test, system Integration test (mechanics/Hardware & Hardware/software), System-system integration, SW Test, SW integration test, SW Module test, etc.
• It can be mandatory/optional depending on the decision of the team.

Testing status:

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

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.

Maturity:

• The attribute indicates the status of the requirement.
• It indicates whether the requirement is ready for review, in creation phase, reviewed and accepted by all relevant disciplines, accepted by stakeholders and invalid.
• It can be mandatory/optional depending on the decision of the team.

Module Name:

• It is used to name the module to which the requirement be long to.
• This attribute can have the names of the modules used in the implementation of the project.
• It can be mandatory /optional depending on the decision of the team.

Pre-condition:

• This attribute defines the pre-condition for the SW test to execute
• This attribute is recommended to be mandatory.
• Test Procedure:
• This attribute indicates the procedure in which the test shall execute.
• (Example: Test inputs, actions and sequential steps to be performed while executing the tests.)
• This attribute is recommended to be mandatory.

Expected Result:

• This attribute is used to anticipate the expected result from the test we execute using the test procedure.
• This attribute is recommended to be mandatory.

Actual Result:

• This attribute is used to identify the actual result from the test we execute using the test procedure.
• This attribute is recommended to be mandatory.

Test Method:

• Test methods is used to create the test case and check whether the test methods are used adequately.
• It can be of the following values, ranging from equivalence classes, boundary values, state-based chart/state transition chart, elementary comparison test, control flow test, error guessing etc.
• This attribute is recommended to be mandatory.

Test Responsible:

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

Test Designer:

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

Manual Automation:

• This attribute 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.

SIL (safety integrity level);

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

Priority:

• This attribute indicates the priority of the test case execution within one release cycle.
• This attribute is recommended to be mandatory
• It can range from Low, Medium, High etc.

Release:

• This attribute is used to define from which release onwards the test case is applicable.
• It is recommended to be mandatory.

Valid Until Release:

• This attribute 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.

HW 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 attribute is recommended to be mandatory.

Reuse:

• Identify the Test cases which are reused (or partially reused) from other projects.
• These test cases can be used on a "high" level testing, e.g., when requirement not yet available.
• This attribute is recommended to be mandatory.

Test suite:

• This attribute defines which test suite the test case has to be executed belongs to.
• The definition of the test suite is done in the test strategy/test plan.
• This attribute is recommended to be mandatory and can have the values like Regression, Integration, etc.

TEST DESIGN TECHNIQUES:

 Ways in which we design the tests based on the understanding of requirements:

• Different Test Design Techniques
• Equivalence classes and Boundary checks
• Classification tree method (CTM)
• Elementary comparison Test (ECT)
• Control flow Test (CFT)
• State Transition Techniques (STT)
• Error Guessing (EG)

 Testing Types:

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.

Classification tree method (CTM):

It consists of the following steps:

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

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 pseudocode or code is tested to assess the proper handling of all decision outcomes.

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 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:

• Analysis the result and find out whether the program is error free or has some defects.

State Transition Techniques (STT):

• All test paths in State-transition-tree
• one test path is a sequence of test steps

 Every test step needs:

• Event (test stimulus)
• Guard (precondition for test stimulus)
• Action (system reaction)
• State (resulting state)

 Error Guessing (EG):

• Characteristics: Black-box, Non-formal test design technique
• procedure: Nominate experienced test engineers (domain and methodology)
• Specific documentation evaluation
• what Error should, I guess?
• Determine all the failure test cases for a given scenario
• failure test cases for a given scenario. experienced test engineers

Testing:

Black-Box Testing:

    A method of testing that tests the functionality of the system without looking into the internal implementation/ structures of the system.

(Example. Testing the lock and unlock features of your mobile.)

White-Box Testing:

• A method of testing that may/may not test the functionality of the system by looking deep into the internal implementation/structures (design, coding etc) of the system.

(Example: Testing any embedded prototype you designed by debugging into the software.)

• Unit Testing is an example of white-box testing without actually concerning about the functionality of code.

Regression Testing:

• A method of testing that tests all the functional and non-functional codes of an embedded software after we perform a change/modify any requirement.
• Write a Test plan to test features of a new mobile phone (Blackbox test) that needs to be implemented based on the following requirements. (The product is still under development stage and is yet to be UA (User Acceptance) tested. Every other thing to be included in the test plan can be hypothetical.

CONDITION:

If (owner long press the power button)

{

      Print f ("open the company logo at centre");

}

else if (customer press the power button)

{

   Print f (" open the apps in grid");

}

else if (owner power on the phone)

{

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

}

else if (owner power on the phone)

{

      Print f ("shows Dictionary icon on second position at bottom");

}

else if (owner click on call the phone icon)

{

      Print f ("contacts appears in chronological order");

}

else if (owner click on Dictionary icon)

{

     Print f (" search bar appears at centre");

}

else if (owner long press power on button)

{

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

}

else if (owners phone font)

{

      Print f ("always in calibri with size of 12");

}

else if (customer requirement touch responsive)

{

      Print f ("reflects on touch");

}

else (customer requirement no hard buttons)

{

      Print f ("touch screen sensitive");

}