As a computer science student getting more into the details of software development, I’ve started to realize how much goes into making sure software actually works the way it’s supposed to. I recently read the article “13 QA Testing Best Practices For 2024” from Testlio, and one part that stood out to me was the idea of risk based testing.
(testlio.com)

Risk based testing is all about using your time and effort wisely. Instead of trying to test every single feature equally, it focuses on the stuff that matters most. You look at what parts of the app are most likely to break or cause problems for users if they fail. Then you make sure those are tested thoroughly before anything else.

The article explains that identifying risky areas early helps teams put their energy in the right place. If you’ve only got so many people and so much time, this method helps avoid wasting those resources. It also means the most important features are solid by the time the app goes live.

This reminded me of a group project I worked on where we made a class management web app. We spent way too much time testing features like color themes and user bios. But when it came to the assignment submission tool, which was probably the most important part, we barely tested it. Sure enough, after we deployed it, users had issues uploading their files. If we had used risk based testing, we probably would’ve caught that.

Now that I know about this approach, I’m going to start using it in future projects. I’ll take time up front to figure out which features are most essential or most likely to go wrong, and make sure we focus testing there first. It’s a simple idea, but it makes a big difference.

In the end, risk based testing is about being smart with your time and making sure what matters most actually works. If you’re also learning software testing, this is a great thing to start thinking about. I definitely recommend checking out the full article if you’re curious:
13 QA Testing Best Practices For 2024

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Manual and automated testing are the two ways to run tests. One involves human touch while the other needs very little from a third party to work. While one would think automated testing is better in almost every case. That’s not necessarily true. To start, in most cases automated tests are just better. They are more efficient and save people a lot of time. They can be run over and over again. And can be run every time code is pushed, instead of having to be manually runned. Oftentimes the only times manual testing is useful is when things are tested for use by humans. Meaning things like testing how an app feels to use or how the functions in practice. These areas require testing things that are hard for a computer or code to test.

Manual testing can be more cost effective depending on the circumstances. But manual testing is also subject to more error due to the nature of human involvement. Tests are more adaptable because they can be changed more easily. While automated tests being changed might take more time to change to make sure they work with the code. Automated testing offers more coverage since they can be made small and can cover various areas of coding. Automated tests can also handle larger test cases that span over a large area. While manual testing struggles to handle something so large. Overall I’d say that automated tests seem better to use in general. Aside from things like testing for human feel, automated tests seem to handle most things better.

https://www.testrail.com/blog/manual-vs-automated-testing/

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Security testing is a major area of testing that is very important. In today’s world, security is imperative to a softwares effectiveness. Without security software will be targeted and used against people. The cost of data breaches result in humongous money loss. Some of the goals in security testing is to find weakness in code, finding the impact of security breaches, report findings, and eliminating risks. Some of the principles of security testing is having realistic tests that test real world applications. Tests that are through and wide spanning. Continuous testing because the nature of security and attacks is always changing. Testing should be a collaboration of all parties involved in the software development process.

We always hear on the news about data breaches for some company that cost billions of dollars. It’s hard to put into perspective how much money that is and how that actually affects people. The security of software has real world consequences on people. It’s not something to take lightly. We have to protect software in order to protect the people using it. It’s just as important as testing to make sure the software works. In the blog it said that negligence in security breaches leads to a higher fine. Which makes sense since if you willingly ignore security breaches you’re putting peoples livelihoods at stake, not just at the company. There are many different areas to security testing. API testing, HTTPS, Cloud, basically any area that requires communication is subject to hackers. 

https://fluidattacks.com/blog/security-testing-fundamentals/

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

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.

Summary of the Source

The blog post introduces JUnit as a unit testing framework designed for the Java programming language, explaining its evolution, core features, and significance. It outlines the primary components of JUnit, such as test cases, test suites, annotations (like @Test, @Before, and @After), and assertions. The guide also discusses test driven development (TDD) and how JUnit supports this methodology by encouraging developers to write tests before writing the actual implementation.

Additional features covered include mocking with Mockito and how to structure test cases for better readability and maintainability. Overall, the article serves as both an introduction and a deeper dive for those wanting to use JUnit effectively in real world software projects.

Reason For Selecting This Blog

I chose this blog post because it well written, and in only a roughly 10 minute read, covers everything there is to know about JUnit, at least as a foundation for starting out with it. It goes over what it is, why its used, and even its history, before diving into how to set the environment up to use it, the shows examples of test cases using JUnit. I think its an overall great resource for any developer who is interested in testing using Java as it covers all the bases.

Personal Reflection

I was introduced to JUnit in university, and learning it there was really helpful towards understanding how testing code works in general. I also liked JUnit especially because it seems very easy to understand and write, where only a couple lines of code could write a test case for your code. Assertions are especially useful as that’s the end result of the test, and with JUnit it’s very simple. One line of AssertEquals tests the expected vs the actual, that’s all it takes to test the correct output. I also see how this framework would be preferred when doing test driven development as each test is separated into different cases denoted by the @Test annotation. This makes it easy to make specific tests for each feature as development continues. I haven’t tried any other testing frameworks but now that I have used JUnit I think it won’t be as confusing to understand a different framework, but since I like how JUnit works I’ll compare the others to it like it’s the gold standard for testing frameworks.

Conclusion

Knowing about JUnit is imperative if you plan on testing code in Java. It has everything that a testing framework could want by making it easy to write, handle multiple test cases, and including assertions. I know that if I ever use Java in the future to test code, I will use JUnit because of how powerful, reliable,  and simple it is.

Citation:
HeadSpin. (n.d.). JUnit: A Complete Guide. https://www.headspin.io/blog/junit-a-complete-guide

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

Week 13 – 4/27/2025

OWASP Web Security Testing Guide (WSTG) is a globally recognized standard for web application security testing. It presents a formalized methodology divided between passive testing (e.g., information gathering, application logic knowledge) and active testing (e.g., vulnerability exploitation), with key categories including authentication, authorization, input validation, and API security. The guide defines the black-box approach first, mimicking real-world attack patterns, and includes versioned identifiers (e.g., WSTG-v42-INFO-02) to give more transparency with revisions. Collaborative and open-source, the WSTG accepts input from security professionals to have the document updated in real-time on new threats.

I chose this resource because we use web applications every day, and it is interesting to see how security testing is implemented in them. The WSTG is ideal for students transitioning into cybersecurity careers due to its systematic nature, which bridges the gap between theoretical concepts (e.g., threat modeling) and actual evaluation procedures. Its emphasis on rigor and reproducibility echoes industry standards that are widely discussed in our training, e.g., GDPR and PCI DSS compliance.

I was impressed with the WSTG’s emphasis on proactive security integration. I’ve noticed that fully automated approaches occasionally overlook context-dependent vulnerabilities like business logic problems, so its suggestion to combine automated tools (like SAST/DAST) with manual penetration testing closes that gap. The manner in which the tests are categorized in the guide, i.e., input validation testing to avert SQL injection, offers a clear path for risk prioritization, which I now see is a skill I must acquire for effective resource allocation in real-world projects. An extremely useful lesson learned was the importance of ongoing testing along the development trajectory. Our study of DevOps practices is supplemented by the WSTG “shift-left” model, adding security at the beginning of the SDLC and minimizing risk post-deployment. One way of finding misconfigurations before deployment is using tools like OWASP ZAP, which is explained in the handbook, during code reviews. However, novices may be overwhelmed with the scope of the instruction. I will start by addressing this with its risk-based testing methodology, with particular emphasis on high-risk areas such as session management and authentication. This is in line with HackerOne’s best practices in adversarial testing, where vulnerabilities are ordered by their exploitability potential.

Going forward, I would like to use the approach of the WSTG taking advantage of the guide’s open-source status to support collaboration, for example, holding seminars for developers on threat modeling, which is emphasized as an important step in NordPass security best practices. I would like to improve application security and support a proactive risk management culture through the adoption of the WSTG’s formalized approach. This is important in the current threat landscape, where web application vulnerabilities represent 39% of breaches.

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