Vish's Journey in Computer Science

In my self-directed professional development this week, I explored the topic of Boundary Value Analysis (BVA) in software testing. We have discussed this topic under the tutelage of Professor Perez recently. The article I selected is titled “Boundary Value Analysis” from the QAble testing blog. The resource explains how testers can design effective test cases by focusing on input values that occur at the boundaries of acceptable ranges. The article can be accessed here:
https://www.qable.io/blog/boundary-value-analysis

The main idea presented in the article is that many software defects occur not in the middle of valid input ranges but at the extreme boundaries of those ranges. Boundary Value Analysis is therefore a testing technique that concentrates on validating the minimum, maximum, and values just inside and outside the boundaries of input constraints. For example, if a system accepts numbers between 1 and 100, the key test cases should include values like 0, 1, 2, 99, 100, and 101. By testing these edge cases, software testers can identify logical errors or validation mistakes that might otherwise remain undetected.

I selected this particular resource because boundary testing is a fundamental concept in Software Quality Assurance, which is directly related to the course material. As someone studying computer science with a focus on software engineering, understanding systematic testing strategies is important for writing reliable and robust software. I wanted to better understand how professional testers design test cases efficiently instead of randomly trying input values.

One thing that stood out to me while reading the article is how small variations near boundaries can expose serious system defects. For example, input validation errors might allow illegal values or incorrectly reject valid ones. This made me realize that testing is not just about checking whether software works in normal conditions, but also about identifying edge cases where systems may fail. The article also emphasized that Boundary Value Analysis is often used together with Equivalence Partitioning, which further improves the efficiency of test design. This connection helped me understand how multiple testing techniques can complement each other.

Reflecting on this resource, I learned that effective testing requires both analytical thinking and structured methodologies. In many of my programming assignments, I usually test my programs with a few normal inputs just to confirm that the program runs correctly. However, after reading this article, I realized that I should also intentionally test boundary conditions. For example, when designing programs that accept user input such as age ranges, scores, or array sizes, I should verify the smallest allowed value, the largest allowed value, and values just outside those limits.

In my future software development practice, I expect to apply Boundary Value Analysis when writing unit tests and validation logic. As a future software engineer, I believe this technique will help me produce more reliable software systems and reduce unexpected runtime errors. Overall, this article reinforced the importance of structured test design in improving software quality.

While going through different resources on API Development, I came across a blog post from Stoplight titled “API Design Patterns for REST Web Services.” Stoplight Blog – API Design Patterns for REST Web Services. I decided to write about this one because it connects directly with what we’ve been discussing in class about Design Patterns for REST API’s under the aegis of Professor Wurst. I’ve always wanted to understand how professional developers make APIs that are easy to use and extend, and this article gave me a clearer picture of what good API design actually looks like.

The post starts by explaining that REST APIs are not just about connecting endpoints — they’re about defining patterns that make services predictable and consistent. It discusses important ideas such as resource-based design, the use of HTTP methods for specific actions (like GET, POST, PUT, DELETE), and how to organize URIs in a way that feels natural to users. It also highlights how consistent naming conventions and status codes can make APIs more reliable for anyone consuming them. One interesting point the author makes is that designing an API is a lot like designing a user interface, except the “user” is another program.

I chose this blog because it goes beyond the basics of how to make an API work and instead focuses on how to make one well-designed. The examples were simple but realistic, and the explanations didn’t feel overly academic or abstract. I could see how these design decisions connect with what we’ve learned about modularity, abstraction, and communication protocols in software process management.

Reading this made me realize that design patterns in REST APIs are as important as design patterns in object-oriented programming. They both aim to make software easier to understand and maintain. For example, I learned about the “collection pattern,” where a resource like /users represents a group of items, and /users/{id} represents an individual. This pattern keeps the structure clean and predictable. I also learned how misuse of HTTP verbs (like using POST for everything) can make an API confusing or harder to scale later.

Personally, this article helped me connect classroom theory with real-world engineering practice. It changed how I think about building web systems — not just as code that works, but as something other people will depend on. In my future projects, especially my capstone work and the “Investment Wisdom” app I’m building, I plan to use these principles when designing backend endpoints. I’ll pay attention to consistent URIs, proper status codes, and resource naming so that my APIs feel professional and well-structured.

Overall, this blog was a great reminder that clarity and consistency matter as much as functionality. It showed me that designing a REST API is an act of communication — between developers, systems, and even future maintainers.