By Daniel Parker

When I say quality testing many software developers and others in the computer science field may think I am referring to testing the quality of software. While in many instances this may be the case, here I would like to point out the importance of quality testing; or creating tests with a high level of quality to ensure working software.

Before delving into why it’s so important it might be beneficial to highlight just how disastrous dysfunctional code can be. According to Harry Ngyuen in his blog “Top 8 Reason Why Software Testing Is Important In 2025“, fixing a bug that has made it the maintenance phase can cost 10 times more to fix than it does during the design phase.

As he also mentions many customers expect fast and high-quality applications and if these expectations are not met many customers may switch their provider. As well as customer satisfaction many risks can come with buggy software creating security hazards.

Clearly having buggy code that was haphazardly tested is incredibly detrimental to any software being released by a single developer or even an entire organization. So how do we ensure this doesn’t happen?

There is a magnitude of ways to test code, and I don’t think listing them out will help with our cause as there is no best way. To ensure high quality software you mut write high quality tests.

Your tests have to be able to accurately track the flow of your program, be able to highlight where something failed and why it failed, and ensure all boundaries are tested and a successful output is what you’re left with. This means writing as many tests as needed, whether its five or fifty. It means writing tests that check whether your application can handle anything thrown at it. Testing can take time and effort but it’s much better to spend that time while writing your code and handling the bugs one at a time than to have to deal with many after a release has occured.

I plan on continuing down the road of software development both in my student career and my professional career. With this in mind, I will ensure I apply my quality testing skills to produce the highest quality software I can.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

When coding there are a lot of factors to consider, the time complexity of your algorithms, the space complexity as well, and even power efficiency can all affect the decisions you make and the flow of your program. It’s a complicated task and with constant distractions in our ever-growing busier and busier lives the need to make the coding process as quick and easy as possible is constantly present (of course it almost never is quick and easy).

One way that we can optimize our time effectiveness is clean code. What is clean code? As Thiraphat Phutson puts it in his blog, “The Art of Clean Code: Writing Code that Lasts“, it’s code that’s easy to understand, maintain, and extend.

There are plenty of aspects to writing clean code such as using good naming schemes for variables and functions, proper spacing, consistent indentation and bracket use, the list goes on and on. And just like there’s many aspects of clean code there’s plenty more attributed to “messy” coding.

So how does clean code apply to me? As a major in computer science the ability to code is almost the entire point of my degree. Learning how to keep my code clean and organized, making it easier for myself to understand if I ever need to come back to it as well as fellow team members and coworkers is incredibly important.

As I’ve mentioned my honors project in my past few posts, I’ll mention it again here. Although as I’m writing this my project has been submitted and is officially done in terms of what my professor will see for now, I’m not done with it. In fact, I’ve barely begun. Most of my honors project was geared around performing my own sprint for a product I’ve chosen to create. In the first sprint I completed almost no coding got done, most of it was setting up to be able to start programming the project.

This is where I can take the clean code skills I’ve acquired, and make sure that as I’m coding what I can only imagine is going to be a very complex project I’m keeping it organized and efficient. As Phutson mentions, clean code allows for maintainability, scalability, and efficiency, all things I’ll need for my project. He also mentions collaboration which is another fantastic aspect of writing clean code, but it doesn’t apply as much to my case with me being the only developer.

Clean code is an incredibly important skill to have in the computer science world and I’m grateful to have had not only an introduction to it but some practice with it as well. I will be sure to keep it ever-present in my mind as I code not just my current project but any project in the future.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

A sprint retrospective is an event that occurs at the end of a sprint where the team meets to discuss improvement for the next sprint. This is to say, the team gets together and looks back at the sprint completed and looks for areas of improvement that they can adjust for the next sprint.

Following the theme of my last few blog posts, I will be manning a one-man scrum team (which is an odd sentence). How exactly will a sprint retrospective look for me and by extension how would it look for someone following a similar journey through scrum?

A great place to start is knowing what’re the right questions to ask, thankfully Rodrigo Ribeiro has provided us with these questions is his blog, “How to Run a Sprint Retrospective 101: The Essential Guide”. Now, this blog was written with an entire scrum team in mind so let’s take a look at the four major questions he poses for a retrospective and look at them in our scenario.

“What did you like in the sprint?”

This is a simple question, but it may have more significance to our situation than you would think. As Ribeiro notes this section is mainly for giving credit where credit is due to your team members and making sure to thank them for their efforts. Well for us we are our team members, but that doesn’t mean we don’t deserve credit or appreciation for our effort. Taking a moment to pat yourself on the back for completing your sprint and telling yourself you did a good job can really improve your attitude and confidence when looking towards the next sprint.

“What is puzzling you right now?”

This question is an opportunity for your team to ask for clarification about roles in the team, as well as technical and functional purposes. For us, roles are not relevant as we are assigned all of them. As for technical and functional purposes, as the product owner we already know what the purpose of our product is, both technical and functional as we’ve designed the backlog. With this being said, maybe this question is better omitted from out one person retrospective.

“What didn’t work so well?”

This is the time for the team to express their feelings about the project. In our instance, this is the perfect opportunity to be fully honest with ourselves about our current feelings towards the project as well as our feelings about that last sprint. Were there issues with backlog items? Did we move the project towards completion in the same direction we set out product goal? These are very important questions to ask ourselves and to be fully honest about as we’re the only input.

“What are your improvement ideas?”

This is the section where you, of course, should ask your team for solutions to issues you’ve been having as well as general ideas for project improvement. So how does this relate to us? After the end of our previous sprint, with certain backlog items finished and maybe even some scrapped, some adjusted, and some still alluding a solution, we can take a minute to reassess our current situation and decide our next steps. Were some of the completed backlog items not completed to our standard, or in the direction we wanted to move our project? Are some backlog items unable to be completed now irrelevant or should a new way of looking at them be implemented. Without the input of others during a sprint it can be hard not to be one track minded and tunnel visioned so this is a great opportunity to take a breather, relax, and try to search for a new angle. Maybe write down some solutions, think them through, and try again with new tasks and backlog items for the next sprint.

It’s important as a one-man scrum team to be incredibly flexible, and getting held up on one backlog item can really stagnate progress and burn out a single developer. Asking these questions in the middle of the sprint will only lead to complicating something that’s already complicated navigating as one person. It’s better to do what you can during the sprint and assess and reevaluate with yourself after. From there you can make changes and move forward in the direction of your choosing.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

As a one-man Scrum team, a lot of the framework provided with Scrum and Agile can be hard to apply. For example, how do I define a sprint goal for my team when I am the team, or how do I determine how much work the team is capable of when again, I’m the team.

Shouldn’t being a single person scrum team make these easier to accomplish? I mean it would stand to reason yes as I don’t have to confer with others on a sprint goal and who better to know my own capabilities than myself. The issues arise in a few places.

The most important being, as someone who is new to scrum how will I know I’m setting a realistic or achievable sprint goal. How will I know I’ve chosen the right goal for that given part of development?

Another given issue is with being the one who sets the goal and the timeframe who’s going to keep my honest and working as hard as I can without burning out? I can push myself incredibly hard and burn out after one sprint or I could accomplish almost nothing because I just didn’t feel like it and didn’t have to answer to anyone.

Thankfully, the first issue can be solved by researching sprint planning. In “Creating a Sprint Backlog: Your Guide To Scrum Project Management” by Dana Brown, she details how to create a sprint goal, how to create a sprint backlog, and how to prioritize tasks.

She highlights the first two steps of sprint planning as setting a sprint goal and identifying important product backlog items. Thankfully this is where my first issue is solved. As someone inexperienced to scrum, I would start at step two which is identifying the important product backlog items and using those to create a sprint goal. This way my sprint goal is relevant and knocks off the items highest on the priority list.

From there I can breakdown my product backlog items into smaller tasks and add them to the spring backlog. Finally organizing these tasks based of their priority and prerequisite tasks.

So, my first issue has been resolved, I now have a method of creating a sprint goal relevant to what’s highest priority. As for my second issue, unfortunately I don’t think I’m going to find an answer to that one online. It’s going to be trial and error as well as being completely honest with myself on whether the workload is too much or too little. Ultimately, it’s going to come down to how disciplined I can be.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

With an honors project coming up for one of my courses I was going to have to learn how to become a single person Scrum team. With the average scrum team being seven to ten people, I knew it was going to be both a strange and difficult task.

I knew my first order of business would be to create a product backlog as I am the product owner (among many other things being the only member of the team). Diving in headfirst, I knew what a product backlog was but not how to set up an effective one.

Thankfully, “A guide on Scrum product backlog” by Brianna Hansen was the perfect blog to stumble across. She eloquently states what a product backlog is, why one should be maintained throughout a project, and how to create a product backlog geared towards success. As an added bonus the end of the blog even provides a platform to create and maintain a product backlog.

As I previously stated, I’ve known what a product backlog is. It’s everything that needs to be done for a product, including maintaining it. As much as a product backlog is a to-do list, one way to increase success is to not overload it. Keep it simple but effective. No one on the Scrum team (in this case me) wants to scroll through a product backlog for hours.

Time management is crucial for a product backlog. Certain items contained in the backlog are going to be more time consuming than others so considering this when putting product backlog items into the sprint backlog is very important to sprint success.

Defining the product vision is one of the major points she gives for maintaining a successful product backlog. This usually involves the whole team getting involved to make sure the vision for the product is shared. While in my case I may be the only member Hansen does give some very important questions for me to ask myself when planning my product and adding items to the backlog.

• “What problem does the product solve?”
• “Who are the target users or customers?”
• “What unique value does the product offer?”

Taking these questions into consideration will help to guide me through this project and help to increase my chances of success.

Finding this blog was incredibly helpful for taking my first steps into trying Scrum firsthand and I intend to use what I learned as I navigate my honors project.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.