Joshua's Blog

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...

 For my first blog post, I read a blog written by Steven Cross, a professional software developer. The blog is titled 'The Curious Case of the Test Case", linked here: https://stevencrossblog.wordpress.com/2017/03/15/the-curious-case-of-the-test-case/ I chose this blog because it helped introduce me to a new but important aspect of software testing in how you actually go about "structuring" it.  In the blog, Steven talks about test cases, and how they are a very useful and important aspect of software testing. Test cases, as I understand, are documented procedures that ensure software behaves as expected under a set of pre-defined conditions. In other words, a set of steps laid out before the testing actually takes place. He talks about how these test cases provide a consistent structure that can be adhered to, and how this structure can be especially useful for new hires in their onboarding process, leading them to better understand how the software works. He also t...

  Hello, my name is Joshua Donovan. This is where I will be posting my blogs for WSU's CS-448 course.