Category Archives: CS-443

Week 6: CS-443

Black box vs. White box vs. Gray box Testing

Black box testing

Black box testing focuses on the behavior of the software on a surface level. This means the tester cannot see any technical details such as code or the structure. Testers are not concerned about the inner workings of the software, rather only on the inputs and outputs. Therefore black box testing comes from the perspective of the user which allows testers to uncover any bugs and/or design flaws that would directly affect the user’s experience.

Some black box testing procedures include boundary value analysis, equivalence partitioning, and decision table testing. Boundary value analysis tests whether the software results in the correct output when the input contains the lower or upper limit of the input range. Equivalence partitioning groups all possible inputs into categories, which can reduce the number of total test cases. Finally, decision table testing involves grouping inputs into a table and testing how the software behaves when those inputs are combined.

White box testing

White box testing is the opposite of black box, meaning testers are given the internals of the system such as the code, the structure, and how its implemented. White box testing allows testers to fully understand how the software is executed. Having access to the internals of the software can help testers find issues related to security vulnerabilities, broken data paths, etc. while black box testing could not focus on those type of issues.

White box testing can be completed with a few techniques. These techniques include statement, branch, and path coverage. Statement coverage ensures that every statement in the code is run and tested at least once. Branch coverage executes all possible branches (i.e. conditional branches) in the code to be tested. Path coverage uses test cases to cover all possible execution paths throughout the software.

Gray box testing

Gray box testing combines black and white box testing into one. Therefore testing can be done from the perspective of the user, while still having access to the software’s internal code. Gray box testing is helpful when identifying problems that may otherwise be hard to find with other types of testing.

A couple techniques that are used in gray box testing are Matrix and Regression testing. Matrix testing looks at all variables in the code and assesses its risk level. Doing this can identify unused/under-optimized variables. Regression testing checks that software changes or bug fixes do not create new errors.

Reflection

This article was chosen because it clearly described the different types of box testing, and what each does. While reading the material, I realized that what we have done in class (equivalence class, boundary value testing) are actually black box testing techniques. I enjoyed learning about the different techniques that are used, and the benefits of them. Although developers and testers are two different roles, developers sometimes play the role as the end user when black box testing, so having a basic understanding of the different types of box testing will be helpful in the future.

References:

https://www.shakebugs.com/blog/black-vs-white-vs-grey-box-testing

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

Front End Testing

As my journey to becoming a full stack developer continues, I have begun to encounter the need for front-end testing. When finding an article, I realized that I did not have very much knowledge on what front-end testing entailed or how to implement it into my coding. I found the blog “Front End Testing: A Comprehensive Overview” by Kiruthika Devaraj (https://testsigma.com/blog/front-end-testing/) on my search for information on this topic.

The blog starts off by explaining that front-end testing is focused on the user’s experience. While past experiences have taught me that back-end testing specifically tests the functionality of the code, front-end, also known as the user-facing end of a website, testing has a higher focus on the user’s interactions. The author also delves into eight different types of front-end testing and the elements that make up these different types:

  • Unit Testing is the analysis and testing of the individual components to ensure they each work as intended. 
  • Acceptance Testing involves testing to ensure permissions, such as account accesses, are working properly. 
  • Visual Regression Testing tests for visual changes in the front-end by comparing a reference picture to a baseline image. This can typically create brittle tests that can fail due to the slightest changes in an element’s location on a page.
  • Performance Testing measures an applications stability and responsiveness under different levels of simulated stress and traffic.
  • Accessibility Testing ensures that individuals with visual impairments or other additional needs can still use and access the application to the fullest of their capabilities.
  • End-to-End (E2E) Testing involves testing the application from start to finish while testing all components and systems for how they work together.
  • Integration Testing is when each individual module is tested to ensure it has been implemented correctly.
  • Cross-Browser Testing tests that the application works correctly across multiple browsers and confirms compatibility.

Devarj also provides tips for better front-end testing, the first tip is to always use a testing framework. These frameworks, also called front-end tools, are what actually run the tests. Although countless front-end tools exist, the blog provides information to 3 popular options; Testsigma, Selenium, and Ranorex. Testsigma and Selenium are both open-source front-end testing frameworks that may be worth investigating further, while Ranorexis a commercial framework that may be more than what I am currently looking for. 

Front-End Testing Moving Forward

As I move to implement automated front-end testing into my projects, it is important to remember that the front-end testing is focused on ensuring the project is user-friendly, responsive, and visually appealing by testing the layout, design, and functionality across multiple browsers. Doing so will provide users with the best possible experience.

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

Boundary Value Testing

Exploring the Edges: A Deep Dive into Boundary Value Testing


In the realm of software testing, Boundary Value Testing (BVT) emerges as a cornerstone, spotlighting the crucial junctures at the extremities of software modules. This method, celebrated for its strategic focus, eschews the intricacies of internal code to scrutinize the behavior at pivotal points: the minimum, maximum, and nominal value inputs. Its essence captures the high propensity for errors lurking at the fringes, thereby underscoring its indispensability, particularly for modules sprawling with vast input ranges.

BVT transcends mere error detection; it embodies efficiency. By tailoring test cases to boundary conditions — including the crucial spots just above and below the extremes — it ensures a comprehensive examination without the exhaustive effort of covering every conceivable input. This approach not only conserves resources but also sharpens the focus on those areas most likely to be fraught with defects.

The methodology behind BVT is meticulous yet straightforward. It commences with the creation of equivalence partitions, a critical step that segments input data into logically similar groups. Within this framework, the boundaries are meticulously identified, crafting a testing landscape where both valid and invalid inputs undergo rigorous scrutiny. The beauty of BVT lies in its precision — it’s a targeted strike on the software’s most vulnerable fronts.

However, the path of BVT is not devoid of obstacles. Its lens, sharply focused on boundaries, may overlook the vast terrain of non-boundary inputs, a limitation particularly pronounced in Boolean contexts where only two states exist. Moreover, its efficacy is inextricably linked to the adeptness in defining equivalence partitions — a misstep here can skew the entire testing trajectory, transforming a potential asset into a liability.

Yet, the allure of BVT remains undiminished. In the high-stakes arena of software development, it stands as a sentinel at the gates of functionality, guarding against the incursion of boundary-related errors. Its role is pivotal, especially when the clock ticks against the backdrop of tight deadlines and expansive test fields.

BVT is more than a testing technique; it’s a strategic imperative. As software landscapes continue to evolve, the demand for precision, efficiency, and effectiveness in testing methodologies will only escalate. BVT, with its focused approach and proven efficacy, is poised to meet this challenge, proving itself as an invaluable ally in the quest for flawless software. In the hands of skilled testers, armed with a deep understanding and meticulous execution, it transforms from a mere method into a beacon of quality assurance. Boundary Value Testing (BVT) is a key black box testing method targeting software’s extreme limits to identify errors without delving into internal code, focusing on boundary conditions for efficient and effective error detection. It requires meticulous planning and execution, especially in defining equivalence partitions, to ensure testing success.

I read the blog on this link:
https://testgrid.io/blog/boundary-value-testing-explained/

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

Levels of Testing

https://testsigma.com/blog/levels-of-testing/#:~:text=The%20most%20common%20types%20of,system%20testing%2C%20and%20acceptance%20testing.

Different levels of testing software is very important when it comes to quality assurance and each of the different levels is based on different combinations of things that help ensure the best conditions and functionality of your software. The four different levels of testing are as follows: “Unit Test” which tests an individual component, “Integration Test” which tests an integrated component, “system Test” which tests the entire system and “acceptance Test” which tests the final system otherwise known as the final product.

Unit Testing is used to outline the expectations of a program or outline its functionality which in essence makes sure that certain parts of the program function as intended. Integration testing allows you to test groups of functions to make sure that they interact properly with each other which is a step above unit testing. System testing is similar to integration testing as it tests a ‘group’ of functions but this group is now comprised of every part of the program/application. Acceptance testing then tests all functional and non functional aspects of the program in order to ensure proper functionality, security, etc.

I selected the levels of testing as a topic as it directly relates to the types of testing we have been doing in class. We have been testing functionality of different bodies of code so far during this semester and we have used different techniques including but not limited to equivalence class testing, edge case testing, worst case testing, boundary value testing, etc. I would say that most if not all of these testing types would fall under the unit testing level of software testing as we have for the most part testing individual system components being able to learn about the different levels of testing makes me excited to continue on through the levels of testing.

This source was very helpful when it came to learning about the other levels of testing we have not used during class yet and I would recommend this article to any of my fellow students although this article does not go extremely in depth when it comes to the different levels of testing it does give you a good general understanding of each level so that you can go on to learn more without getting confused between the different levels of testing. The diagrams and explanations of the software sequence are valuable resources for a software testing course.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Testing your Boundaries

Boundary testing is a technique that “involves evaluating data based on boundary values… such as minimums and maximums.” It involves testing the lower and upper limits of a domain of inputs, as well as values just inside and outside those limits. This technique helps improve software quality by detecting defects early in the development process, which ultimately saves time and resources. This is due to the fact that “the number of defects at the boundaries of an input domain tends to be higher than in other areas of the domain.” 

Going back to how it saves time and resources, it helps developers choose more efficient test cases, which cuts down on time and how much they have to do, especially with large sets of data and number of inputs to consider. Furthermore, this technique “allows for a lot of uniformity and the test cases are much smaller” meaning that it can be automated. This would save more time, possibly result in less errors than if a person were to write the test cases, and allow for developers to put their focus on other tests or somewhere else, resulting in increased productivity. 

Boundary testing involves determining the input value range, which is whatever values the system accepts. Values inside that range are valid while those outside are invalid. Test cases are then created based on the values at the extreme ends, end values, and values just before and after the end values. For example, with a range of 0 to 100, we test values less than 0 (-50), greater than 100 (150), values around and at 0 and 100 (-1, 1, 99, 101). 

Another example the article shares is one that allows users to create a password. The password has to be 5 digits meaning that the range is 10000 at minimum and 99999 at maximum. Any combination of numbers is valid as long as it is 5 digits long, meaning that 4 digit long and 6 digit long passwords are outside the range and are invalid. 

Boundary testing seems like a very useful testing technique with very little downsides. It’s a black-box testing technique which usually means that testers don’t need extensive knowledge of coding, computer science, or the system at hand. It also seems very easy to do as long as all the necessary knowledge for testing is provided. Seeing as how it can also be easily automated, it may be more efficient to focus on more complex or time-consuming testing techniques while this test is running in the background or on the backburner.

https://www.indeed.com/career-advice/career-development/what-is-boundary-testing

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

Learn how to write unit tests

Hello everyone,

Today I want share a tutorial which explains unit testing with the JUnit 5 framework (JUnit Jupiter). It explains the creation of JUnit 5 tests with the Maven and Gradle build system. After reading it, you will definitely gain something new.

Here is the link:

https://www.vogella.com/tutorials/JUnit/article.html

“JUnit 5 tutorial – Learn how to write unit tests”

By Vogella GmbH

As a new software testing student, I recently stumbled upon the JUnit tutorial on the Vogella website while browsing for some knowledge about software testing. In this blog post, I will share my insights and discuss how this can help This knowledge is applied to our development practices.

This tutorial can be said to be a comprehensive guide that covers various details of JUnit. Including “What is software testing”, “Using Maven in the Eclipse IDE”, “Using the Eclipse IDE for creating and running JUnit test”, “JUnit 5 extensions” and so on. In chapters 1.2 and 1.3 of the article, it demonstrates how to use “assert” to check expected and actual results. Because “assert” is a powerful function, it contains almost all the judgments required by the scenario, so being proficient in the “assert” function is necessary as a software tester. Also, in Chapter 1.5 and 1.6, the article talks about unit tests are created in a separate source folder to keep the test code separate from the real code. This is the problem I started to encounter in HW1, my Gitpod cannot idenify all my Junit5 command. Because my test code and the real code are in the same path. So we should have a main path and a test path, as follows:

src/main/java – for Java classes

src/test/java – for test classes

In Chapter 2 of the article it explains how to use Assertions and assumptions. There are also examples of Testing for exceptions and Testing multiple assertions (grouped assertions) with assertAll, which we need to be proficient in and will use in the following assignments.

import static org.junit.jupiter.api.Assertions.assertThrows;

@Test void exceptionTesting() {

// set up user

Throwable exception = assertThrows(IllegalArgumentException.class, () -> user.setAge(“23”));

assertEquals(“Age must be an Integer.”, exception.getMessage());

}

Anyway, that’s why I recommend this tutorial. As a student who has just started learning software testing, I not only need theoretical knowledge about JUnit, I also need examples and explanations of practical application of this knowledge. This tutorial is exactly what we need, high quality and easy to understand. It left a lasting impression on me and I hope everyone will learn something from this tutorial.

From the blog CS@Worcester – Ty-Blog by Tianyuan Wang and used with permission of the author. All other rights reserved by the author.

Exploring Boundary Value Testing and Equivalence Class Testing in JUnit

Software testing is a crucial aspect of the software development lifecycle. Among various testing techniques, Boundary Value Testing and Equivalence Class Testing stand out for their effectiveness in identifying defects early in the development process. In this blog post, we delve into these two techniques and discuss their implementation using JUnit, a popular Java testing framework.

Boundary Value Testing: Boundary Value Testing focuses on testing the boundaries of input ranges. The rationale behind this technique is that bugs often lurk around the edges of acceptable input values. By testing values at the boundaries, we increase the likelihood of uncovering potential defects. For example, if a function accepts input within the range of 1 to 100, we would test values such as 0, 1, 100, and 101.

In JUnit, implementing Boundary Value Testing involves writing test cases that specifically target boundary values. By using assertions to verify the behavior of the function at these critical points, developers can gain confidence in the robustness of their code.

Equivalence Class Testing: Equivalence Class Testing aims to reduce redundancy in test cases by partitioning the input domain into equivalence classes. Each equivalence class represents a set of input values that should produce the same output when processed by the function under test. By selecting representative values from each equivalence class, testers can ensure adequate coverage without testing every possible input value.

In JUnit, implementing Equivalence Class Testing involves creating test cases that cover each equivalence class. Test inputs are chosen strategically to represent the entire range of possible inputs within each class. This approach not only improves test coverage but also makes test suites more manageable and maintainable.

Combining Boundary Value Testing and Equivalence Class Testing: While both techniques offer unique benefits, they are most effective when used together. By combining Boundary Value Testing to test the edges of input ranges and Equivalence Class Testing to cover representative values within each range, testers can achieve thorough test coverage with minimal redundancy.

Boundary Value Testing and Equivalence Class Testing are powerful techniques for improving the quality of software. By leveraging JUnit, developers can easily implement these techniques within their Java projects. By understanding the principles behind these testing strategies and applying them effectively, teams can build more robust and reliable software products.

Incorporating these testing techniques into your development workflow can help catch bugs early, reduce the risk of defects slipping into production, and ultimately enhance the overall quality of your software.

Link: JUnit 5 – User -guide/

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Bugs: Severity vs. Priority, and Why It Matters

While looking for more articles online involving testing, I came across SauceLabs. This website is another compendium of blogs, similar to stickyminds mentioned in my last blog. The layout and articles on this website were an excellent selection of resources dedicated to testing and quality assurance. While running through many bugs in my most recent projects and assignments, I was searching for an article dedicated to programming bugs. I found an article that fit my needs, dedicated to the differences between severity and priority of bugs, which is something I had not previously considered. The article’s title is Understanding Bug Severity vs. Priority: Key Differences and Best Practices by Chris Tozzi

The article provides (as the title indicates) a breakdown of bug severity and bug priority in software testing. It explains that bug severity is primarily concerned with the impact of a bug on the system’s functionality. Issues are categorized into the following levels of severity: critical, major, minor, and trivial. Each of these have a different level of impact on the system. For example, critical bugs may cause system crashes, while trivial bugs have a small functionality and performance impact. Bug priority focuses on the order in which bugs should be addressed, considering various factors that will impact the job as well as the program, such as deadlines, or bugs that are caused by higher priority bugs. Bugs with high priority require immediate attention, and those with low priority can be addressed later as the program develops and is tested further. It is an extremely important skill to be able to identify the severity and priority of bugs throughout the system and its development, so as to facilitate a smoother and more efficient development cycle. The article also provides some examples, such as a critical severity bug that causes data loss. This bug would ALSO have high priority because it is causing a lot of damage to the system’s structure.The article offers very useful recommendations for bug reports such as: establishing clear classification guidelines for bugs (priority/severity levels), communicating efficiently within teams, or reassessing bug statuses frequently.

I chose this blog because of my most recent experience in my assignments and projects. I had found that many bugs relied on each other, and I had never previously taken the initiative to learn more about bugs. When working with a team in industry, I will now have an understanding of how bugs are classified, as well as how to manage bug reports. This is something I had very little experience with prior to this article, and I will make sure to put extra effort into bug reports in my own projects with peers. I will continue to look into articles about bugs, testing, and QA to further improve my knowledge.

Source:
https://saucelabs.com/resources/blog/bug-severity-vs-priority

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

Foundations of Unit Testing in Software Development

In software development, Unit Testing turns out to be a crucial phase within the software testing lifecycle, ensuring that each component or “unit” of the software performs as intended and designed. I chose this topic really because it is all we have been doing the past 2 weeks in class and the whole course is about Quality Testing and Assurance so it makes sense. Also Since I am not a software developer (I’m a Data Analytics kinda guy) I have been trying really hard to motivate and enjoy the struggle of doing this courses assignments.

The GeeksforGeeks article provides a comprehensive overview of Unit Testing, defining it as a level of software testing where the individual units/components of a software are tested. The primary goal is to validate that each unit of the software code performs as expected. Unit Testing is typically performed by developers themselves or by QA engineers, emphasizing the importance of testing small parts of the project independently for errors. The article outlines the process, benefits, and challenges of Unit Testing, along with examples of tools that facilitate this testing method, such as JUnit for java and NUnit for .NET framework applications.

I went with this specific post because of the clarity and depth in explaining Unit Testing. It aligns perfectly with out course’s focus on Software quality and Testing, providing a solid foundation for understanding the complexities and nuances of unit testing within the software development lifecycle.

Upon reflecting the content, the article really highlighted the significance of Unit Testing in early bug detection, which not only saves time but also costs in the later stages of development. The emphasis on Unit Testing as a foundation for more comprehensive testing methods resonated with my understanding of a layered system strategy. It was really interesting to learn about the various tools and frameworks that support Unit Testing (though I may not know how to use them) across different programming languages, showing the universality and critical nature of this testing approach.

The knowledge gained from the article will reinforce my commitment to integrating Unit Testing future development projects. Recognizing its rile in maintaining high quality code and facilitating agile development processes. I am motivated to delve deeper into Unit Testing frameworks.

Unit Testing emerges as an indispensable practice in software development. The article serves as a valuable resource for understanding the principles and practices of Unit Testing, leading to a deeper appreciation for meticulous testing methodologies. As I move forward the principles outlined in this resource will be guiding my approach to quality assurance and testing

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

Behavioral Testing

For this week’s blog post, I chose the article “Behavior Testing | What it is, Why & How to Automate?” from testsigma.com. I selected this article because it fits within the Behavioral testing section in the course topics section of the syllabus. This article goes into great detail about behavioral testing, from discussing what it is to explain how AI could be used in its implementation. For this blog post, however, I will discuss the sections on what behavioral testing is and a couple of methods that can be used to catch errors with behavioral testing.

The article describes behavioral testing as a form of functional testing designed to test the external functionality of a system. “Behavior testing or behavioral testing is a type of testing that focuses on testing the external behavior of a software application. It is a type of functional testing. It helps ensure that software systems meet the expectations and requirements of end-users, making it a valuable part of the software development and testing process. Behavior testing is also known as black-box testing.” As described by the article, behavioral testing is essential to ensure that the systems or products you are designing work well enough so your customers can use them efficiently. There are many different methods when using behavioral testing to find errors, such as equivalence partitioning.

According to the article, one method that can be used with behavioral testing that is good at finding errors is Equivalence Partitioning. “The equivalence partitioning testing technique involves dividing the input data into different classes or partitions, such as valid and invalid data, assuming the system will behave the same for both inputs. Example – For a login form, if the password requires at least eight characters, you might test one case with a 6-character password (invalid) and another with a 10-character password (valid).” When using equivalence partitioning, because you are dividing inputs into separate groups, in a way, you can do two things at once. One is that the system functions as it should with valid inputs, and the other can catch invalid inputs. Another way behavioral testing can be implemented is through boundary value analysis.

According to the article, boundary value analysis is a form of behavioral testing focusing on the possible range of inputs, specifically numerical inputs. “It focuses on testing the boundaries of input ranges, as errors often occur at the edges of these ranges. Test cases are designed for values at the lower and upper boundaries and just above and below. Example – If an input field accepts values from 1 to 100, the test data can be 0, 1, 2, 99, 100, and 101.” This kind of testing can be very helpful in making sure that you have accounted for the possible range of inputs that a user may enter, both valid and invalid.

Article: https://testsigma.com/guides/behavior-testing/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.