Skip to main content

Error, Fault, Failure, Incident, Test Cases

Error in software testing

During the process of software testing, errors are the most basic discrepancies found by the team of testers. These are the mistakes made by the software developer or programmer while preparing the code or design of the software. Errors are mainly a deviation from the results expected by the team, which further changes the functionality of the software.

Reasons for Error:
The reasons for these errors are misconceptions or misunderstandings on the part of the software developer. Other reasons for errors and mistakes in the software are:
  • Because of the wrong login, loop, and syntax.
  • Mistakes in the program.
  • Confusion in understanding the requirements of the software.
  • Miscalculation of some values.
  • Misinterpretations and issues in coding.
  • If a developer is unable to successfully compile or run a program.
  • Mistakes in design or requirement activities.
  • The discrepancy between actual and expected results.

Ways to Prevent Errors:
  • Improve software quality with code and system review.
  • Identify issues and prepare an appropriate mitigation plan.
  • Verify fixes and validate their quality and accuracy.
  • Indulge in thorough testing.
  • Adopt effective software development methodologies.

Fault in software testing

Introduced in the software because of an error, the fault is another discrepancy found by the team of testers during the process of software testing. Unlike error, the reason for a fault to occur while implementing the software is not because of a miscalculation of some value or discrepancy between actual and expected results but is merely a manifestation of an error in the software. Moreover, a fault in the software system inhibits it from performing its intended function and forces the system to act in an unanticipated manner.

Reasons for Faults:
Faults in a system can be raised because of various reasons, a few of which are mentioned here:
  • Discrepancy or issue in the code that causes the failure of the system/program.
  • Caused by an introduction of an incorrect step, process, or data definition.
  • An anomaly or irregularity in the software, which makes the software behave in an incorrect way and not as per the stated requirements.
Ways to Prevent Faults:
  • Implementing thorough code analysis.
  • Peer review.
  • Measure functional requirements.
  • Validate the accuracy of software design and programming.

Failure in software testing

When software is incapable of performing the required functions and is offering results that are not adequate and far from the expected results, then it is termed as a failure. These failures are incorrect external behavior that leads a software to deliver services that are not in compliance with the specifications.

Reasons for Failures:
Failures usually occur when a defect present in the system is executed by the team, which forces it to produce unpredicted and unanticipated results and function inappropriately. 
Other reasons that lead to the failure of the software are:


  1. Human Error: Errors made by the human while interacting with the software and by providing wrong or incomplete inputs.
  2. Environmental Conditions: Another common reason that forces the system to fail are environmental conditions. These impact the hardware and force it to fail. Additionally, it changes the various environment variables.
  3. Users: Failures may also occur in the system if the user tries to perform operations that can harm the functionality of the software. Moreover, they can also execute actions with the intention of breaking the system, which will further lead to failures.
  4. System Usage: Failures might also arise due to errors in the way system is being used.
Ways to Prevent Failures:
  • Identify and analyze errors and issues.
  • Adopt effective preventive techniques.
  • Ensure re-testing.
  • Revise and revisit specifications and requirements.

The incident in software testing

An incident in software testing can be defined as a variation or deviation observed in system behavior from what is expected. It can be a deviation from a functional requirement or from the environment setup. Very often an incident is referred to as a defect or a bug, but it is not always the case.


Test cases in software testing

The test case is defined as a group of conditions under which a tester determines whether a software application is working as per the customer's requirements or not. Test case designing includes preconditions, case names, input conditions, and expected results. A test case is a first-level action and derived from test scenarios.

Test case gives detailed information about testing strategy, testing process, preconditions, and expected output. These are executed during the testing process to check whether the software application is performing the task for that it was developed or not.

Why test cases?
We will write the test cases for the following reasons:
  • To require consistency in the test case execution.
  • To make sure a better test coverage.
  • It depends on the process rather than on a person.
  • To avoid training for every new test engineer on the product

The process to write test cases


  1. System study

In this, we will understand the application by looking at the requirements or the SRS, which is given by the customer.

Identify all scenarios:

  • When the product is launched, what are the possible ways the end-user may use the software to identify all the possible ways.

  • I have documented all possible scenarios in a document, which is called test design/high-level design.

  • The test design is a record having all the possible scenarios.

  1. Write test cases

Convert all the identified scenarios to test claims and group the scenarios related to their features, prioritize the module, and write test cases by applying test case design techniques and use the standard test case template, which means that the one which is decided for the project.

  1. Review the test cases

Review the test case by giving it to the head of the team and, after that, fix the review feedback given by the reviewer.

  1. Test case approval

After fixing the test case based on the feedback, send it again for approval.

  1. Store in the test case repository

After the approval of the particular test case, store in the familiar place that is known as the test case repository.



Next: Testing Process and Limitations of Testing

Credit: javatpoint

Comments

Popular posts from this blog

Graph Theory | Cyclomatic complexity

What is Graph Matrix? A graph matrix is a square matrix whose size represents the number of nodes in the control flow graph.  Each row and column in the matrix identifies a node and the entries in the matrix represent the edges or links between these nodes. Conventionally, nodes are denoted by digits, and edges are denoted by letters. Example: Graph Examples Since the graph has 4 nodes , so the graph matrix would have a dimension of 4 X 4 . Matrix entries will be filled as follows : (1, 1) will be filled with ‘a’ as an edge exists from node 1 to node 1 (1, 2) will be filled with ‘b’ as an edge exists from node 1 to node 2. It is important to note that (2, 1) will not be filled as the edge is unidirectional and not bidirectional (1, 3) will be filled with ‘c’ as edge c exists from node 1 to node 3 (2, 4) will be filled with ‘d’ as edge exists from node 2 to node 4 (3, 4) will be filled with ‘e’ as an edge exists from node 3 to node 4 Connection Matrix A connection matrix is a ma...