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.

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.

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.

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.

For this weeks’ log entry, I wanted to cover a topic that was a bit different from the post that I made last week. One topic that caught my eye as being a perfect option to learn more about was Behavior Driven, and potentially also Test-Driven, development of code. When researching this topic, I came across a podcast titled, “Behavior-Driven vs Test-Driven Development & Using Regex in Python” by The Real Python Podcast on spotify. One of the largest factors that drew me to choosing this podcast to learn from was the fact that it was made incredibly recently (only a few months ago).

TEST-DRIVEN DEVELOPMENT:

A process of developing code that revolves around writing automated tests for code before ever actually writing the code itself. The process starts with a programmer writing a test for some sort of new feature that they want added to their code or that they want their code to be able to solve. After this, they write the smallest amount of code that they possibly can in order for that test to pass, potentially refactoring after the test is passed if they feel a need to do so. TDD originated before and was used to heavily inspire the agile process and scrum methodology that we see used today. TDD can be a helpful process to follow for several reasons. First, it ensures that you have actually written good tests and helps to mitigate any sort of temptation to cut corners when working on a project. TDD also helps teams to work specifically within the realm of what is being asked of them, rather than “gold-plating” their work and adding other features to their code that may not have been asked of them. Overall, TDD is very structured and easily provides a path for workflow to follow without confusion.  

BEHAVIOR-DRIVEN DEVELOPMENT:

BDD for short, in a way it is an extension of TDD, only focusing on the highest levels of the testing pyramid and involves Acceptance Test Driven Development. Essentially, before you ever write the function that you would use to test in TDD, you first write tests about how you think the application is actually supposed to behave. It focuses on a feature behaving in a particular way as opposed to that same feature returning a particular response. First, you would identify things that your code would need to create some sort of list that can be used to define what needs to be done or whether or not that feature is properly working. After identifying the need, you would write high level tests to check this. Same as in TDD, you would essentially be writing the code in parts, running tests in between to ensure that the code being written is being done so with an immediate purpose and goal to achieve within the project.

From the blog CS Blogs with Aidan by anoone234 and used with permission of the author. All other rights reserved by the author.

For this blog post, I’d like to discuss an interesting piece by Jeremy D. Miller titled “Effective Test-Driven Development”. It provides some practical tips and advice for developers on how to make the most of Test-Driven Development (TDD). I found it very relatable because it relates to what we’ve been discussing in our software development class, particularly testing and keeping our code in good shape.

Miller’s article delves into TDD, which entails writing tests before coding. While TDD is a common method, he explains how to avoid common issues and adhere to best practices. He discusses how too much setup code, slow feedback, and unnecessary tests can all contribute to slow performance. He contrasts these issues with good habits such as writing quick tests, providing timely feedback, and ensuring tests are clear about what they check in the code.

Miller also discusses how TDD can help with design and quick feedback. He mentions that TDD encourages developers to plan out how their code will look, making it easier to maintain and less buggy. The goal is to make testing an integral part of development rather than a final step, so that problems can be identified early.

I chose this blog because we had only touched on TDD in class and I wanted to see how it applied in real-world software development. I thought it was fascinating that TDD is about more than just writing tests; it’s also about improving code structure. Miller’s suggestions are ones I’d heard of but hadn’t looked into thoroughly. His advice helped me understand how TDD can improve code quality and make life easier for developers, which is extremely useful to me as a student learning to write solid code. Reading this blog made me realize how important it is to write tests that do more than just check if things work; they should also ensure that the code is easy to change later. Miller, for example, discusses “happy paths” in which tests check for expected results and “negative tests” in which errors are handled. This is consistent with what we’ve been learning about testing, but it also gives me a better understanding of how TDD can help clean up and improve code over time.

Miller’s post emphasizes the importance of not rushing through TDD. It’s better to take your time and write clean, manageable code. I found this extremely useful because, as a beginner, I frequently feel the need to complete tests quickly. But Miller reassured me that taking it slowly can save time in the long run by identifying problems early on.

I intend to use TDD more actively in future projects. By writing tests first, I can keep the end goal in mind from the start, reducing the need for major rewrites later. I also feel more confident about refactoring because TDD will help me keep the code solid while I make changes.

In the future, I want to incorporate Miller’s concept of clear intent expression into my code. Writing tests that clearly demonstrate what the code is supposed to do will simplify things for others and help me stay focused when working on larger projects.

Blog: https://jeremydmiller.com/2022/10/03/effective-test-driven-development/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

While teamwork may not be listed as one of our topics for the course, if I’ve learned anything during this semester it’s that teamwork yields massively more results than testing alone. We just recently did an assignment where we were given “shaky” code to look at and record any errors we found. We started by going off on our own to look for errors. We then came back together to see what everyone found, and it was amazing how different our lists look. Even though it was the same code everyone caught a ton of different mistakes.

There are plenty of benefits to teamwork in the software testing field. “The Importance of Collaboration in Software Testing Teams” is a great blog I discovered that fully goes over these benefits. Unfortunately, the author did not leave their name anywhere and signs off as “admin” so I can’t give them the full credit due, but I linked the blog above if you want to give it a read over.

Some key takeaways are early issue identification, improved software quality, and increased efficiency. There’s many more listed in the blog, but these are the three I find most important.

In one of my previous blogs, I mentioned just how much more it can cost to fix a mistake that slips through the early phases of software development so having early issue identification is huge. Through multiple eyes looking at the same software everyone is able to use their own unique perspective to weed out as many bugs as possible.

As for improved software quality and efficiency, how can you not say yes to better software, faster. That’s just a win for everyone. Every developer has their own style and methods to solving problems and by combining them you can create innovative solutions that can drastically increase efficiency while creating more sound programs.

Teamwork has been a large part of my computer science degree at Worcester State. I plan on continuing to sharpen my skills as both an individual and a teammate as I progress through my career both academically and professionally.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

TDD or test driven development is a method of building software by creating tests first and then writing the implementation of the code. This blog breaks down what TDD is and the steps to the process. TDD aims to help developers build a program that meets the requirements. By building to meet certain criteria, programmers will always keep the goal in mind. Building with certain behaviors or outputs in mind. The first step is to write a test list. Essentially you are writing tests with the end behavior in mind. It is writing tests, but this stage is also an analysis. An analysis of what the programmer or team or whoever thinks the final program behavior looks like. The next step is to write a test, one that is robust and fully implemented. With one test implemented, the program implementation is now taking shape. Because the program must be made in a way so that it will work for the test. Now that you have a test, the next goal is to make that test pass, by any means necessary. After that you can refactor depending if the tests or implementation needs to be changed to make the program better. Then it becomes a matter of repeating the process until the test list is through.

I think TDD is a very interesting approach to programming. Usually we think of the typical process of build first and then testing. But TDD reverses that, and it creates a very dynamic when it comes to building software. I never really thought about it before but the way you build a test does affect the way the program is implemented. Like if your test is expecting a string or integers, you have to build the implementation in a way that returns those types. There are many ways to make a test that does the same thing. But those tests go about it in a different way. Thus that changes the way you program the implementation. I also think TDD adds focus and direction to programming. As you always know what you need to return or what the expected output looks like.

https://tidyfirst.substack.com/p/canon-tdd

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