Project 1 - V&V SW Analysis - I
Test features required by the customer:
Test feature 1: When long pressed the power button of the phone shall switch on with a company logo
at the center of the screen.
Test feature 2: When the power button is pressed my phone is switched ON and all my icons of the
APPS shall be present in the grid.
Test feature 3: When the phone is powered ON ,I shall see the "call the phone" icon as the first icon
at the bottom bar of my screen.
Test feature 4: When the phone is powered ON, I shall see the "Dictionary" icon as the
second icon at the bottom bar of my screen.
Test feature 5: When I Clicked my "call the phone" icon ,all the contacts
shall be visible based on chronological order.
Test feature 6: When I Clicked my "Dictionary icon ,a search bar shall appear at the middle
of the screen to let me search the meanings of the words I desire.
Test feature 7: When I long pressed my "power on" button ,my phone shall be switched off
saying "Good-Bye” Message.
Test feature 8: My font in the mobile shall always be ''calibri (Body)" and shall be of size 12.
Test feature 9: I need my UI to be touch responsive.
Test feature 10: My mobile phone should have no hard buttons.
These all are the test features required by the costomer, So that we want to write a test plan
according to the test features because the product is still under development stage and is yet to be UA
(User Acceptance).
1)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.
2)TEST CASE ATTRIBUTES:
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.
TestCase 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 Methoed:
This attributes 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 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.
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:
This attributes 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 belong 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 attributes defines the pre-condition for the SW test to execute
This attributes is recommended to be mandatory.
Test Procedure:
This attributes 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:
This attributes is used to anticipate the expected result from the test we execute using the test
procedure.
This attributes is recommended to be mandatory.
Actual Result:
This attributes is used to identify the actual result from the test we execute using the test procedure.
This attributes 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 attributes is recommended to be mandatory.
Test Responsibe:
This attributes indicates the person(s) responsible for the test
It is recommended to be mandatory
Test Designer:
This attributes 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 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:
This attributes indicates the priority of the test case execution within one release cycle.
This attributes 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 attributes 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 are not yet available.
This attribute is recommended to be mandatory.
Test suite:
This attributes 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 attributes is recommended to be mandatory and can have the values like Regression,Integration,etc.
3)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 camparison 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 consist of the following steps:
1.Identify aspects of the test object
2.portioning input domain according to aspects
3.Specifying logical test cases
4.Constructing physical test cases
5.defining test actions
6.defining checkpoints
7.Determining the start situation
8.Establishing the test script
Elementary camparison 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 i
mplementation 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.
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:
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
4)Testing:
Black-Box Testing: A method of testing that tests the functionality of the system without looking i
nto the internal implementation/ structures of the system.
E.g. 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.
Eg: 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.
Test cases have a few integral parts that should always be present in fields. However, every test case
can be broken down into 8 basic steps.
Step 1: Test Case ID
Test cases should all bear unique IDs to represent them. In most cases, following a convention for this
naming ID helps with organization, clarity, and understanding.
Step 2: Test Description
This description should detail what unit, feature, or function is being tested or what is being verified.
Step 3: Assumptions and Pre-Conditions
This entails any conditions to be met before test case execution. One example would be requiring a
valid Outlook account for a login.
Step 4: Test Data
This relates to the variables and their values in the test case. In the example of an email login, it
would be the username and password for the account.
Step 5: Steps to be Executed
These should be easily repeatable steps as executed from the end user’s perspective. For instance, a
test case for logging into an email server might include these steps:
Open email server web page.
Enter username.
Enter password.
Click “Enter” or “Login” button.
Step 6: Expected Result
This indicates the result expected after the test case step execution. Upon entering the right login
information, the expected result would be a successful login.
Step 7: Actual Result and Post-Conditions
As compared to the expected result, we can determine the status of the test case. In the case of the
email login, the user would either be successfully logged in or not. The post-condition is what happens
as a result of the step execution such as being redirected to the email inbox.
Step 8: Pass/Fail
Determining the pass/fail status depends on how the expected result and the actual result compare to
each other.
Same result = Pass
Different results = Fail
Accelerate Software Testing by Sharing Test Assets Across Dev & Test Teams
Standard Unit Test Case Format
Each part of a will define several core aspects including:
Functions performed by the test
Data used in the test
Expected result from the test execution
Ensuring the test was executed in isolation from other parts of the codebase
TEST PLAN:
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");
}