Category Archives: CS-443

Boundary Value Testing & Equivalence Partitions

            I was looking for some materials to supplement the work we are doing in Software Quality Assurance and Testing (CS-443) and I came across a nice article from ReQtest entitled What is Boundary Value Analysis and Equivalence Partitioning? I found this to be a good supplement to our in-class activity on boundary value testing, summarizing some of the key ideas. It helped me nail down the concepts and is a nice, short resource for me.

            The article begins describing boundary value analysis. It highlights it is focused on, well, the boundary values, as, “for the most part, errors are observed in the extreme ends of the input values.” This directly relates to the topics covered in class, but is limited as it is mostly focused on single inputs, rather than testing for multiple inputs like we did in class. The article then provides a couple example for an input domain of 1 to 100. The exact boundary values would be 1 and 100, just below boundary values would be 0 and 99, and just above boundary values would be 2 and 101. This seems similar to robust boundary value testing. However, the article doesn’t consider multiple inputs, so there is no noting of nominal inputs or the single fault assumption, or worst-case boundary value testing. Nonetheless, I find it is a concise way of summarizing normal boundary value testing.

            The article then goes on to describe equivalence partitioning, which is the division of, “test input data into a range of values and selecting one input value from each range.” This goes more towards describing the domain of input values and somewhat alludes to physical and arbitrary boundaries. These are not described within the article, but are worthy of noting. The example given is again in the 1 to 100 acceptable range. The article states that one valid input class is anywhere within the 1 to 100 range, another is any value below 1, and the last is any value above 100.

            Together, these two topics do well to sum up the different ranges of inputs for boundary value testing, with equivalence partitioning touching on a little bit of worst-case boundary value testing. Overall, I thought this was a worthwhile article and was helpful. I can see myself returning to it when I actually am writing tests. Boundary value testing is quite useful in many cases, so it’s a topic I’m happy and interesting in learning more about and practicing.  

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

A quick but necessary recap on Boundary and Equivalence Class Testing

This week in class we covered what is Boundary Value Testing/Analysis and what is Equivalence Class Testing/Partitions and what are each of its subclasses.

After finishing the activities in class, I feel like the assignment really did a good job teaching us how to do each type of testing but it does not really explain why we should use each of these testing techniques.

What is Boundary Value Analysis and Equivalence Partitioning?

While I think knowing how to conduct each of these testing techniques is important, the essentialist within me cannot stop thinking about the logic or the origin of these techniques. In this blog post, Mr. Eriksson gives a recap of the topics we covered in class and gives a couple short and easy to understand examples to work through. Also in this post, he gives a short explanation of the main ideas of each technique. The reason why I chose this specific blog post wasn’t because I wanted to introduce new information about the topic but because I wanted the topic a quick once-over and really nail down the topic. This blog post gives a really nice summary about what we covered in class and serves really nicely in filling the blanks in our understanding of the topic.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Static vs. Dynamic Testing

In this post I will be talking about what static and dynamic testing is and how they differ.

Static testing’s objective is to find and prevent any errors in the early stages of a software’s development. This sort of testing is done without execution of the code. Some methods of static testing are manual and/or automated reviews of the code, requirement documents and document design. Some examples of the documents reviewed in this stage are test cases, source code, user documents and web page content. This is primarily verification.

Dynamic testing’s objective is to check the functional behavior of software, how it conforms to the business requirements and fix any errors that have been found. Its system, its usage and its performance are tested through execution of code. This sort of testing is done at any stage of the testing life cycle and can be white or black box testing. Most of the time it is validating the outcome is what is expected.

Some key differences between the two types of testing are that in static testing you do not execute the program, you analyze and review the documents and code. In dynamic, you execute the program and analyze the behavior. The goal of static testing is to prevent defects when developing the software while the goal of dynamic testing is to fix the defects. The costs of finding defects in static testing is less than of dynamic testing and the return on investment for static is greater than of dynamic. This is because of the development stage that each are executed in. Since static testing is done in the early stage before compilation it is preventing before it happens. Since dynamic is performed at the end of the development stage, you are only fixing technical debt.

Techniques for static testing include technical reviews, inspection, code reviews, and walkthroughs. Techniques for dynamic include unit testing, integration testing and system testing. Ultimately, static testing involves some sort of checklist and process and dynamic testing includes test cases and execution.

Source: https://www.guru99.com/static-dynamic-testing.html#:~:text=Static%20testing%20is%20about%20the,testing%20is%20performed%20after%20compilation.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

differences and benefits between JUnit 4 to JUnit 5:

https://www.baeldung.com/junit-5-migration

According to this blog what I study for the Junit 4 and Junit5:

JUnit 5 is a powerful and flexible update to the JUnit framework, providing various improvements and new capabilities to organize and describe test cases and to help understand test results. Upgrade to JUnit 5 is quick and easy: Just update your project dependencies and start using the new functionality.

JUnit 4 bundles everything into a single JAR file.

JUnit 5 consists of three sub-projects, namely JUnit Platform, JUnit Jupiter, and JUnit Vintage.

1. JUnit platform

It defines TestEngine’s API for developing new testing frameworks that run on the platform.

2.JUnit Jupiter

It has all the new JUnit annotations and TestEngine implementations to run tests written with those annotations.

3.JUnit Vintage

Support for running tests written by JUnit 3 and JUnit 4 on the JUnit 5 platform.

But here are four strong reasons to start writing new test cases with JUnit 5:

JUnit 5 takes advantage of features from Java 8 or later, such as lambda functions, to make tests more powerful and easier to maintain.

JUnit 5 adds some very useful new capabilities for describing, organizing, and executing tests. For example, tests get better display names and can be organized hierarchically.

JUnit 5 is organized into multiple libraries, so import only the functionality you need into your project. With build systems like Maven and Gradle, it’s easy to include the right libraries.

JUnit 5 can use multiple extensions at the same time, something that JUnit 4 cannot do (you can only use one runner at a time). This means that you can easily combine Spring extensions with other extensions, such as your own custom extensions.

The JUnit 5 tests look pretty much the same as the JUnit 4 tests, but there are a few differences you should be aware of.

The import. JUnit 5 uses the new org.junit.jupiter package. . For example, org. Junit. Junit Test into org. Junit. Jupiter. API. Test.

Annotation. The @Test annotation no longer has arguments; each argument is moved to a function.

Assertions. JUnit Assertions 5 now in org. JUnit. Jupiter. API. Assertions. Most common assertions, such as assertEquals() and assertNotNull(), look the same as before, but with a few differences.

The hypothesis. Assumption has been moved to org. Junit. Jupiter. API. Assumptions.

In summary, JUnit 5’s tests are more powerful and easier to maintain. In addition, JUnit 5 offers many useful new features. Only the features you use will be imported, you can use multiple extensions, and you can even create your own custom extensions. Together with the new features, these changes provide a powerful and flexible update to the JUnit framework.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Unit Testing vs. Integration Testing

The basic idea of unit testing is that you are testing individual units of source code that you have written to see if there are any bugs. Usually the code is deterministic so there are set outputs. The idea of integration testing is to test how a group of modules in your application are working together including how external dependencies are working with the code. This usually involves testing something that is non-deterministic in the application.

Integration testing usually comes after unit testing and is the more expensive to maintain. While the developers will run the unit tests, integration tests are usually required to be ran by a test team. This is partly due to the difficulty in finding errors in integration tests as well as the time it takes.

Integration testing is black box testing which means you are testing the inputs and outputs of the interface. An example of an integration test would be checking the interface to see if you are brought to your profile home page when you enter your username and password. Unit testing is white box testing so you are writing test cases for certain functions to see if they perform correctly. An example of a unit test would be writing a JUnit test case to test the deposit() method and assert that when you make a deposit of $50 to your bank account object (with initial balance of $0) that your balance is now at $50.

The main takeaway is that integration testing tests the interface and how multiple modules work together while unit testing is testing the source code of one function. Unit tests are done in early development while integration tests are done after you have some sort of product complete.

Sources:

https://www.guru99.com/integration-testing.html#3

https://www.guru99.com/unit-test-vs-integration-test.html#:~:text=Unit%20Testing%20test%20each%20part,see%20they%20are%20working%20fine.&text=Unit%20Testing%20is%20executed%20by,performed%20by%20the%20testing%20team.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Why QA is essential

The software development life cycle consists of many parts and one of the essential factors included is software quality assurance. QA for software has the role of establishing and maintaining a standard set of requirements for developing code and making sure the product is properly tested before being available to users. Quality assurance is essential because mistakes are inevitable to happen because the people who develop code are humans not machines. There is always something that can happen that escapes the developer’s eye and so there is another stage of the life cycle to catch this mistake. Now there are many reasons why quality assurance plays a huge role and can really help prevent major problems down the road.

By far the most important reason for quality assurance is money which makes sense because the goal of a business is to make money by selling their products. If code is developed but not tested through QA, then it will be released to the users and they will face problems. This will bring many additional problems to the company since their product failed because the right precautions were not taken. It is essential to test for as many unexpected problems that come to mind, and this is why a quality assurance process is needed to clear up these issues. Another big reason for quality assurance is safety for both the user and the company. A person who buys the software is investing in the product knowing that it is safe and their personal data won’t be a threat. If companies don’t ensure their products through quality assurance testing, then they are liable for damages to the user’s life and further safety issues. Adding on to this, once a company is known to not properly test their products and code, then they will be tarnished with a reputation that they are unreliable. First impressions are always important and this also applies to software because the technological world is changing exponentially which leads to a smaller margin of error for software companies to protect their reputation. The essential goal of a business is to create a product they can sell to a client and receive compensation for it. The user wants to spend money so he can be able to use that product for his own good. Therefore, the company has an obligation to make sure they do their best to meet client’s needs and make the best product based on their capabilities. Overall, software quality assurance is an essential process in the development life cycle and can break or make the software.

Additional resources to read up on:

View at Medium.com

https://www.msystechnologies.com/blog/everything-you-would-want-to-know-about-quality-assurance/

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Blog Post #1 JUnit 5 Testing

In class, we have been learning about testing with Junit 5 and doing assignments related to it. After watching the video for the advanced part of the assignment,  I decided that I wanted to research further into the topic for my first blog post. So, what is Junit? In a short answer, JUnit is a Java open sources unit testing framework that is used to write and run repeatable automated tests. JUnit 5 Is the updated version of the highly popular testing library that is Junit 4 which I’m sure you all have heard of it. Junit 5 was released in 2017 that adds good use for Java 8 features. In fact, JUnit 5 requires Java 8 JDK or higher to work.

While researching a few of the key differences between the two versions are Junit 5 is composed of 3 sub-projects JUnit Platform, JUnit Jupiter, and JUnit Vintage. The Assertions and Annotations have been changed, and most importantly Junit 5 adds the support of the lambda expression in which we went over in class. One of the blogs I read recommends doing this example,  which I found quite helpful and easy to understand. The code below is just a conversion between Fahrenheit to Celsius and Junit to test it. The author breaks each part down into subsections which made It easier to follow along. I was also, curious about how Junit 5 worked in the Gradle so I followed tutorials to see how the build systems provide supports to the new feature. I highly recommend watching the video that I have provided; it explains everything you need to know about Junit 5 and the architecture behind It.

 

Resources: 

https://www.youtube.com/watch?v=flpmSXVTqBI 

https://www.parasoft.com/junit-tutorial-setting-up-writing-and-running-java-unit-tests/

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Test Driven Development

Link: https://www.thoughtworks.com/insights/blog/test-driven-development-best-thing-has-happened-software-design

            The article linked above talks about test driven development, also referred to as TDD, and how it effects software development. I specifically chose this article since it centers around a topic that we’re supposed to cover in this class. The author explains three key reasons why this type of development is used. The first reason is that test driven development is an iterative cycle comprising of the three steps of failing tests, passing tests, and refactoring code. The “failing tests” phase establishes a baseline to work with, the “passing tests” phase develops that baseline into code that meets minimum requirements, and the “refactoring code” phase further develops that code. The second reason is that TDD forces a developer to question their code on multiple levels. For example, a developer would be pushed to question how a specific component works or what they expect from their code. The last reason is that test driven development allows for faster feedback on software design as poor design is often the reason why testing features fail. The article goes on further to explain how to apply TDD on code that is impossible to test.

            Reading this article, I found myself agreeing with a lot of what the author had to say. What stuck out to me in particular was how TDD forces a developer to question their code. It got me thinking about the habit I developed writing code where I began to write down and plan the general structure of a whatever project I worked on. The way that test driven development pushes someone to understand their code in what component does what reminds me of my habit but on a smaller scale since a developer would usually test a single feature at a time. And this type of development is really a new concept for me since I’ve used that iterative cycle that the author mentioned without even realizing it. The only major difference is that is that I typically didn’t use a test class which is what I’d assume is a given in the context of the article. I usually manually tested my projects which obviously hurt my productivity and deprived me of the benefit of faster feedback in TDD.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Getting my feet wet with the JUnit 4 Runner Architecture

Recently as part of a homework assignment, I learned that in JUnit 4, you were only allowed to use one test runner. This aspect of Junit 4 intrigued me so I decided to do a little more research into the architecture of the JUnit 4 Runner Class.

https://www.mscharhag.com/java/understanding-junits-runner-architecture

In this blog by Michael Scharhag, he explains generally what are Runners, how they work and the class hierarchy. Throughout the post, he walks us through the class hierarchy by using a series of tree diagrams and code snippets. He also explains some of the more easily missed details such as what happens when we don’t pass a Runner to the @Runwith annotation. He also talks a little bit about possible pitfalls such extending the wrong class and some neat tricks you can do with the JUnit 4 Runner such as creating custom runners. Overall, I feel like this post was more on the technical side and I used the following video to look at more of the application side.

In this video, it talks more specifically about what each of the classes in the hierarchy do and what annotations to include and when.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

JUnit 5

This week we had our first assignment. This assignment was about practicing writing JUnit 5 test cases. I am familiar with Junit 5 test cases from another computer class in last semester. Because I haven’t used Junit or coding in java for a while it took me a while to remember what I knew and how to code the test cases. JUnit 5 is most widely used testing framework for java applications. For very long time, JUnit has been doing its job perfectly. In between, JDK 8 brought very exciting features in java and most notably lambda expressions. JUnit 5 aims to adapt java 8 style of coding and several other features as well, that’s why java 8 is required to create and execute tests in JUnit 5.

In this homework, we had a BankAccount class and create at least one test class for the Bank Account System using Junit 5. In the base assignment we had to write the test for the methods that were in the BankAccount class and at the same time create a private method. In the intermediate we had to the write tests for which may include Custom Exceptions. In JUnit 5, to test methods which throws exceptions, we should use .assertThrows() method from org.junit.jupiter.api.Assertions class. The assertThrows() method asserts that execution of the supplied executable block or lambda expression which throws an exception of the expectedType.

In the advance I had to watch a podcast from Sam Brannen, Deep Dive into Junit5. The podcast was very interesting. From here I learned the fun fact that Junit5 is called Jupiter, the reason is Jupiter happens to be the fifth planet from the Sun. He explained some advantages and differences that Junit 5 has over 4 like; JUnit 5 has new features for describing, organizing, and executing tests, especially the display names and can be organized hierarchically, Junit 5 can use more than one extension at a time, you can easily combine the spring extensions with other extensions etc.

Overall, I really enjoyed working in this assignment even though I had to refresh my skills in java and writing test cases has always been a challenge for me but that doesn’t mean that I will give up.

https://howtodoinjava.com/junit5/junit-5-vs-junit-4/

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.