The main point of the article is that basis path testing gives developers a systematic way to test the logic of a program. Instead of guessing which test cases to write, testers analyze the structure of the code. The process starts by creating a control flow graph. This graph represents how the program moves from one statement to another, especially around decision points like if statements or loops. Each branch in the graph represents a different path the program could take.

Once the graph is created, the next step is calculating cyclomatic complexity. This value represents the number of independent paths through the program. From that number, testers know the minimum number of test cases needed to ensure that each path is executed at least once. The goal is not simply running the program with random inputs. The goal is intentionally covering the different logical paths that exist in the code.

One thing that stood out to me while reading this article is how structured the approach is. Before learning about path testing, I mostly thought about testing in terms of inputs and outputs. If a program produces the correct output, the test passes. If it does not, there is a bug somewhere. This article shows that testing also involves understanding how the program is built internally. Looking at the structure of the code can reveal paths that might not be obvious when only focusing on outputs.

The concept also made me think differently about how bugs appear in programs. A program might work perfectly for one path but fail on another path that rarely gets triggered. If that path is never tested, the bug could remain hidden for a long time. Basis path testing tries to prevent that by ensuring every independent path is executed during testing.

I chose this article because it directly connects to what we have been discussing in class. Reading another explanation of the concept helped reinforce what path testing is trying to accomplish. It also helped me see how techniques like control flow graphs and cyclomatic complexity are not just theoretical ideas. They are tools that developers use to design better test cases.

Going forward, I expect this concept to influence how I approach testing in my own projects. Instead of only thinking about typical inputs, I want to think more about the structure of the code itself. Looking at the branches and decision points in a program should help identify paths that need to be tested. That approach feels more intentional and more likely to catch issues before they become bigger problems.

Link: https://blog.testlodge.com/basis-path-testing/

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

As someone new to software testing, yet working with it for my capstone project, I selected this piece because it presents a few practical caveats that I will need to consider, in that test suites need maintenance, tests can be buggy, and automation changes the nature of testing work rather than removing it. We have yet to get to testing automation in our course, and while I have been looking into it personally for my capstone I mentioned earlier, this is the first blog post I have found that serves as a sort of “reality check”, presenting realistic  hurdles of the practice that I will definitely come across. 

I learned that automated tests are another codebase that requires the same discipline as production software: design, code review, debugging, and maintenance. This reframes automation as a more conventional dev task to me, which makes it feel somewhat more intuitive. The article also helped me understand the limits of automation for exploratory, usability, and context-sensitive checks that require human judgment. Going forward, I will prioritize writing maintainable, focused automated checks that target stable functionality and avoid brittle end-to-end scripts that duplicate application complexity. I will treat automation as part of the development lifecycle, putting the development through the same checks; code review, proper development principals, etc. Finally, I have begun to see automated testing as a way to free up time for exploratory testing, allowing for me to act as the “human” side of things, while the automated test covers the more general aspects. 

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

As someone new to software testing, yet working with it for my capstone project, I selected this piece because it presents a few practical caveats that I will need to consider, in that test suites need maintenance, tests can be buggy, and automation changes the nature of testing work rather than removing it. We have yet to get to testing automation in our course, and while I have been looking into it personally for my capstone I mentioned earlier, this is the first blog post I have found that serves as a sort of “reality check”, presenting realistic  hurdles of the practice that I will definitely come across. 

I learned that automated tests are another codebase that requires the same discipline as production software: design, code review, debugging, and maintenance. This reframes automation as a more conventional dev task to me, which makes it feel somewhat more intuitive. The article also helped me understand the limits of automation for exploratory, usability, and context-sensitive checks that require human judgment. Going forward, I will prioritize writing maintainable, focused automated checks that target stable functionality and avoid brittle end-to-end scripts that duplicate application complexity. I will treat automation as part of the development lifecycle, putting the development through the same checks; code review, proper development principals, etc. Finally, I have begun to see automated testing as a way to free up time for exploratory testing, allowing for me to act as the “human” side of things, while the automated test covers the more general aspects. 

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

As someone new to software testing, yet working with it for my capstone project, I selected this piece because it presents a few practical caveats that I will need to consider, in that test suites need maintenance, tests can be buggy, and automation changes the nature of testing work rather than removing it. We have yet to get to testing automation in our course, and while I have been looking into it personally for my capstone I mentioned earlier, this is the first blog post I have found that serves as a sort of “reality check”, presenting realistic  hurdles of the practice that I will definitely come across. 

I learned that automated tests are another codebase that requires the same discipline as production software: design, code review, debugging, and maintenance. This reframes automation as a more conventional dev task to me, which makes it feel somewhat more intuitive. The article also helped me understand the limits of automation for exploratory, usability, and context-sensitive checks that require human judgment. Going forward, I will prioritize writing maintainable, focused automated checks that target stable functionality and avoid brittle end-to-end scripts that duplicate application complexity. I will treat automation as part of the development lifecycle, putting the development through the same checks; code review, proper development principals, etc. Finally, I have begun to see automated testing as a way to free up time for exploratory testing, allowing for me to act as the “human” side of things, while the automated test covers the more general aspects. 

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

From the blog BforBuild by Johnson and used with permission of the author. All other rights reserved by the author.

What is Test-Driven Development?

TDD is fairly self explanatory, actual development of code happens after unit tests are created for a program. Essentially you are writing the tests, and then writing the code for those tests after. Nicola gives a good visual of how the process works.

• RED – Write a unit test, run it and watch it fail.
• GREEN – Write the minimum amount of code needed to make the test pass
• REFACTOR – Eliminate the duplication (both in the test and in the code, including duplication between test and code).

Benefits to TDD:

The IBM article makes some good points on the benefits of TDD. For example TDD “..can allow coders to gain better insight into their projects and help drive program design. By centering the test case before each feature is implemented, developers must visualize how a function will be used by a client or user. This approach positions the product interface before the implementation and helps developers create more user-centric applications.” A few other benefits consist of:

• Improved documentation
• Reduced debugging
• Facilitates continuous integration
• Strengthens mental models.

Challenges with TDD:

We have some pretty good benefits to this style of development, but there are certainly challenges to it, including:

• Increased code volume
• Increased overhead
• Neglect of overall design

Most of these issues stem in the fact that TDD requires more code, and as a result more time, so it may be slower in development. Also, developing code for individual tests may effect how their individual feature updates will integrate when compiled into the overarching software application.

Conclusion

Cool, so now we know everything that is needed in order to use Test-driven development, how am I then able to then apply this in my career?Nicola has a great example in his blog, which I’d suggest checking out after, and its a matter of finding a basic application like building a throttler & following the steps.

Ultimately, i’m certain this would be something I’d find useful sometime in the future as well as many other rising software developers.

Links:
https://dev.to/napicella/test-driven-development-by-example-29g8
https://www.ibm.com/think/topics/test-driven-development

From the blog CS@Worcester – Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

In this technique, the software tester creates a graph similar to how its done in path testing. Nodes are marked with some information. For instance, when a line of code declares some variable, you mark that node representing that line of code as DEF for define (though this can be changed by the tester). When a variable is used in a line of code, the tester should mark that node representing the line of code as USE.

Like with path testing, we use this technique to better understand the flow of a given program, but more specifically, in the case of data flow testing, we analyze the flow of data in the program. This can be helpful in preventing very nasty bugs related to data flow such as defining a variable before using it, or using a variable unintentionally, or even writing a variable incorrectly.

In my personal projects, I honestly could see myself in the near future using this technique. Especially for languages like C and C++ that don’t have garbage collectors, where you have to manage memory by hand, it can get cumbersome tracking down data flow related bugs. Right now I have a project I am working on in C where I am recreating Minecraft. I am doing everything mostly from scratch meaning I have to manage memory using my own systems.

Let me tell you that I could definitely use this testing technique, as the more features I add to the project, the more data flow issues start to arise. One time I spent a whole week trying to track down a segmentation fault, which is when a program access data out of its given address space. If I had implemented a system to track data flow, I would have been able to more easily see the cause of the error. it would have taken a fraction of the time.

Path testing would also be very helpful to implement, especially in the rendering and game logic portion of my application. This would help me visually see the flow of my program and allow me to nip really hard to track bugs like null pointers and buffer overflows and things like that.

In future, I do want to add data flow testing, path testing, as well as all the other techniques (asserts, boundary testing) into the build/testing system for this project. I want to build this in a way were I can use these systems for other projects in these types of low level projects.

-Mordecai

From the blog CS@Worcester – The Devlog by Mordecai Yiadom and used with permission of the author. All other rights reserved by the author.

The article
“Comprehensive Guide to Equivalence Partitioning Testing” from TestGrid
explains an important software testing technique used to design efficient test
cases. Equivalence partitioning is a black-box testing method where input data
is divided into groups, or “partitions,” that are expected to behave the same
way in the system. Instead of testing every possible input value, testers can
choose one representative value from each partition to verify the system’s
behavior. This approach reduces the number of test cases while still
maintaining good test coverage. The article explains how the equivalence
partitioning is useful when the range of possible inputs is large and testing
every value would be wasting time. By grouping similar inputs together, testers
assume that if one value in the group works correctly, the rest of the values
in that group should behave the same way. For example, if a
form only accepts ages between 18 and 59, the test cases can be divided into
three partitions: valid ages (18–59), ages below the valid range, and ages
above the valid range. A tester can then choose representative values from each
group instead of testing every possible age.

I selected this
article because it directly relates to our course topics on software testing
techniques, particularly equivalence class testing and boundary testing. While
learning how about equivalence testing, I found it helpful to see a practical
explanation from an industry-focused blog. The
article provides a clear explanation of how testers use equivalence
partitioning in real testing scenarios, which helped reinforce the theory we
learned in lectures.

One important
insight I gained from this article is how equivalence partitioning improves
efficiency in the testing process. Instead of creating hundreds of redundant
test cases, testers can focus on representative inputs that provide the same
coverage. This not only saves time but also helps teams focus on meaningful
test scenarios that are more likely to reveal errors. The
article also highlights that this technique works especially well when combined
with other methods such as boundary value testing, which focuses on testing the
limits of input ranges. Reading this article helped me better understand why
equivalence partitioning is widely used in professional software testing. When I
work with automated testing tools like Playwright and Vitest, I can see how
this approach can help create more effective automated test suites. In the
future, I expect to apply this technique when designing tests for input
validation, APIs, and user interfaces.

https://testgrid.io/blog/equivalence-partitioning-testing/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The article
“Comprehensive Guide to Equivalence Partitioning Testing” from TestGrid
explains an important software testing technique used to design efficient test
cases. Equivalence partitioning is a black-box testing method where input data
is divided into groups, or “partitions,” that are expected to behave the same
way in the system. Instead of testing every possible input value, testers can
choose one representative value from each partition to verify the system’s
behavior. This approach reduces the number of test cases while still
maintaining good test coverage. The article explains how the equivalence
partitioning is useful when the range of possible inputs is large and testing
every value would be wasting time. By grouping similar inputs together, testers
assume that if one value in the group works correctly, the rest of the values
in that group should behave the same way. For example, if a
form only accepts ages between 18 and 59, the test cases can be divided into
three partitions: valid ages (18–59), ages below the valid range, and ages
above the valid range. A tester can then choose representative values from each
group instead of testing every possible age.

I selected this
article because it directly relates to our course topics on software testing
techniques, particularly equivalence class testing and boundary testing. While
learning how about equivalence testing, I found it helpful to see a practical
explanation from an industry-focused blog. The
article provides a clear explanation of how testers use equivalence
partitioning in real testing scenarios, which helped reinforce the theory we
learned in lectures.

One important
insight I gained from this article is how equivalence partitioning improves
efficiency in the testing process. Instead of creating hundreds of redundant
test cases, testers can focus on representative inputs that provide the same
coverage. This not only saves time but also helps teams focus on meaningful
test scenarios that are more likely to reveal errors. The
article also highlights that this technique works especially well when combined
with other methods such as boundary value testing, which focuses on testing the
limits of input ranges. Reading this article helped me better understand why
equivalence partitioning is widely used in professional software testing. When I
work with automated testing tools like Playwright and Vitest, I can see how
this approach can help create more effective automated test suites. In the
future, I expect to apply this technique when designing tests for input
validation, APIs, and user interfaces.

https://testgrid.io/blog/equivalence-partitioning-testing/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The article
“Comprehensive Guide to Equivalence Partitioning Testing” from TestGrid
explains an important software testing technique used to design efficient test
cases. Equivalence partitioning is a black-box testing method where input data
is divided into groups, or “partitions,” that are expected to behave the same
way in the system. Instead of testing every possible input value, testers can
choose one representative value from each partition to verify the system’s
behavior. This approach reduces the number of test cases while still
maintaining good test coverage. The article explains how the equivalence
partitioning is useful when the range of possible inputs is large and testing
every value would be wasting time. By grouping similar inputs together, testers
assume that if one value in the group works correctly, the rest of the values
in that group should behave the same way. For example, if a
form only accepts ages between 18 and 59, the test cases can be divided into
three partitions: valid ages (18–59), ages below the valid range, and ages
above the valid range. A tester can then choose representative values from each
group instead of testing every possible age.

I selected this
article because it directly relates to our course topics on software testing
techniques, particularly equivalence class testing and boundary testing. While
learning how about equivalence testing, I found it helpful to see a practical
explanation from an industry-focused blog. The
article provides a clear explanation of how testers use equivalence
partitioning in real testing scenarios, which helped reinforce the theory we
learned in lectures.

One important
insight I gained from this article is how equivalence partitioning improves
efficiency in the testing process. Instead of creating hundreds of redundant
test cases, testers can focus on representative inputs that provide the same
coverage. This not only saves time but also helps teams focus on meaningful
test scenarios that are more likely to reveal errors. The
article also highlights that this technique works especially well when combined
with other methods such as boundary value testing, which focuses on testing the
limits of input ranges. Reading this article helped me better understand why
equivalence partitioning is widely used in professional software testing. When I
work with automated testing tools like Playwright and Vitest, I can see how
this approach can help create more effective automated test suites. In the
future, I expect to apply this technique when designing tests for input
validation, APIs, and user interfaces.

https://testgrid.io/blog/equivalence-partitioning-testing/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.