Category Archives: CS@Worcester

Understanding Equivalence Partitioning and Boundary Value Analysis

While doing an activity related to Software Quality Assurance concepts in class, I came across an article that clearly explained two crucial black-box testing techniques: Equivalence Partitioning (EP) and Boundary Value Analysis (BVA). The article, “Equivalence Partitioning and Boundary Value Analysis” by Alan Liew, stood out to me because of its simple examples and approachable language. I appreciated how it used realistic scenarios like age and email validation to make the concepts easier to understand.

In summary, the article defines Equivalence Partitioning as a technique that divides input data into partitions or sets that are treated similarly by the system. Inputs from the same partition are expected to behave the same way. For example, if users are allowed to register only when their age is between 1 and 21, then that range is a valid partition, while any value outside it is considered invalid. The article also introduces the idea that only valid partitions should be combined in testing, whereas invalid ones should be tested individually to catch specific error messages or bugs.

Boundary Value Analysis builds on this by emphasizing that input values at the edge of partitions, like 1 and 21 in the age example are more likely to uncover boundary-related bugs. It explains the 2-value and 3-value BVA methods. A 2-value BVA tests the boundary and its neighbor (e.g., 0, 1, 21, 22), while a 3-value BVA goes even further (e.g., -1, 0, 1, 2, 20, 21, 22, 23). This distinction is important for thorough testing and to avoid letting bugs slip by due to limited test coverage.

I chose this topic because it was one of the activities during class that initially confused me. I struggled to understand its purpose and how it applied in real testing scenarios. I wanted to learn more about why this technique matters and how it fits into the bigger picture of software quality assurance.

From the article, I learned that testing isn’t just about checking if a system works, it’s about designing the right test cases to catch errors early. Testing with both valid and invalid inputs, along with carefully chosen boundary values, helps ensure robust software. I also realized how combining invalid inputs in one test can lead to overlooked issues because one error may hide another.

Moving forward, I plan to use these strategies in future development and testing projects, especially where user input validation is involved. I hope to explore more QA topics like this to gain deeper insight into the role of a software tester.

Reference:
Liew, A. (2024, July 14). Equivalence partitioning and boundary value analysis. Medium. https://alanliew.medium.com/equivalence-partitioning-and-boundary-value-analysis-c940a0c120f5

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

Learning About Spies in Unit Testing

In my software testing class, we’ve been learning a lot about unit testing and how to make sure our tests are clean and focused. For our group project, I needed to learn more about spies specifically. I came across a blog post on testRigor called “Mocks, Spies, and Stubs” that seemed to offer everything I wanted. I already knew a good bit about mocks and stubs, but spies were still kind of confusing to me, and it doesn’t hurt to review.

Summary of the Blog Post

The post explains how testing tools like mocks, stubs, and spies help isolate the code you’re testing. That just means you’re testing one piece of code without depending on other stuff like a real database or API.

Spies are used when you want to track what happens during a test. For example, you can use a spy to see if a method was called, how many times it was called, and what it was called with. What’s different about spies is they don’t change what the function does unless you want them to. They just track what happens for you.

Why I Picked This

I picked this blog because we’ve been working on our spies POGIL, and we haven’t covered these ourselves in class. I figured now was a good time to figure it out. It also helped me understand how spies are different from mocks and stubs, which I didn’t fully get before.

What I Learned

The main thing I learned is that spies are great when you want to see what a method did without actually changing how it works. That sounds really useful for stuff like tracking clicks or making sure a method only runs once. It also helped me realize that mocks and stubs have different purposes too, as mocks check behavior and stubs give fake data.

How I’ll Use Spies

I think I’ll try using spies when I need to test things that happen in the background or when I just want to see if something got called. They seem useful when you don’t want to mess with the actual code but still want to make sure it’s doing what it’s supposed to, and in a pretty safe manner.

Conclusion

After reading this blog, I understand spies way better. They’re another helpful tool for writing good tests, and now I know when to use them instead of just guessing.

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

JUnit Blues

Hello!

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class.

As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time.

I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that.

Thank you for reading my blog!

Camille