Blog

Terminology – Error, Fault, Failure, Incident, Test, Test Case

Greetings reader!

In today’s blog,  I will discuss the differences between very important terminology in software testing: Error, Fault, Failure, Incident, Test, and Test Case. This blog will define each term and explain how they all correlate. Without any further introduction, let’s begin.

The differences between error, fault, failure, and incident are as follows:

An error is a human action that produces an incorrect result.  A fault is a flaw in a component or system that can cause the component or system to fail to perform its required function. A failure is a deviation of the software from its expected delivery or service. An Incident is an unplanned interruption. When the status of any activity turns from working to failed and causes the system to fail it is an incident. A problem can cause more than one incident which are to be resolved, preferably as soon as possible.

An error is something that a human does, we all make mistakes and when we do while developing software, it is known as an error. The result of an error being made is a fault.

When a system or piece of software does not perform the correct action, this is known as a failure. Failures are caused by faults in the software. Note that software system can contain faults but still never fail (this can occur if the faults are in those parts of the system that are never used). In other words, failure is the exposure of one or more faults.

A test is a process that evaluate the functions of a software application with an intent to find whether the developed software met the specified requirements or not and to identify the defects to ensure that the product is defect free in order to produce the quality product.

A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. The process of developing test cases can also help find problems in the requirements or design of an application.

All in all, these terms are pretty elementary, however they are all important in Software testing. These terms all coincide with each other and I hop this blog was able to explain them in short detail.

 

Using JUnit

Greetings reader!

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: JUnit Testing. I will be expressing my reaction to the content by sharing what I find useful and interesting. Without any further introduction, let’s begin.

The JUnit framework is a framework that uses annotations to show methods that specify a test. When defining a JUnit test, the test itself is a method in a class that is only used for testing. This is called a test class. To define that a method is indeed a test method, define it with the @Test annotation. This method implements the code under test.

Also when defining a test, testers can use an assert method, made by JUnit to check an expected result against the actual result. These method calls are called assert statements. Testers should provide messages in assert statements because it makes it easier for the user to identify and fix any problems. This works if someone looks at the problem, who did not write the code under test or the test code.

When naming a test, there are many naming conventions. A solution for classes is to use the word “Test” at the end of test classes names. This gives the reader an easier understanding that this is actually a test class. A test name should explain what the test does. If that is done correctly, reading the actual implementation can be avoided. If you are using the Maven build system, you should use the word “Test” for test classes. The Maven build system automatically includes such classes in its test.

Testers can also run their JUnit tests outside the IDE with standard Java code. Systems like Maven or Gradle can be used to execute tests automatically. The org.junit.runner.JUnitCore class provides the runClasses() method. This method allows you to run one or several tests classes. As a return parameter you receive an object of the type org.junit.runner.Result. This object can be used to retrieve information about the tests.

J unit testing is a huge part of unit testing and so much more can be said about it. This is just an intro or short summary of the topic.

Boundary Value Testing, Equivalence Class Testing, Decision Table-Based Testing

Greetings reader!

This blog will give a short summary over topics that are essential in the Computer Science field: Boundary Value Testing, Equivalence Class Testing, and Decision Table- based testing.  I will be expressing my reaction to the content by sharing what I find useful and interesting. Without any further introduction, let’s begin.

Equivalent Class Testing is a black box method that can be used with all levels of testing (unit, integration, system). In this technique, the tester divides the set of test conditions into a partition. Equivalence class testing is used to reduce large numbers of test cases into clusters that are much more easy to manage. It also makes clear instructions on determining test cases without adjusting on the efficiency of testing.

Boundary value testing is the testing between extreme ends of the input values. The idea of boundary value testing is to select input values at their minimum, just above the minimum,  the nominal value, just below the maximum, and the maximum. In boundary value testing, equivalence class testing plays a huge role because boundary testing comes after the equivalence class testing. Boundary testing is used when it is  almost impossible to test large pool of test cases individually.

Decision table testing is a technique that is used to test system behavior for many different input combinations. This is a strategic approach where the different input combinations and their outputs are captured in a table format. Decision table testing is also called cause and effect testing. This testing method is important when it is necessary to test different combinations. Some advantages of decision table testing is when the system behavior is different for different inputs and not the same for a range of inputs, both equivalent testing, and boundary value testing wouldn’t help, but the decision table can be used.

Decision tables are so simple that they can be easily interpreted and used for development and also business. This table will help make effective combinations and will ensure better coverage for testing. In a case when a tester is going for 100% coverage, when the input combinations are low, this technique can typically ensure the coverage.

 

Specification-Based vs Code-Based Testing

Greetings reader!

In today’s blog, I will be discussing the differences between specification-based testing and code-based testing . I will also explain the benefits of each test, as well as pointing out their distinct features. Without further explanation, let’s begin!

Code based testing is a technique used to see if each line of code has been executed correctly. It corresponds to the testing that is carried out on code development, code inspection, and unit testing in the software development process. The idea is to find out whether any bugs exist in the program by choosing a set of test cases that can create the wanted results. Code based testing involves dynamic testing, static testing, and calculating Cyclomatic complexity.

In static testing, code is not executed; instead it checks the code, requirement documents, and design documents to detect errors.  The goal of this technique is to improve the quality of software by finding errors in early stages of development. Dynamic testing is when you are providing an input, receiving an output, and comparing the output to the expected behavior. Cyclomatic complexity is a mathematical based technique that helps reveal the facts that may be hard to find. It is the calculation of the number of nodes reached and the jump to the next node. It is done with the help of a control flow graph.

Specification-based testing technique is also known as black-box testing because they view the software as a black-box with inputs and outputs. Black box testing is a testing method in which there is no access to the source code or the internal structure of software. The main goal is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors. The testers have no knowledge of how the system or component is structured inside the box. Specification-based techniques are applicable at all levels of testing where specification exists.

Types of Specification Based Testing Techniques

  1. Equivalence Partitioning
  2. Boundary Value Analysis
  3. Decision Tables
  4. State Transitioning

Levels of Testing – Unit, Integration, System

Hello reader!

Today’s blog,  will discuss the differences between Unit, Intergration, and System testing. I will briefly explain the benefits for each test, as well as pointing out their distinct features. I will also be sharing my analysis of Software Testing Fundamental’s-“Software Testing Levels” article from which I readLet’s begin!

Software testing levels are various phases of the development sequence in which the testing is conducted. The main goal of system testing is to assess the system’s agreement with the specified needs. There are different testing levels that help check behavior and performance. These testing levels are designed to see missing areas and accordance between the development lifecycle states. There are three levels of software testing that I am going to talk about: Unit, Integration, System, and Sytem Testing.

Unit testing is a level of the testing process that tests individual units of a software. The goal is to show that each unit of the software works as designed. Intergration testing is a testing process that combines and tests individual units as a group. The goal of this level is to show faults in the interaction with integrated units. System testing is a testing process in which a program is tested for acceptability. The goal is to evaluate the program’s agreement with the business requirements and to see whether it is acceptable for delivery.

These three testing types cannot just be applied randomly during the forming process. There is a sequence that should be considered to in order to lessen the risk of failures. By increasingly testing the more simple things in the system and moving on to the more complex things, the testers should know that they are carefully examining the software in the most efficient ways possible.

Testing early and often is definitely worth the effort. Having a efficient approach to testing allows the tester to find any faults in the system sooner, which leads to less time and less money wasted later on.

Software Testing Fundamental’s-“Software Testing Levels” was written very well and it was very easy to understand. It taught me a great amount of these three types of testing. I hope I was able to extend what I learned in a informative way.