Introduction To Software Testing

Software testing is a process of identifying the correctness of software by considering its all attributes (Reliability, Scalability, Portability, Re-usability, and Usability) and evaluating the execution of software components to find software bugs errors or defects

Software testing provides an independent view and objective of the software and gives surety of the fitness of the software. It involves testing all components under the required services to confirm whether they satisfy the specified requirements or not. The process is also providing the client with information about the quality of the software.

Testing is mandatory because it will be a dangerous situation if the software fails any of the time due to lack of testing. So, without testing software cannot be deployed to the end user.

Software Testing
Software Testing

Testing

Testing is a group of techniques to determine the correctness of the application under the predefined script but, testing cannot find all the defects of the application. The main intent of testing is to detect failures of the application so that failures can be discovered and corrected. It does not demonstrate that a product functions properly under all conditions but only that it is not working in some specific conditions.

Testing furnishes a comparison that compares the behaviour and state of software against mechanisms because the problem can be recognized by the mechanism. The mechanism may include past versions of the same specified product, comparable products, interfaces of expected purpose, relevant standards, or other criteria but not limited to these.

Strategic Approach to Software Testing

A strategic approach to software testing involves a comprehensive plan for testing software that is aligned with the goals of the organization and the needs of the end-users. Here are some key steps to develop a strategic approach to software testing:

  1. Understand the Requirements.
  2. Define the Test Plan.
  3. Test Design.
  4. Test Execution.
  5. Defect Tracking.
  6. Reporting and Metrics.
  7. Continuous Improvement.

Test Strategies for Conventional Software

Testing strategies for conventional software depend on the type of software being developed and the testing requirements of the design. Then are some general strategies that are used

  1. Unit Testing.
  2. Integration Testing.
  3. System Testing.
  4. Acceptance Testing.
  5. Regression Testing.
  6. Performance Testing.
  7. Security Testing.
  8. Usability Testing.
  9. Exploratory Testing.

Validation Testing

The process of evaluating software during development or at the end of the development process to ensure that it meets specified business requirements.

Validation testing verifies that a product truly meets a customer’s needs. It can also be defined as demonstrating that a product meets its intended use when deployed in an appropriate environment.

Workflow:

  • Unit Testing
  • Integration Testing
  • System Testing
  • User Acceptance Testing

System Testing

System testing is a testing level that tests a complete and fully integrated software product. The purpose of system testing is to evaluate system specifications end-to-end. Software is usually just one element of a larger computer system. Ultimately, software interacts with other hardware and software systems. System testing is defined as a series of various tests whose sole purpose is to test the entire computer system.

Types of System Testing

There are over 50 system test types. For a full list of software testing types, click here. Listed below are the types of system testing commonly used by large software development companies.

  1. Usability Testing
  2. Load Testing
  3. Regression Testing
  4. Recovery Testing
  5. Migration Testing
  6. Functional Testing
  7. Hardware/Software Testing

Basic Terminologies

  1. Test Case: A test case is a set of conditions or steps used to determine whether a particular feature or functionality of a software application is working as expected or not.
  2. Test Plan: A test plan is a document that outlines the approach, scope, objectives, and resources required for a specific testing project.
  3. Test Suite: A collection of test cases that are grouped together and executed as a single unit is called a test suite.
  4. Test Scenario: A test scenario is a hypothetical situation or use case that is designed to test a particular feature or functionality of a software application.
  5. Test Environment: The test environment refers to the hardware, software, and other resources that are required to carry out testing activities.
  6. Test Execution: The process of running test cases and recording the results is called test execution.
  7. Test Script: A test script is a set of instructions that automate the execution of test cases.
  8. Test Result: The output generated from executing a test case or a group of test cases is called a test result.
  9. Test Coverage: Test coverage refers to the percentage of a software application that has been tested through various test cases.
  10. Defect or Bug: A defect or bug is an error or flaw in a software application that causes it to behave unexpectedly or incorrectly.

V Shaped Software Lifecycle Model

The V-shaped software development model is a type of software testing lifecycle model in which the testing process is started after the completion of the development process. The model is named after its V-shaped structure, which illustrates the relationship between each phase of the development process and its corresponding testing phase.

In this model, the development process and testing process are carried out simultaneously but independently. The left side of the V represents the development phase, which starts with the requirement gathering and ends with the implementation of the code. The right side of the V represents the testing phase, which starts with the validation of requirements and ends with user acceptance testing.

Functional Testing

Functional testing is the process by which QA determines whether the software works according to predefined requirements. It uses a black box testing method in which the tester does not know the internal logic of the system. Functional testing is only concerned with verifying that the system works as intended.

Types of Functional Testing

  • Unit Testing
  • Smoke Testing
  • Sanity Testing
  • Regression Testing
  • Integration Testing:
  • Beta/ Usability Testing

Black Box Testing

Black box testing is a software testing technique that tests the functionality of a software application without knowledge of the code’s internal structure, implementation details, and internal paths. Black box testing focuses primarily on the inputs and outputs of software applications and is based entirely on software requirements and specifications. Also called behavioural testing.

Types of Black Box Testing

There are many types of Black Box Testing but the following are the prominent ones –

  • Functional testing
  • Non-functional testing
  • Regression testing

Boundary Value Analysis

Boundary value analysis is one of the popular case design techniques for black box testing. Input values ​​near the boundary are more likely to be erroneous, so they are used to test boundary values.

Whenever testing with boundary value analysis, the tester focuses on whether the software produces the correct output when boundary values ​​are entered.

Boundary values ​​are values ​​that contain the upper and lower bounds of a variable. Suppose that age is a function variable and has a minimum value of 18 and a maximum value of 30, both 18 and 30 are considered boundary values. A basic assumption of boundary value analysis is that test cases built using boundary values ​​are most likely to fail.

Equivalence Class Testing

Introduction

Among all other methods used in the software testing model, one of the most important is equivalence class testing. This is considered black box testing, which plays an important role in the software testing life cycle. The tester performing the test not only ensures the correctness of the results but also deals with a very limited amount of time when executing the input script. Test cases are designed to divide input data into equivalence classes and can be used for various testing purposes.

What is Equivalence Class Testing?

Equivalence class testing is commonly known as equivalence class division and equivalence division. Among all other software testing methods on the market, it is a well-known testing approach that allows test teams to develop and split inputs for analysis and testing, based on which software products are divided into multiple equivalence classes for testing.

Decision Table-Based Testing

Decision tables are used in many technical fields to represent complex logical relationships. This test is a very effective software testing and requirements management tool. The output can depend on many input conditions, and the decision table presents different combinations of input conditions in tabular form, and these conditions are in the form True (T) and False (F). It also provides a set of conditions and corresponding actions required during testing.

Parts of Decision Tables :

  1. Condition Stubs
  2. Action Stubs
  3. Condition Entries
  4. Action Entries

Structural Testing

In this section, we are going to understand structural testing, which is an important part of software testing.

You will also learn about the requirements, types of structural testing, compatible tools for structural testing, and their pros and cons.

Types of Structural Testing

Structural testing is divided into four different categories, which are as follows:

  • Mutation testing
  • Data flow testing
  • Control flow testing
  • Slice-based testing

White Box Testing

White box testing is a testing technique that examines the internals, design, and coding of software to verify I/O flows and improve design, usability, and security. White box testing is also called open box testing, open box testing, transparent box testing, code-based testing, or glass box testing because the code is visible to the tester.

This is one of two parts of the Box Testing approach to software testing. The counterpart, black box testing, is testing from the perspective of an external user or end user. On the other hand, white-box testing in software development is based on the inner workings of an application and revolves around internal testing.

Types of White Box Testing

  1. Unit Testing
  2. Testing for Memory Leaks

Program Graph

A Program Graph (PG) is a graphical representation of the control flow of a program, showing the relationships between program statements and the possible paths of execution. It is often used in software testing as a means of visualizing and analyzing the behaviour of a program, especially in the context of detecting and diagnosing errors or faults.

A Program Graph can be represented as a directed graph, where nodes represent program statements and edges represent control flow between the statements. Each edge is labelled with a condition that must be satisfied for the flow to follow that edge. The edges can also be labeled with probabilities or other quantitative measures if desired.

DD Path graph

A directed acyclic path graph, also known as a DAG path graph or simply a DD path graph, is a directed graph in which there’s a single path of bumps that connect the source knot to the Gomorrah knot.

The graph can be represented as a sequence of bumps, where each knot is connected to the coming knot in the sequence by a directed edge. The first knot in the sequence is the source knot, and the last knot is the Gomorrah knot. Each knot in the sequence has at most one incoming edge and at most one gregarious edge, except for the source knot which has only a gregarious edge, and the Gomorrah knot which has only an incoming edge.

Cyclomatic Complexity

The cyclomatic complexity of a section of code is a quantitative measure of the number of linearly independent paths within it. A program metric is used to indicate the complexity of a program. It is calculated using the control flow graph of the program. A node in the graph represents the smallest group of program instructions, and a directed edge within it connects the two nodes. That is if the second command can immediately follow the first command.

Steps that should be followed in calculating cyclomatic complexity and test case design are

  • Construction of graph with nodes and edges from code.
  • Identification of independent paths.
  • Cyclomatic Complexity Calculation
  • Design of Test Cases

Graph Matrix

A graph matrix is ​​a square matrix whose size represents the number of nodes in the control flow graph. If you don’t know what a control flow graph is, read this article. Each row and column of the matrix identifies a node, and an entry in the matrix represents an edge or link between those nodes. Nodes are usually represented by numbers and edges by letters.

Control Flow Testing

Control flow testing is a type of software testing that uses the control flow of a program as a model. Control flow testing is a structured testing strategy. This testing method refers to white box testing. For the control flow test type, the overall structure, design, code, and implementation of the software must be communicated to the test team.

Control Flow Testing Process

  • Control Flow Graph Creation
  • Coverage Target
  • Test Case Creation
  • Test Case Execution
  • Analysis

Statement Coverage

The statement coverage method is used to develop test cases for white-box testing in which every source code statement is executed at least once. This article explains operator coverage in detail.

This is one of the white box testing methods to ensure that every source code statement will be executed at least once. It covers every path, line and statement in your source code. Used to develop test cases that find the total number of statements executed from the total number of statements present in the code.

Branch Coverage

Branch coverage techniques are used to cover all branches of the control flow graph. All possible outcomes (true and false) of each decision point condition are covered at least once. Branch coverage is a white-box testing method to determine if each branch of each decision point should be executed.

However, while branch coverage and decision coverage are very similar, there are important differences. Decision scope covers all branches of each decision point, and branch testing covers all branches of each decision point in the code.

Condition Coverage

Condition coverage is a testing technique that is used to ensure that all possible outcomes of a condition in a software program are tested. It is a type of white-box testing technique, which means that it requires knowledge of the internal workings of the program’s code.

The condition coverage criteria require that each condition in a decision point should be tested both true and false. This means that every possible combination of conditions that can occur within the decision point must be tested. By doing so, the tester can be confident that all possible paths through the code have been executed, and that all logical outcomes have been evaluated.

Path Coverage

Path coverage testing is a structured testing technique for developing test cases with the intention of testing all possible paths of execution at least once.

  • Creating and running tests for all possible paths gives you 100% statement coverage and 100% branch coverage.
  • In this type of test, it is guaranteed that every statement in the program will be executed at least once. Flow graph, cyclo-complexity is used to get the default path