Joshua's Blog

 The semester is less than two weeks from being over now, for our final blog I chose the post “ Testing is not always Black & White ” by Renée Elizabeth Mineart. It has a lot of good insight about one of our course topics that I find interesting, white-box and black-box testing. The post argues that the difference between the two is not always as strict as it is often made out to be. Instead of treating them like completely separate categories, the author explains that testing often exists in a kind of gray area where both perspectives can overlap. That idea stood out to me because it makes testing feel more realistic than the simple definitions we usually start with. I selected this piece because it gives a practical view of the topic we are working with in our team's group for our final assignment, where we are making our own in-class activity based off of a topic of our choice (in this case Black-Box vs White-Box testing). We only briefly touched on this in class, so this bl...

The semester is quickly coming to an end, and so for my third blog post, I read " Black Box vs White Box Testing - What's the Difference? ", written by Faith Quinn. As the title suggests, it touches on one of the course topics (in this case one that we have been over already, unlike my previous blogs): Specification-Based vs Code-Based Testing, otherwise known as Black Box vs White Box Testing. To quickly summarize what exactly that is; black box testing is when you focus on the expected behavior of the software without looking at the code itself, while white box testing is when you use knowledge of the internal code structure to design tests. Quinn’s post explains the difference between the two approaches, and also shows that both can be useful depending on what kind of problem you are trying to find. This made the post a good fit for the class because it connects directly to one of the main testing ideas we discussed during the semester. I chose this particular resource...

We are nearing the end of the semester, and with that have completed our second sprint. It has formally spanned from the 5th of March to the 7th of April, a week shorter than was initially planned due to what I believe were time constraints. Our sprint consisted of four goals, and of those goals we were able to complete two. The sprint was largely divided into two "parts". The first part is what we actually completed; the "prep-work". This involved the necessary preparations our team needed to start test development, which consisted of creating a new branch dedicated to frontend-testing (our team), and building a new container that had the necessary testing tools needed for our tests. These necessary tools were Playwright and Vitest.  The second part, and the part we did not finish, was themed around the actual test development. This involved all of us independently writing draft-tests , to help us formalize a methodology we could follow, as a group, when writing ...

The semester is about halfway over now, and for my second blog I chose the blog post “ Test Automation – The Bitter Truth ” by Mr Slavchev . It has a lot of good insight about one of our course topics I find interesting, test automation. The post argues that what teams call “test automation” is usually automated checking, not true testing. The author explains that automated scripts only execute predefined checks, lack human judgment, and bring their own maintenance costs and bugs. The post stresses that automation is a tool that supports testers, not a replacement for critical, exploratory human testing. Importantly, he also makes an important clarification, automated testing isn't entirely automated. In reality, it is more like tool assisted testing. Quoting the blog post directly, Slachev says " we use tools to assist our testing , that’s it, we don’t want to replace it, or get rid of it ". As someone new to software testing, yet working with it for my capstone project...

The first sprint for my software development capstone has concluded. It's served as a good way for me to start immersing myself in the "real world", in other words having a way to practically apply what I have been learning throughout the second half of my CS undergrad. Up until now I have done virtually all of my coding projects alone, this class (besides my research team) is the first time I have had to consistently work with a group of people on a project of any kind for more than a week or so (basically, more than a single assignment). To quickly recap what every student in my capstone is collectively working on (I'm not actually sure if I explained this in my introduction blog post), we are working on the software for a food pantry. We are in charge of developing every aspect of it, from frontend elements like the UI, to the back-end processes. In particular, my team is in charge of front-end testing. We, over the semester, will be developing tests to verify the ...

 My software dev capstone is a few weeks in, and I have been tasked with reading a textbook titled 'Apprenticeship Patterns', written by Dave Hoover. The book reframes software development in an interesting way; it structures it as a craft, with the necessary skills developed through an apprenticeship as if it were a conventional trade. The apprentice has a master they work under, who acts as a goal to work towards, with the intention of becoming one themselves. Importantly, it presents this not necessarily as a rigid structure or protocol to follow, but more-so a mindset to inform your decisions. Instead of seeking out a specific track to follow, it suggests you try to turn your day-to-day operations as opportunities to learn, by seeking feedback or mentorship. In other words, it encourages you to actively look for improvement.  I haven't read the entire book, so far I have only read the first chapter and the introductions of a few subsequent chapters, but it is pretty int...