Project 1 - V&V SW Analysis - I

Black Box Testing

• Black Box Testing is a software testing method in which the functionalities of software applications are tested without having knowledge of internal code structure, implementation details, and internal paths.
• It mainly focuses on the input and output of software applications and it is entirely based on software requirements and specifications.
• It is also known as Behavioral Testing.

Types of Black Box Testing

• Functional testing – This black box testing type is related to the functional requirements of a system; it is done by software testers.
• Non-functional testing – This type of black box testing is not related to testing of specific functionality, but non-functional requirements such as performance, scalability, and usability.
• Regression testing – Regression testing is done after code fixes, upgrades, or any other system maintenance to check the new code has not affected the existing code.

Tools used for Black Box Testing

• For Functional/ Regression Tests you can use – QTP, Selenium
• For Non-Functional Tests, you can use – LoadRunner, Jmeter

Black Box Testing Techniques

• Equivalence Class Testing: It is used to minimize the number of possible test cases to an optimum level while maintains reasonable test coverage.
• Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This technique determines whether a certain range of values are acceptable by the system or not. It is very useful in reducing the number of test cases. It is most suitable for systems where input is within certain ranges.

Test Plan

• Test Plan is a detailed document that describes the test strategy, objectives, schedule, estimation, deliverables, and resources required to perform testing for a software product.
• The test plan serves as a blueprint to conduct software testing activities as a defined process, which is minutely monitored and controlled by the test manager.
• Importance of the test plan is to help people outside the test team such as developers, business managers, and customers understand the details of testing.

Components of Test Plan

• Test Objective

It consists of information about modules, features, test data, etc., which indicate the aim of the application means the application behavior, goal, etc.

• Scope of Testing

It contains information that needs to be tested with the respective application. The Scope can be further divided into two parts

• In scope - The components of the system to be tested (hardware, software, middleware, etc.) are defined as “in scope“

• Out scope - The components of the system that will not be tested are defined as being “out of scope.”

• Roles and Responsibilities

The Roles and Responsibilities of the test team should be listed.

• Schedule of Tests

The time frame within which the testing activities are to be completed. It covers when exactly each testing activity should start and end. And the exact date is also mentioned for every testing activity for the particular date.

• Assumptions

The assumptions that have been made to prepare this plan and also the dependencies associated with this test plan.

• Risks

Mention the possibility of risk occurrence on the basis of previously identified risk factors.

Risks are related to the availability of resources, the availability of test environments, and the technical knowledge of the team.

• Mitigation/Contingency plans

A mitigation plan attempts to decrease the chances of a risk occurring, or decrease the impact of the risk if it occurs. It is implemented in advance.

A contingency plan explains the steps to take after the identified risk occurs, in order to reduce its impact.

• Test Methodology

Testing methodologies are nothing but the approaches and strategies used for testing an exact product

Example – Waterfall model, Agile model, V-model, etc.,

• Test Approach

In the Test Approach Test plan demands mentioning an overall approach to be adopted in the process of testing.

This may consist of specifying the types of testing, and the various methods of testing like manual or automated, white box or black box.

• Entry Criteria

Specific conditions or on-going activities must be present before a process can begin.

• Exit Criteria

Specific conditions or on-going activities that should be fulfilled before completing the software testing life cycle.

• Test Environment

Testing environment is a setup of software and hardware for the testing teams to execute test cases.

These are the environments where we will test the application, and here we have two types of environments, which are of software and hardware configuration.

• Defect Tracking

Defect tracking is generally done with the help of tools because we cannot track the status of each bug manually. And we also comment on how we communicate the bugs which are identified during the testing process and send them back to the development team and how the development team will reply. Here we also mention the priority of the bugs such as high, medium, and low.

• Effort Estimation

It is a detailed estimation of the effort required by the test engineers in the team to carry out the testing activity.

• Test Automation

Test Automation is the best way to increase the effectiveness, test coverage, and execution speed in software testing.

• Test Deliverables

These are the documents that are expected from the testing team, which we handed over to the customer along with the product. It includes

• Test plan
• Test Cases
• Test Scripts
• RTM (Requirement Traceability Matrix)
• Defect Report
• Test Execution Report
• Graphs and metrics
• Release Notes

if (product owner long pressed the power button of the phone)

{

switch on with a company logo at center of the screen

}

else if (customer presses the power button)

{

phone gets switched ON and all icons of apps present in grid

}

else if (product owner turned ON the phone)

{

should see call the phone icon as first icon at bottom bar of screen

}

else if (product owner turned ON the phone)

{

should see dictionary icon as second icon at bottom bar of screen

}

else if (product owner clicks call the phone icon)

{

all contacts should be visible on chronological order

}

else if (product owner clicks dictionary icon)

{

search bar should appear at middle of screen to search meaning of the words

}

else if (product owner long pressed power ON button)

{

phone gets switched off saying Good Bye

}

else if (product owner mobile font)

{

Always be calibri and font size is 12

}

else if (customer touch responsive)

{

UI need to be touch responsive

}

else (customer mobile should not contain hard buttons)

{

mobile should be touch sensitive without any hard buttons

}