Category Archives: CS-348

Types of Software Testing: Ensuring Quality in Development

Within the Software Development Lifecycle, it has a major step that takes a decent amount to do is Software testing. The purpose of software testing is that the program has no problems and meets the requirements set by the customer. Software development is divided into two different types: verification and validation. As noted before, verification is a step that has programmers checking if the software is doing as the customer intended. In the same vein, the validation step is just programmers testing if the software meets the customer’s requirements. For example a website wants to add a new feature to handle an increase of daily users on the platform. 

Moving on, there are multiple different types of testing programmers use to validate and verify if the program is working as intended. There is automation testing, and manual testing. They then divide into smaller more specific tests that will focus on certain aspects of the program. As mentioned earlier, automation testing is when programmers write test scripts with or without software and can run the tests repeatedly. While manual testing is a method of testing that has a programmer write tests that will check on different sections of the program.

Within software testing there are different levels of testing. They are called unit testing, integration testing, system testing, acceptance testing. 

Unit Testing

  • It is a testing that checks every component or software 
  • It is to make sure the hardware or software that could be used by the programmers 

Integration Testing 

  • It checks two or more modules which are tested are then put in the program or hardware 
  • To make sure the components and interface are working as intended

System Testing

  • Is a test that verifies the software itself 
  • Also it checks the system elements 
  • If the program meets the requirements of the system 

Acceptance Testing  

  • Validates if the program meets the customer’s expectation 
  • If the customer can work correctly on a user’s device 

These different types of testing are used to prevent issues down the line. So that programmers can find potential bugs, improve quality of the program, improve user experience, testing for scalability, also to save time and money. In order to save money and time because it takes a lot of employees to solve problems with a program that could have been used to make a new product. A business wants a program to work and be improved over time.

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

Scrum On

Software Development Methods

Wow, look at us, huh? Almost a month later, another post appears! This month (I guess I’ve moved to monthly blogging… We’ll tighten it up, I promise) has been mostly about the different ways to go about developing something. Neat, huh?

So far, we’ve talked about waterfall, agile, and the latest, scrum!

SCRUM

Scrum builds upon each previous development methodology, and is a natural extension of Agile. It is not, however, ‘better’ than agile, but simply different. No one methodology is the best, but some perform better than other in certain circumstances. Scrum is the latest methodology that my class has been learning about, and as such I decided to take some time to further look into it.

Scrum in 20 minutes is a video I came upon while looking for examples. It explains the process of scrum, why it is used, and how it is different to other methodologies. As well as this, the video contains a few examples of how using scrum has been beneficial.

One of the reasons that I decided to watch this video was that it simply looked professional. It was well polished, and felt like a finished product. A lot of the times, when I go looking for academic supplemental material, I’m presented with a sea of the same animated characters, slideshows, and whiteboard-style videos, so this one was a VERY nice change of pace. More of these, please! (I have some words with whoever invented PowToon).

This video really helped me to see how Scrum is applied to a real life example. I also appreciated the refresher on the process as a whole, but having real-life examples of a full sprint, planning, and what each of the team members’ roles contribute was really helpful in better understanding Scrum as a whole.

Something that I realized while watching the video, was that Scrum does not have to be software development specific. I play a lot of optimization games, and something like scrum just feels extremely organized, and is something that I feel is worth applying, at least in terms of concept, to more of my life than just this one small facet. Organization and goal setting is important in almost everything we do, and Scrum is just one way to do that, but it has been refined over multiple years of trial and error.

I am excited to apply scrum to future projects, and look forward to the increased organization that a solid planning methodology will bring to the table.

This concludes my mandatory blog post of Quarter 2 for the semester.

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Understanding RESTful API design principles – Upsun Blog

This quarter I decided to read “Understanding RESTful API design principles” by the Upsun blog, which talks about many aspects of RESTful API. I picked this because it directly relates to what we’ve been learning recently in class, and relates to a system I will have to work with next semester for my Capstone. I figured it would be a good idea to get more familiar with REST API early.

The article starts off explaining what REST (REpresentational State Transfer) actually is. It’s a “set of architectural principles that define how to design and implement these interfaces”, discussing the HTTP methods involved. Being the only API design principle I know of, I had no frame of reference for its advantages compared to other options, but the article provides a chart and compares RESTful to GraphQL (good for more efficient and specific data fetching) and gRPC (Good for microservices and streaming).

The RESTful architecture typically contains a Client, Server, and Database, but it can include additional elements such as a load balancer or a cache. The Client, Server, and Database are fairly straightforward, being the consumer, the server hosting and processing the requests, and the database to store the data. The load balancer is also intuitive to it’s name, but for the smaller scale system like the Food Pantry which is unlikely to experience a large server load at any time anyway, it’s probably unnecessary.

The article goes into 6 design principles of REST APIs. The first one, Client-server architecture, states that the client and server should operate independently to make long-term maintainability better. The second is Stateless communication, stating that each request from the client should contain all the information needed to process the request. Nothing is stored on the server, so that each request is self-contained and can be handled independently, simplifying the process. The third is Cacheable Responses. If an API response is cacheable, it should include caching headers such as “Cache Control” or “Expires”, so that the data can actually be cached and the server doesn’t need to be queried every time. The fourth principle is Layered System. In many ways this seems similar to the principle of Abstraction, where the API should operate across multiple layers without the client being aware of the layers, reducing complexity and making it so the client doesn’t have to interact directly with multiple backend servers. The fifth is Uniform Interface, stating that the way resources are interacted with (ie. HTTP Methods, URL patterns, etc.) should be standardized and uniform. The last one is Code on Demand, which the article states as optional. It states that servers can use executable code such as Javascript to extend functionality.

Many of these principles were fairly intuitive, but it’s good to have them explicitly stated anyway. Some were also directly connected to our class discussions. Things like caching and the executable code stuff are things we didn’t talk about, but I’ll keep them in mind as we do more with REST API.

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

Why Software Maintenance Matters for Business Success

Recently AWS servers were not working due to something causing one third of the internet to go down. It made me start to think about what maintenance companies like Amazon have to have in order to make sure clients’ websites or programs do not get shut down. Then I found an article about Software maintenance explaining in a software engineer’s perspective on what happens with a product already made but has to be maintained. 

It starts to explain that software maintenance branches between bug fixes, adding new features, adding new hardware or software environments. At the end of the day the software has to work, be secure, efficient, and meet the users demands. As mentioned earlier there are multiple different types of software maintenance: bug fixes, patches, adaptive maintenance, optimizations, preventive maintenance. 

As programs get used or the amount of users start to increase companies have to consider that users might face bugs. These bugs can affect user experiences that might cause the company to lose a potential sale and even get bad reviews. These bugs can range from small coding errors or errors that might affect the user experience. 

In the future there is always the risk of needing to add patches to fix something very quickly. For example many companies would get hacked and have to undo the damage hackers might do to their program. Even though it could be an extreme case like getting hacked it could be a major update to the software that might be needed. 

Moving on to Adaptive Maintenance, it is about whether customers might want a new feature added to the software. Which could even change involving the environment, hardware, business wants, or new regulations that apply to the company. For example in the past the U.S government added a law to ensure the privacy of online users to prevent websites collecting data on users without consent.

Another type of maintenance is Perfective maintenance but to me I consider it optimizations. This can be either the consistency of the performance of a program and reliability. In addition, to make the software be flexible when adding new features or changes to it. 

The last type of Maintenance is Preventive maintenance. These could be features that make the program to be more secure, frequently tested, constant documents being made, and backups. This type of maintenance is to make sure potential problems can be fixed as quickly as possible and be tested so that it does not impact the user experience. 

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

REST API Design Practices

Link: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

In the blog post “Best practices for REST API design,” the authors go over important guidelines for designing any type of web service through the REST architecture style. They first go over the definition of a REST API, which is an interface that follows stateless communication and cacheability, as well as other constraints. They then show off a set of recommendations for good practices, such as using nouns and not verbs in endpoint paths, accepting and responding with JSON, logically nesting hierarchical resources, handling errors with standard HTTP status codes, and many more. The blog post emphasizes greatly that keeping names consistent and adhering to web standards will ultimately make APIs easier for maintainers and clients, as it will be easier for clients to use and maintainers to support. It would also make it much easier for systems to scale properly.

I selected this blog post because we are currently talking about this topic, and we have a homework assignment going over this topic so I thought it would be helpful to gain a deeper understanding of it. Also, in past courses, such as Unix Systems Programming, we would focus on architecture and backend systems, but I never really gave it a deeper look. This blog post gives very clear guidelines for REST API design, which can be very valuable in my career if I end up working in software or if I have to build or interact with APIs in the future. In the future, I plan on applying these principles if I ultimately have to design or integrate REST services, which could be through setting up a microservice in the cloud or even connecting to one as a consumer. I will definitely look to follow the guidelines listed in the blog post, as I believe that following those will provide a good baseline for my work. These API design patterns can also help me with projects, as I can ensure that my interface layers are clean and intuitive.

Overall, I thought that this blog post was very helpful and informative, as it provided a lot of clarity on the guidelines for REST API design. Their point about using nouns in endpoint paths was a very good point, as it is better for HTTP verbs to be doing the action. While it is a small naming decision, it can end up making a big difference when it comes to readability and maintainability. In the end, this blog post improved my understanding of REST API design practices and showed me that good design isn’t just about the efficiency of the algorithms and resources, but it is also about the service and client experience.

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

Understanding Scrum

My understanding of Scrum is that it isn’t just a process or checklist; it’s a lightweight framework for solving complex problems through collaboration, transparency, and continuous improvement. The Scrum Guide defines Scrum as: “a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.” The framework is based on … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

BLOG 2 – Agile vs Scrum

There are many different methodologies that can be used for project management. The two that I would like the most are Agile methodology and Scrum methodology. So, what are the differences between these two methodologies, and when is choosing the right one? In this article, I want to summarize the key differences between agile and Scrum methodologies based on what I just read from Northeastern University Graduate Programs. Their article is really helpful for me and you to understand what they are and their differences. The article link is posted below. Feel free to check it out for further information: 

Agile vs. Scrum: What’s the Difference?

Agile vs. Scrum: What’s the Difference?

By Shayna Jouber

What is Agile Project Management? 

People say that Agile is a way of thinking about project management that focuses on delivering in small steps, being in touch with customers, and being able to adapt to change. Agile doesn’t tell you what process to use; instead, it gives you ideals and principles (like those in the Agile Manifesto) that you may use with other methods (like Scrum, Kanban, XP, etc.).\

Important traits: constant communication with customers and end users, willingness to change the scope of work, and delivering work in small steps.

What is Scrum Project Management?

One such approach in the Agile family is Scrum. It offers a clear procedure for handling tasks, including who completes them, how they are arranged, and when they are finished.

Typical Scrum responsibilities include a cross-functional team, a product owner who is in charge of optimizing the product’s value, and a scrum master who makes sure the team follows Scrum procedures.

Work is divided into sprints, which typically last two to four weeks. The team decides which subset of the scope to finish at a sprint planning meeting. Every sprint concludes with a review and retrospective to consider what was accomplished and make improvements.

Frequent delivery of “shippable” increments as opposed to waiting until the project is finished to provide everything is one of the clear benefits.

Agile vs Scrum – Key differences 

Agile is the underlying idea or strategy, and Scrum is a way to put Agile into practice.

Scrum is always Agile since it adheres to Agile principles, but utilizing Agile does not imply using Scrum; you may choose to use another Agile methodology instead.

Choosing the Right Methodology 

  • Agile: Agile makes sense if the project requires flexibility, frequent testing, stakeholder feedback, and shifting requirements.
  • Scrum: Scrum usually works well in situations with a lot of uncertainty, rapid changes, and the ability to arrange into sprint cycles.

Selecting the approach is only one aspect of it; another is having strong communication, leadership, critical thinking, project management, and organizational dynamics skills.

Conclusion 

Don’t use “Agile” and “Scrum” interchangeably; Agile is more comprehensive, and Scrum is one way to achieve it.

Before choosing Agile, consider the context of your project; if you decide on Agile, select the appropriate approach.

Methodology is only one aspect of successful project management; other factors include teamwork, stakeholder engagement, effective leadership, and flexibility.

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

Understanding Team Management

Proper team management is the crux of a well-oiled workflow and a productive team. This blog post by Alicia Schneider highlights not only what good team management is but also how to achieve that and improve your own management skills. Team management covers not only the coordination of oneself and fellow members of the group, but also facilitating and supporting the members through communication and ensuring a healthy and positive work environment that uplifts and motivates all. Clear roles and tasks through delegation are vital in ensuring that everyone knows their job at the overarching goal, as well as giving credit and praise to those who deserve it for a job well done. There are multiple types of management styles, which include:

Autocratic: Managers make decisions without input from team members

Democratic: Team members share ideas and thoughts in decisions that will affect the team before coming to a consensus

Laissez-faire: The Manager allows the team to self-manage with only minor input

Transformational: Managers’ main goal is to inspire and motivate the team to innovate

Transactional: Reward and penalize team members based on their completion of tasks and following outlined instructions

Collaborative: Managers help the team to work together, while the team focuses on working together and making decisions as a group

Coach: Give guidance, support, and advice to team members to improve and develop skills

Servant: Predominantly focused on fostering the growth of the team members

I chose this topic because it aligns with the current lecture material, such as Scrum and Agile workflows. Team management is key for these. No matter one’s role, there is always self-management and teams working in such close collaboration that everyone is managing each other. While the role of leadership may be delegated to a predefined position in these structures, management still relies on communication between people, such as between developers in the Scrum workflow. After reading the blog post, my overall notion of team management has expanded in terms of how to develop my management ideas. I had originally just seen it as delegating tasks and facilitating discussion, but it is actually much deeper after reading. While I myself may not agree with all of the management styles, I find that there are things that can be pulled from them to become a more effective leader and supportive team member, such as fostering the growth of team members from the “Servant” style, which is a great idea to also implement with the “Coach” style of giving guidance and support. By blending the management styles like this, I believe that it will help to produce not only a more productive team but also a more positive environment with great morale. I look forward to implementing these ideas in my future teams I work in and may lead.

Work Cited:

Schneider, A. (2024, August 21). How to manage a team: 6 powerful tips for team management. Monday. October 22, 2025, https://monday.com/blog/teamwork/team-management/

From the blog CS@Worcester – Dan's Blog by Daniel Fung-A-Fat and used with permission of the author. All other rights reserved by the author.

More Information on Agile and Scrum

I decided to write this self-directed blog entry on an article I found regarding information and differences between Agile and Scrum, two topics we have recently been covering in class. I sought to learn more about these two topics, as I was not entirely confident in my understanding of them. I unfortunately was absent due to an illness on the day we covered the Agile methodology in class, so in order to get a better understanding on the topic, I went through the activity and learned more about it on my own time. This article summarizes what Agile and Scrum are, their differences, the core Agile values and principles, the basics of Scrum, and when and how they should be utilized. This was quite a thorough read and was very informative to reinforce what I had learned from the class. One thing that I did not immediately connect from class was that Scrum was based on the Agile philosophies. As best said in the article, Agile is the guiding principles to shape how you work, Scrum gives a structured playbook to follow.

Though I do not plan to go into software development as a career path, I think this is still a beneficial way to learn quality teamwork and collaboration. Regardless of concentration or field of study, computer science and information systems related disciplines require efficient teamwork and collaboration. Working professionally in the field for four years now, there has never been a project or major task that involved no one besides myself. I always had to work with different teams to accomplish the final goal that was needed. Learning this framework could be very beneficial for me moving forward so I can apply it to my future professional projects. Having better tools almost always leads to a better job done, and I always strive to improve and better myself as a technology professional.

One discovery made from this article is that there are other common implementations of Agile outside of Scrum. One of these, I recognized from my professional experience, as my current organization requires all full-time staff to participate in Lean training. I was not aware that Lean training, which according to the article, “aims to eliminate waste and maximize customer value by focusing on efficiency and continuous improvement,” was an extension of the Agile methodology. This is critical, especially in the healthcare environment that I work in. It is an everchanging field and an environment that can change drastically within a matter of seconds. Though I am not a full-time employee and have yet to participate in that training, I will participate in it once I resume full-time work permanently at the end of December 2025.

ZG

The link to the blog post: https://monday.com/blog/rnd/agile-vs-scrum/

, ,

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Working in Agile and Scrum Teams

Source: Hapticmedia and The Scrum Guide

Agile is a methodology that allows for iterative development that is constantly being improved upon for the best product and efficiency. Those who use Agile follow the manifesto, consisting of 4 values and 12 principles of best practices. 

The values are: 

  1. Individuals and Interactions Over Processes and Tools
  2. Working Software Over Comprehensive Documentation
  3. Customer Collaboration Over Contract Negotiation
  4. Responding to Change Over Following a Plan

The first value relates to prioritizing how the team is working as a whole rather than following a strict set of protocols that may hinder productivity. The second value focuses on getting a working product to show the customer over spending too much time on documentation that does not progress the project. The third value involves the customer in the development process, allowing for constant feedback and a product the customer will love. The fourth value is similar to the first, reacting to changes the team needs to make to be more efficient and create a working product is more important than sticking to a plan created in the beginning. 

A type of the Agile methodology is called Scrum. Scrum breaks down a project into small “sprints” where the team works on a small increment of the whole project. In each team there are the Developers, a Product Owner, and a Scrum Master. The Product Owner acts as the communicator between the developers and the customer and maintains a priority list of what needs to be done. The Scrum Master oversees the developers and ensures they are being as effective as they can be. During each sprint, there are 4 main components, the planning meeting, the daily scrum, the sprint review, and the sprint retrospective. The planning meeting happens at the beginning of the sprint and is where the team decides what they will accomplish this sprint. The daily scrum is a daily meeting where everyone decides what they will do that day and what they will do better from the day before. The sprint review is a meeting with the customers/stakeholders where everything that was accomplished is presented. The sprint retrospective is a meeting between the scrum team where they discuss what went well overall and what needs to change for the next sprint. 

Agile is a very effective methodology for software development. Over 85% of developers use it and it improves delivery time and team morale. It also allows for all team members to be on the same level where everyone is important and always making valuable progress. I hope to be in a team that uses Agile because it is the most effective compared to other methods of software development, like Waterfall. I am looking forward to experiencing the Scrum process first-hand in the Software Development Capstone next semester and I have high hopes of what it will do for my long term career.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.