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.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

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

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

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 read. Let’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.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

Today’s blog,  will discuss the differences between static and dynamic testing. I will be briefly explaining the benefits for each test, as well as pointing out their distinct features. I will also be sharing my analysis of Software Testing Help’s-” Static Testing and Dynamic Testing – Difference Between These Two Important Testing Techniques” article from which I read. Without any further babbling, let’s start.

Static testing is a testing technique that takes the form of design reviews, functional requirement reviews, code walkthroughs, business requirement reviews, and test documentation reviews. It is a ongoing activity that is not just done by testers.

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. Static testing is often called as non-execution technique or verification testing.

Static Testing Techniques:

• Informal Reviews
• Technical Reviews
• Walkthrough
• Inspection
• Static code Review

Dynamic testing is more hands-on and develops on the product itself and not on an a representation of the product. A much formal process of test cases, considerations, and execution explain the dynamic testing methods. Dynamic testing is when you are providing an input, receiving an output, and comparing the output to the expected behavior. It is a system made with the intent of finding errors.

In dynamic testing, code is executed. It checks for working behavior of the software system, memory, and the performance of the system. The goal of this technique is to ensure that the  product works in agreement with  the business requirements. Dynamic testing is used at all levels of testing and it can be either black or white box testing. Dynamic testing is also known as validation testing.

Dynamic Testing Techniques:

• Unit Testing
• Integration Testing
• System Testing

In conclusion, both static and dynamic testing reveal mistakes and coding errors using different methods. Verification (Static) and Validation (Dynamic) are two measures used to check that the software product meets the requirements specifications. Together they try to help improve software quality.

Software Testing Help’s-” Static Testing and Dynamic Testing – Difference Between These Two Important Testing Techniques” helped me a lot when reading about Static vs Dynamic testing.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

In today’s blog,  I will be discussing the differences between black box and white box testing. This blog will briefly explain the benefits for each test, as well as point out their distinct features. I will also be sharing my analysis of QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article from which I read. Without any further introduction, let’s begin.

Black box testing (BBT) is a testing method in which there is no access to the source code or the internal structure of software. The main goal of BBT 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.

Some advantages of black box testing are as follows. First, the tester can start designing test cases just after the specification is ready. Secondly, tests preparation time is short, and finally, there is no need for a tester to know the programming language of the application. The disadvantages of black-box testing: it is hard to design test cases without a specification, only some paths are covered , and it is impossible to to see what part of the code can cause a problem in future.

White-box testing (WBT) is a testing method where there is access to the source code and internal structure of the software (opposed to BBT). This testing type insinutates that a tester knows which code line is called for each function. It allows the tester to better choose an entry data set and to check errors and exceptions efficiently. White-box Testing focuses on bad code writing, conditional loops, the working flow of the code, and memory leaks.

Advantages of white-box testing are: there is no need to wait for the GUI application, it can conduct more detailed testing with more cases covered, and it can predict the potential problems in the software. The disadvantages of white-box testing is that a tester must know the programming language of the software, it can take much more time than other methods, and it can be expensive.

To conclude, there are advantages and disadvantages to both methods of testing, so there is none that is “better” than the other. They are both necessary and complementary.  The QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article that I read was extremely informative and very easy to comprehend. I greatly recommend their articles to expand your computer science knowledge.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: Mutation Testing. This blog will share my analysis of Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial.  I will be expressing my reaction to the content by sharing what I find useful and interesting and displaying if I have any concerns or disagreements. Without any further introduction, let’s begin.

First, let’s start with defining what mutation testing is. Mutation testing is a testing technique that uses the structure of the code to conduct the testing process. It is simply the rewriting of code in small ways in order to take out the excessiveness in the code. This wordiness may cause failures in the software if it is not altered. It is very sneaky because it can pass through the testing process’ unnoticed.

There are three types of mutation testing: value, decision, and statement mutations. Value mutations are efforts to change the values to display errors in the programs. The change of the value is usually to either a very large value or a very small value. It is found that the most common strategy to combat this is to change the constants. Decision mutations are when the code is changed to check for errors in the design. Ways to fix these errors are by changing the arithmetic operators to find the failures or by altering the relational and logical operators. Statement mutations are when changes are done to the statements by deleting or rewriting the line.

Mutation testing is based on two theorems. The first is the competent programmer theorem. This theorem explains that most software errors made by experienced programmers are due to small syntax errors. The second theory is called the coupling effect. The coupling effect says that simple errors can couple to form other faults.

All in all, mutation testing is a fairly simple technique that is used when testing code. Sometimes errors or faults can be hidden when making tests that will cause the source code to fail. Mutation testing is the process of altering these subtle errors in efforts to run the code.  This topic is extremely important to this field because it gives us a deeper understanding of our errors, which helps greatly when correcting “bad” code.

Source: Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – dekeh4 by dekeh4 and used with permission of the author. All other rights reserved by the author.