Category Archives: CS-443

The Importance Of Security Testing

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.

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.

Testing Smells

For the last homework in the course, we were assigned the task as a group to create a lesson plan for the class to do and put it in a POGIL activity. My group sat for a while throwing around ideas before I came across something called testing smells/code smells. Testing smells, also known as code smells, which refer to issues and/or warning signs in an individual’s code that won’t necessarily throw an error or cause the code not to run but likely leads to some bigger issue that would cause fundamental problems in the code. 

Code smells come in all shapes and sizes and often seem harmless or meaningless such as reusing variable names, repeating lines of code, hard coding data and more. Testing smells typically refers to code smells that occur specifically in the testing files. These mistakes affect the validity, functionality, and reliability of a test. 

Since the whole purpose of testing is to check for problems or potential issues in the code, testing smells is a serious issue that is worth learning about. I watched this video on youtube called, “a few common code smells to be aware of and how to fix them”. 

In this video, the individual talks about how testing smells can often point to bigger problems in the code which are important to pay attention to. The first code smell that is mentioned in the video is long functions. The video explains how long functions may seem harmless at first, especially to programmers that are first starting out, but the purpose of a function is to perform one task simply and directly. Long functions often do more than one thing, making them complex and convoluted, therefore more prone to causing bugs in the program. This also makes them more difficult to maintain and to fix.

Another testing smell mentioned is duplicate code. Duplicate code is another testing smell that seems harmless because from a technical standpoint, although a tedious task, does it really matter if you rewrite the same line 30 times? While it is true that if you do this perfectly the functionality of the code shouldn’t be affected, the code will still become messy and unreadable. Additionally, repeating code in this manner increases the likelihood of making a mistake. Turning repeat code into a function or having them inherit from a shared class not only improves cleanliness and readability but prevents simple and clerical errors that would cause frustration at a later point in the coding process.

Overall, Testing smells is something that I believe is an important subject matter worth learning about in order to improve coding ability both on a personal and professional level.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

Dice Game Code Review

This week we started to work on our own POGIL activity similar to the Sir Tommy code review. The activity the team has chosen will be a dice game with a specification sheet that expects the people to do the activity based off of the specification sheet. The sheet is going to have specific questions asking what lines contain bugs or have format issues that are not best practice. This will help the students read code more in depth as well as to work together in searching for bugs and format issues. The team is going to meet out of school to determine the questions and how we will go about working on the project. We will also focus on the types of questions we are going to ask in order to make the reader think about what they are reading and to critically think about how they will address the issues presented in the source code as well as test code.
                We are thinking about making a few models explaining and asking questions that send the users to the code to examine it, but also think about much deeper than just the code they are looking at. We will implement Encapsulation, Inheritance and Polymorphism. This means that the users will have to read and understand underlying methods within other methods in order to progress through the models, but it still will be simple enough so that the users do not take up too much time and can focus on the questions rather than the code.

In class yesterday we talked about what other teams were doing, and it was very interesting that everyone took a different approach to the homework. I am still glad my group stuck with sir tommy due to underlying issues with the original that we thought was a good idea to add certain bits and pieces to make the activity more understandable. We did the model questions asking about stubs, mocks, fake and dummies in mind, we dedicated an entire model to these objectives so that the student would understand how each works and how to create and get rid of each for a more optimal solution.

                Overall, this activity showed me how much I learned about different types of testing how to read and understand certain aspects of other people’s codes as well as paying close attention to imports as usually you assume the imports are always correct. I also learned that I have been using dummies, fakes, stubs and mocks without knowing since I did not have prior knowledge to these types of testing. I really enjoyed the class as well as how it was structured and how we had to figure things out on our own as well as a team.

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

The Best Java Testing Framework: JUnit

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.

Security Testing

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.

How to Perform Security Testing In Web Applications

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

Software Technical Review

Week 14 – 5/2/2025

This is my last week of class, and this is kind of bittersweet. The topic for this week was software technical review. While I was working on my last project for the class, I went ahead and read a blog post called “What is Technical Review in Software Testing?” by Ritika Kumari. I did not read this article to find out what a technical review is but to learn more about the process of it.

The article gives a suitable introduction to technical reviews in software testing, stating that technical reviews are formal assessments conducted by technical reviewers to examine software products like documentation, code, and design. Technical reviews are designed to check compliance with standards, enhance the quality of the code, and identify defects at the initial phase of the Software Development Life Cycle (SDLC). The blog discusses how technical reviews reduce the cost of rework, enhance the level of expertise of the team, and get software outcomes in line with business goals.

I picked this article because it is very much in line with the topic we had for this week’s class. The article mixes practical applications, such as Testsigma’s integration for test case management, with abstract concepts, like static testing and peer reviews. Its emphasis on collaborative procedures also aligns with our class’s ideas about agile teamwork.

The blog highlighted the importance of spotting design or code bugs early in development, for if one does so, he or she can save post-release costs up to 70%, as illustrated through the example of re-engineering faulty software. This aligns with the “shift-left” testing philosophy that we examined. Technical reviews are as much about information sharing as they are about error detection. For example, I had not realized how much cross-functional knowledge was built up through walkthroughs and peer reviews. I will look to apply this idea further in automation efforts. Testsigma’s review capabilities, such as automated test case submission and element management, demonstrated how tools could speed up reviews. The blog made me rethink my understanding that reviews are only a “checklist activity.” Rather, they are interactive processes that achieve harmony between teamwork and technical correctness. For instance, the difference between formal defect-oriented inspections and informal knowledge-swap peer reviews led to a better understanding of how to customize reviews according to project requirements. I will promote systematic technical assessments in my next work environment in the future. This class overall was an interesting class and I hope to use the lessons that I have learnt throughout my professional career.

https://testsigma.com/blog/technical-review-in-software-testing/

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

Static Testing vs. Dynamic Testing

Hello everyone,

This week’s blog topic is about Static Testing vs. Dynamic Testing. This is something we discussed at the beginning of the semester but nonetheless is still very important to know. It took me a bit of time to understand the differences between the two and when was each one used but after reading this blog it made it a lot clearer to understand but let’s start with what they are. Let’s start with just a simple definition to separate the two terms. Static Testing which is done manually without executing the application and dynamic testing is an automated approach that involves executing the code and testing it in various ways within a closed run-time environment. If we read more into the blog we can understand that Static Testing is the process of checking an application or website without executing the code. It’s a manual process and it is done usually in the early stages of the development life cycle. A person compares the code against the requirements and specification  that he needs to meet and this review allows him to identify any flaws, defects or possible changes. Now Dynamic Testing is more for the customer and user experience and it is the process of executing controlled tests and experiments on live digital platforms with real user traffic. Unlike static testing, where you manually have to review the design and the actual code, dynamic testing deploys different variations in order to understand how users behave and then they can analyze user engagement and other performance data.

The blog does a great job of not only explaining the definition of the two different types of testing but also gives the Advantages and Disadvantages for both. For example as per the authors notes he says that Static shines on identifying  potential experience issues upfront in the early stages of the development process. This helps to positively impact performance metrics before launching to the customers and also prevents a poor experience for the developers as well. But it has some disadvantages like it heavily relies on the expertise of reviewers evaluating designs, the better the reviewer the better the static testing. It is also very time consuming and may not catch flaws that can only appear in real and actual user interaction. For the Advantages of Dynamic Testing we have that it is amazing at allowing continuous optimization of multiple experiences. It has Controlled experiments that lets you roll out new features and experiences with minimal risk and its ability of Automated testing means you can quickly scale testing. While it sounds amazing and all it has some Disadvantages which are that it can be very time-consuming for complex experiments with many versions. In some cases it won’t cover every potential user scenario and edge case and it requires a lot of upfront investment in testing tools. 

In conclusion, it is very important to know and use both testing types so you can get the best of both worlds!

Source:

https://monetate.com/resources/blog/static-testing-vs-dynamic-testing/

From the blog Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

Code Reviews and Their Importance in Keeping Maintainable Code

Summary of the Blog

The article emphasizes that code reviews are not just about finding mistakes but are primarily about improving code quality, spreading knowledge across the team, and building better, more maintainable software.

  • Code reviews help maintain consistent coding standards across a project.
  • They foster team learning, as developers can see different approaches to solving problems.
  • Good code reviews catch potential bugs and architectural flaws early, preventing costly fixes later.
  • Reviews create a sense of shared ownership over the codebase, leading to more sustainable, long-term development.

He also stresses that code reviews should be approached positively, focusing on collaboration rather than criticism. The goal is to help, not to criticize harshly, and reviewers should offer suggestions rather than simply pointing out what’s wrong.

Why I Chose This Resource

I chose this blog because it reads as someone who actually has been through the experience of not doing them and realizing the hard way why they exist and are used regularly. It’s a resource that goes through the whole process of code reviews, but the added element of feeling that the person writing it actually understands why the thing they are explaining is useful makes it feel a lot more credible. It also just makes it easier and more interesting to read in my opinion.

Personal Reflection

Messy codebases can lead to immense technical debt over time, and code reviews are the solution. Of course it would be great to simply adhere to the rules and standards set by the group to avoid the sloppiness in the first place, but the code reviews are necessary to ensure that if there is messy code it doesn’t make it into the production branch, like a last defense. The steps laid out in the blog create a healthy environment to improve the code being reviewed, while also being respectful in the manner it is done. The checklist of standards to go over during the review makes sense and is the base of keeping everything “correct”, but it pleasantly surprised me when they mentioned the correct way to communicate the changes. Most people wouldn’t think about how they mention the changes found, but this blog states the correct way, even showing examples, which takes into account respect for the developer as well as being descriptive / informative with the comment. 

Conclusion

This blog made me understand why code reviews are important. Before reading I thought similarly to the author that code reviews are a waste of time and just some bureaucratic process, but now I see that the time spent on making all of the code cohesive and adhere to coding standards actually saves a lot of time in the long run from fixing bugs and reading sloppy code. 

Citation

Kravcenko, V. (n.d.). The Importance of Code Reviews. Retrieved from https://vadimkravcenko.com/shorts/code-reviews/

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.