Project 1 - V&V SW Analysis - I

Test features required to the customer:

Test feature 1: When long pressed the power button of the phone shall switch on with a company logo at the centre 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).

Test plan:

if(owner long press the power button)

{

open the company logo at centre;

}

else if(customer press the power button)

{

open the apps in grid;

}

else if(owner power on the phone)

{

shows call the phone icon on first position at bottom;

}

else if(owner power on the phone)

{

shows Dictionary icon on second position at bottom;

}

else if( owner click on call the phone icon)

{

contacts appears in chronological order;

}

else if(owner click on Dictionary icon)

{

search bar appears at centre;

}

else if(owner long press power on button)

{

displays Good-Bye and gets switched off;

}

else if(owners phone font)

{

always in calibri with size of 12;

}

else if(customer requirement touch responsive)

{

reflects on touch;

}

else ( customer requirement no hard buttons)

{

touch screen sensitive;

}

1. Test Plan and Strategy

1.1 Unit Testing

1.1.1 Objective

The main objective of unit testing is to verify whether every unit operates as intended. A function, procedure, method, or even the entire module can be considered a separate unit. Unit testing can be conducted manually, but automated testing is a more common practice.

1.1.2 Entry Criteria

• the planning phase has been finished
• testable units are available
• all functional requirements have been defined
• the unit testing environment has been set up

1.1.3 Exit Criteria

• all planned test cases have been covered
• all the bugs found have been reviewed
• the performance of key modules has been tested

1.1.4 Logging Tests and Reporting

Developers fix the defects found in each unit. If these defects are related to other modules and units, they must be reported.

1.2 System Testing

1.2.1 Objective

System testing is generally conducted after Unit Testing. The objective of System testing is to evaluate compliance of an integrated application with its requirements.

1.2.2 Testing Procedure

• test cases preparation
• test executions
• bug reporting

1.2.3 Types of System Testing

1.2.3.1 Performance Testing

Performing testing is conducted to detect issues related to:

• memory consumption
• power utilization
• network connectivity
• operating in the background
• switching between applications
• memory leakage

1.2.3.2 Interrupt Testing

This testing type examines how an application reacts to interruption and resumes to its previous state. There are numerous reasons that can potentially interrupt the operation of an app, such as getting a phone call, messages, notifications, battery low, etc.

1.2.3.3 Usability Testing

Usability testing is performed to check whether the application is easy to use and understand for the end-user.

1.2.3.4 Installation and Launch testing

Installation testing aims to detect whether there are any issues during the installation, uninstallation, and updating process. Once the application has been installed, a QA engineer also checks the launching process.

1.2.3.5 Functional Testing

All the functions and features of the application are tested to verify whether they operate according to the specification.

1.2.3.5 Security testing

Security testing is conducted to find the application vulnerabilities and prevent data breaches.

1.2.3.6 Regression testing

Regression testing is a re-execution of tests that had been done before the code changes. Its purpose is to verify whether a new functionality has affected the existing one.

1.3 Pass/Fail Conditions

All the conditions when tests pass or fail are defined and described.

1.5 Test Report

Test Report helps to summarize testing activity in a formal way. It should contain:

• name and overview of an application
• testing hardware and software environment
• the number of test cases executed/passed/failed.

For each issue that has been encountered, the following information is provided:

• bug description
• bug status (open, fixed, etc.)
• bug location
• steps to reproduce an issue

2. Schedules for Testing

A test schedule, created by Project Managers, helps to monitor the testing process.

3. Risks and Assumptions

3.1 Risks

The following risks may occur during the mobile app testing process:

• availability of devices
• new features and modification which have not been planned in advance
• changes in requirements
• delays in schedule

3.2 Assumptions

• each release is accompanied by a note with information about implemented features and their impact on the system
• all blocker bugs receive the high priority status
• all the bugs found are fixed before the next software release
• all documents are up-to-date and delivered to the testing team in time
• all necessary equipment and tools are provided and ready for testing
• the test schedule is reviewed in case there are any obstacles for testing

4. Entry and Exit Criteria

4.1 Entry Criteria

• the development phase has been finished
• requirements have been defined and approved
• test design and tests plan have been created
• the test environment has been set up
• all necessary resources are available.

4.2 Exit Criteria

• tests cases are executed
• the rate of tests cases passed is satisfactory, e.g., 95%
• failed test cases are not related to crucial functionality
• tests results have been accepted
• critical defects have been fixed.

5. Test Metrics

Test metrics are quantitative measures that help to estimate the testing effort. The most common metrics are:

• requirement coverage
• test cases coverage
• number of tests executed
• number of defects found (taking into consideration their priorities and severities)
• tests design effort
• total test effort

6. Logging Tests and Reporting

Each detected issue should be properly reported using special tools and applications.

7. Roles and Responsibilities

Project roles and responsibilities should be clearly defined and divided among the project staff. Commonly, the roles are as follows:

7.1 Project Manager

The Project Manager is responsible for managing the whole testing process. They approve all test documentation, considers budget and time terms, and provide necessary resources.

7.2 Test Lead

The Test Lead is responsible for collecting requirements, planning process, test activity monitoring, and project reporting.

7.3 Test Engineer

The Test Engineer is responsible for test case preparation and execution, as well as issue reporting.

8. Deliverables

The list of testing deliverables usually contains:

• test plan
• test cases documents
• test strategy
• test results
• test summary report

Black Box testing:

• It is non-functional testing, also called as static testing method.
• It doesn't involve any type of code while performing test.
• It requires highly qualified professionals for testing.
• Testing is based on error guessing technique.

User Acceptance Testing:

• This test is completely based on user requirement i.e., whether the code meets the user requirements or not.
• No need of developer involvement while performing this test.
• This is the last stage of testing conducted after all the development are done.