Joshua's Blog

Our final sprint is over, and the course itself will be wrapping up soon as well. Once this semester ends I will be a graduate. Scary. Anyways the sprint itself spanned a month like the other two, formally ending on the 30th of last month. Unlike the last one, this sprint wasn't cut short and lasted the whole month. The sprint had five goals, of which we completed four of them. Firstly, we needed to update our container with the latest dependencies, which would then allow us to carry out the rest of the goals. After that we moved onto what took by far the most time; we all independently drafted a series of tests , which we would then present to the group for us to decide on what was good or bad about each, with the plan of incorporating that knowledge into a 'methodology' for developing subsequent tests. Naturally that leads into our third sprint goal which was to fully write a comprehensive series of tests for the main page (and wherever it lead in the case of e2e tests....

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

 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. 

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

Hello! For this quarter’s blog I read a post written by Jeff Bridgforth, titled “ Think like a front-end developer. ” Coming to the end of the semester we have started working with the frontend, and I got the impression that it would be useful to see, as with my other blog posts, the insights someone who actually has experience working on it may have. As such, I wanted to find a blog that could give me an idea of the practical priorities and decision patterns used in real projects, this post does that well.  To quickly summarize, a front end developer is someone who designs what a user/client/etc. would actually see when they interact with a program. It encapsulates everything from the UI to how it interacts with the backend, or what goes on behind the scenes. Jeff outlines the basic mindset he believes front-end developers should have. He explains that the three main languages used for front end (html, css, and js) should be "partitioned" specifically for certain roles: html...

For this quarter's blog I read " The Day My Role-Based REST API Design Collapsed (and What I Learned) " by Sidharth Devaraj. The blog talks about REST APIs, specifically Sidharth's experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API "...is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server". Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and something I would like to see a human perspective on to gain insight about how I may utilize it in the future.  Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions ...

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled " Spaghetti Deconstructed: Lessons from my first refactoring ". As its name suggests, this blog talks about Yung's personal experiences and advice pertaining to refactoring. For those who don't know, refactoring is essentially improving existing code in a way that doesn't affect it's functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone's actual experiences with it, as everything we have been doing has been in a classroom setting.  Yung's blog recounts her experiences in refactoring some of her earliest code written when she was ...

 Hello! For my first real blog, I like to talk about an entirely different blog I read written by Fredrik Klingenberg, titled " UML Sequence Diagrams ". For one of my classes where we talk about software design processes, UML diagrams were something that was taught to us very early on, and I got the impression that they would be something I would see a lot of for the rest of my career. As such, I wanted to find a blog that could give me an idea of how they would be realistically applied, and after some digging I found this.  In the blog, he talks about not only what the diagrams are and how to construct them, but more importantly how to actually use them in a day-to-day basis. Firstly, if you are unfamiliar, a UML Diagram is a graphical tool used to visualize the structure and behavior of a software system. Think of it sort of as the visual equivalent of pseudocode, if you shifted the focus to more of an overview of the entire project. Visualizing the codebase in this manner ...

 Hello, this is nothing fancy, just a simple first blog required by my class