Monthly Archives: February 2025

Apprenticeship Patterns

This reading presents an insightful perspective on software craftsmanship, emphasizing apprenticeship, perpetual learning, and skill mastery. The concept of learning through mentorship and practical experience, as illustrated in Dave’s story, was particularly interesting. It highlights the importance of hands-on work, exposure to real-world challenges, and the necessity of a growth mindset in becoming a great developer. The reading has influenced my perspective on professional growth. It reinforces the idea that mastering something comes from deliberate practice, seeking out mentors, and embracing failure as a learning opportunity. I believe this is what makes a good developer. One point I disagree is the romanticization of craftsmanship. While the focus on individual skill development is inspiring, modern software development requires collaboration with teams. Balancing skilled craftsmanship with effective teamwork is important. In chapter 2, I find the story of the Zen master and the young philosopher was provoking. It talks about the importance of maintaining a beginner’s mindset, or “emptying your cup,” to fully absorb new knowledge. I think this is important in apprenticeship. The idea that experience can sometimes be a barrier to learning is interesting and that applies to many fields, including software development.

Dave’s realization that true mastery comes not from credentials but from continuous learning and engagement with a community of experts is highly relevant. The story also highlights the importance of humility in learning. Even the most skilled developers acknowledge that they are still learning, which serves as both an inspiration and a challenge to those just starting out. The idea that learning is a lifelong journey rather than a destination is a valuable takeaway. I resonate a lot with this point because I often feel like this is a lifelong journey of continuously learning and adapting to new technologies. In terms of how I work, the idea that certifications and formal training are only steppingstones, not the final proof of competence is true. I’ve learnt that while training can provide foundational knowledge, real expertise comes from practice, engagement with peers, and continuous learning. One thing that I found interesting was the analogy of “the big fish in a small pond”. It is a powerful way to describe the risk of complacency for those who learn quickly. It’s a reminder that achieving success in a limited environment may feel rewarding, but true growth comes from recognizing the wideness of the field and challenging yourself to bigger things. I’ve learnt that it’s important to stay challenged and continuously learn. It’s easy to become comfortable in an environment where your highly competent, but it’s important to seek out mentors that can further challenge you to be even better than you already are.

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

The Key Pillars of API Testing

Application Program Interfaces (APIs) provide the framework for how pieces of software communicate with each other, as well as the user. Therefore, proper API testing is key in delivering a reliable product. In a blog for Medium.com, Andrey Enin says that around 3/4 of product functionality involves designing the API correctly. He also lists some of what he considers to be the core ideology behind how these tests are designed and conducted.

Firstly, an API, or any program, must be tested to ensure it works properly. Functionality testing involves sending requests to the API and comparing the results with the intended specifications. End-to-end tests are useful in this case; multiple calls are chained together, often across multiple APIs, to replicate the end user experience in order to bring bugs to the surface.

Performance testing is another point. Measuring how the software and API perform in high use cases or under high traffic loads improves stability by identifying issues in a controlled environment. That is, better to break it now, rather than after delivering the product. Compatibility testing falls under a similar umbrella. Differing and often “unexpected” requests are sent to the API to test how the program responds. While performance testing can involve stress-testing and compatibility testing often involves testing the API in different environments, the philosophy is the same: better for it to break now, when fixes are easier to implement as opposed to post-release.

In a similar thread is error testing. Quality software will be able to handle errors without suffering catastrophic failure. With API testing, this generally comprises of sending intentionally incorrect or malformed requests to ensure the interface returns the relevant error responses.

Testing the usability of the API is somewhat different, in that it refers to the developer experience when working with the interface. Some of the examples listed in the aforementioned Medium.com post include adhering to OpenAPI specifications, uniform naming conventions, and making sure documentation is comprehensive and unambiguous. The unique perspective of focusing on the end user experience helps create developer-friendly interfaces that are popular and remain relevant in the industry.

Finally, security testing involves checking to make sure the API carries data securely and is protected from unauthorized or malicious use. Transmitting data over HTTPS is a common method of protecting sensitive information, and is generally considered standard for most web traffic. Testing the interface’s authentication methods for vulnerabilities protects against outside access to the same sensitive information as well as preventing unauthorized use of the interface.

As a final note, it’s helpful to consider these testing approaches as a foundation for a standard of quality assurance, as opposed to a check list to follow. Specific tests may address multiple different parts, and different approaches may take importance over others. Considering each different aspect of API testing over the course of the development cycle, outside of the testing environment, helps ensure the quality of the final product.

References:

Enin, Andrey. “Field Notes in API Testing, Part 1: Areas of Focus.” Medium.Com, Medium, 25 Jan. 2025, adequatica.medium.com/field-notes-in-api-testing-part-1-areas-of-focus-46b516ccacf4#4439.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Unit Testing: Decision Tables

Week 5 – 2/23/2025

For this week’s blog, I recently came across an insightful article titled “Decision Table Testing: A Comprehensive Guide” on the Testsigma website. This article provided a detailed overview of decision table testing, a technique for testing system behavior for various input combinations. The article not only defined the concept but also went over its applicability, benefits, and practical applications.

I chose this resource because we had just done a POGIL activity on decision table testing in class, and I wanted to learn more about how it works in real-world circumstances. The article stood out to me because it was well organized, simple to understand, and contained practical examples to make the subject more approachable. As someone who is still learning about software testing, I found this material to be both instructive and accessible.

The article begins by defining decision table testing as a black-box testing technique for determining how a system responds to different input combinations. It then describes the structure of a decision table, which is made up of conditions (inputs) and actions (outputs), as well as how to generate one. What I found most useful was the step-by-step illustration of how to apply decision table testing to a login system. This example helped me visualize how the strategy works in practice.

One of the most important takeaways for me was the emphasis on the value of decision table testing in dealing with complex business logic. The article explained how this technique assures that all conceivable scenarios are examined, lowering the likelihood of missing key edge cases. This spoke to me because, in my limited experience, I’ve seen how easy it is to overlook specific input combinations, particularly in systems with several decision points. The blog also covered decision table testing’s limits, such as its inefficiency for systems with a large number of inputs, which helped me understand when to utilize this technique and when to look into alternatives.

Reading this article has greatly increased my understanding of decision table testing. I’m now more confident in my ability to apply this strategy to future projects. For example, I envision myself utilizing decision tables to evaluate systems with well-defined criteria, such as payment processing or eligibility verification. In addition, the blog emphasized the need for thorough testing and considering all possible circumstances, which I will include in my testing methods.

Overall, this article was a helpful resource for my learning experience. It not only simplified a subject that I was having trouble understanding, but it also provided practical insights that I may use in the future. This article is highly recommended to anyone looking for a clear and practical explanation of decision table testing.

https://testsigma.com/blog/decision-table-testing/

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

Week 5: 4 THINGS YOU SHOULD KNOW ABOUT GIT AND GITHUB

Are you one of those people who occasionally find using GitHub a bit of a headache?

I get it. At first glance, GitHub can seem intimidating—so many branches, pull requests, merges, conflicts… it’s easy to feel lost.

I’ve been there too. I often wondered whether I was following best practices or just making things messier for the team with every commit I pushed.

The good news is, it doesn’t have to be that way. With the right approach and a few key tips, GitHub can seamlessly integrate into your development workflow.

Whether you’re a complete beginner or someone overwhelmed by its countless features, GitHub is here for you.

WHY SHOULD YOU CARE ABOUT GITHUB?

GitHub is more than just a fancy cloud storage for code—it’s where the magic of collaboration happens.

It allows you to implement version control in the most efficient way possible, something every developer needs when working with a team to avoid stepping on each other’s toes. Mastering GitHub will make your life easier, whether you work solo or in a group.

BASIC WORKFLOW

Let’s go through a simple GitHub workflow. This assumes you have a basic understanding of Git, so we’ll focus on GitHub as a collaboration hub.

CREATING A NEW REPOSITORY

Go to your GitHub dashboard and click the “New Repository” button. Give it a cool name—maybe “super-cool-project” or something more professional if you’re working in a team.

CLONING TO YOUR LOCAL MACHINE

Now, clone this new repository to your local computer.

(Illustration: “GitHub Repo Clone”)

BRANCHING OUT

This is where many beginners struggle: branching. If you’re developing a new feature, always create a new branch from main (or master, depending on your default setup).

(Illustration: “Branching Out”)

MAKING CHANGES

Go ahead and do what you need—write great code, add some files, maybe fix a few bugs along the way.

COMMITTING AND PUSHING

Once you’re happy with the changes, stage them and commit. Remember the golden rule: write meaningful commit messages. Avoid vague messages like “fix stuff” or “final version control.”

(Illustration: “Commit and Push”)

CREATING A PULL REQUEST (PR)

After pushing your branch, it’s time to create a pull request on GitHub. This is a crucial step. PRs allow others to review your code, provide feedback, and discuss potential changes.

Go to your repository on GitHub, and you’ll see a big button that says something like “Compare & Pull Request.”

Click it, add a meaningful title, and write a clear description. Be specific—let your teammates know what you changed and why.

MERGING THE PULL REQUEST

Once your team has reviewed your code and you’ve addressed their feedback, merge the PR into the main branch. Voilà!

You’ve just successfully collaborated like a pro.

HANDLING MERGE CONFLICTS LIKE A “BOSS”

Merge conflicts are inevitable, but don’t let them stress you out. If two people edit the same part of a file, Git won’t know which version to keep. That’s where you come in.

When Git notifies you of a conflict, it will mark the conflicting parts in the file. You’ll see something like this:

(Illustration: “Handling Merge Conflicts”)

Simply decide which code to keep, or merge both in a logical way, save the file, and commit again. That’s it!

GITHUB ACTIONS: AUTOMATE YOUR WORKFLOW

Another game-changing feature on GitHub is GitHub Actions. Why waste time manually running tests, building code, or deploying updates when GitHub can do it for you?

Actions allow you to automate almost anything in your workflow.

For example, you can set up GitHub Actions to automatically run tests every time a pull request is created, ensuring no buggy code gets merged. You can even set up continuous deployment to push changes to production once they pass all tests.

Here’s a basic setup for an action that runs tests on your code:

(Illustration: “GitHub Actions”)

This means that every time you push to main, GitHub will run tests for you—like a little assistant reminding you, “Hey, let me check if everything’s still good to go.”

FINAL THOUGHTS

GitHub is your best friend in the world of version control and collaboration. With features like branching, pull requests, and GitHub Actions, it provides everything you need to work effectively with others—or even just by yourself.

It’s not as scary as it seems. Stick to good practices, keep things organized, and soon, you’ll be committing, merging, and collaborating like a seasoned developer.

Key takeaways:

Use meaningful branch names and commit messages.
Don’t fear pull requests—they’re your safety net.
Handle merge conflicts with confidence, not panic.
Automate testing with GitHub Actions to save time.

And remember: no matter how great GitHub is, it’s the people using it that create the real magic.

Have a good day!

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

On Integrating Automated Testing

In this post, I’ll be discussing my thoughts on a recent article I read from the Software Testing Help website, which can be found here. The piece really struck me because it reinforced many of the ideas I’ve come to believe about the role of testing in the software development lifecycle, particularly how automation can improve both speed and quality. I’ve always been a fan of automated testing, but this article helped me think more deeply about how it should fit into the broader testing strategy.

One of the key points in the article was the idea of balancing automation with manual testing. While automation is critical for repetitive tasks and quick feedback, the author pointed out that certain aspects of testing—like user experience—cannot be fully captured by automated scripts. This really resonated with me, as I’ve encountered situations where automation was great for catching functional issues, but it missed some of the nuance that a manual tester might be able to identify or spot. I think it’s a reminder that we should never rely too heavily on automation, and that human insight still has an important role to play.

In my own experience, automated testing has been a huge time-saver, especially for regression testing. It helps ensure that previously working functionality remains intact as new features are added. But I’ve also seen the limitations, particularly when automated tests don’t cover edge cases or fail to reflect real-world scenarios. I’ve learned that a good testing strategy needs to integrate both approaches—automation for efficiency and manual testing for critical thinking and creativity. I’ve gotten in the habit of mentally doing a once over to make sure that all my automated tests still cover everything I can think of, instead of just blindly assuming they do.

The article also emphasized the importance of writing testable code to support automation. This is something I think I can improve on in my own work. By considering testability from the start, we can avoid technical debt and create more maintainable, reliable systems. Writing code with testing in mind encourages good design practices and ensures that automated tests are effective.

Lastly, the article touched on continuous integration (CI) and how automated tests play a vital role in CI pipelines. This is something I’ve been trying to implement more consistently, and I’m seeing the value of catching bugs early, before they make it to production. It’s a mindset of constant improvement that aligns well with the idea of being a “Software Apprentice”—always refining and enhancing our process.

In conclusion, this article reaffirmed the importance of finding the right balance between automated and manual testing. As I continue my journey as a developer, I’ll be more mindful of how I integrate both into my workflow to ensure quality and efficiency.