Category Archives: CS@Worcester

Understanding Pairwise and Combinatorial Testing

Hello everyone, and welcome back to my weekly blog post! This week, we’re diving into an essential software testing technique: Pairwise and Combinatorial Testing. These methods help testers create effective test cases without needing to check every single possible combination of inputs. Similar to most of the test cases selection methods we’ve learned.

To make things more relatable, let’s start with a real-life example from the insurance industry.

A Real-Life Problem: Insurance Policy Testing

Imagine you are working for an insurance company that sells car insurance. Customers can choose different policy options based on:

  1. Car Type: Sedan, SUV, Truck
  2. Driver’s Age: Under 25, 25–50, Over 50
  3. Coverage Type: Basic, Standard, Premium

If we tested every possible combination, we would have:

3 × 3 × 3 = 27 test cases!

This is just for three factors. If we add more, such as driving history, location, or accident records, the number of test cases grows exponentially, making full testing impossible.

So how can we test efficiently while ensuring that all critical scenarios are covered?
That’s where Pairwise and Combinatorial Testing come in!

What is Combinatorial Testing?

Combinatorial Testing is a technique that selects test cases based on different input combinations. Instead of testing all possible inputs, it chooses a smaller set that still covers key interactions between variables.

Example: Combinatorial Testing for Insurance Policies

Instead of testing all 27 cases, we can use combinatorial testing to reduce the number of test cases while still covering important interactions.

A possible set of test cases could be:

Test Case Car Type Driver’s Age Coverage Type
1 Sedan Under 25 Basic
2 SUV 25–50 Standard
3 Truck Over 50 Premium
4 Sedan 25–50 Premium
5 SUV Over 50 Basic
6 Truck Under 25 Standard

This method reduces the number of test cases while ensuring that each factor appears in multiple meaningful combinations.

What is Pairwise Testing?

Pairwise Testing is a type of combinatorial testing where all possible pairs of input values are tested at least once. Research has shown that most defects in software are caused by the interaction of just two variables, so testing all pairs ensures good coverage with fewer test cases.

Example: Pairwise Testing for Insurance Policies

Instead of testing all combinations, we can create a smaller set where every pair of values appears at least once:

Test Case Car Type Driver’s Age Coverage Type
1 Sedan Under 25 Basic
2 Sedan 25–50 Standard
3 SUV Under 25 Premium
4 SUV Over 50 Basic
5 Truck 25–50 Premium
6 Truck Over 50 Standard

Here, every pair (Car Type, Driver’s Age), (Car Type, Coverage Type), and (Driver’s Age, Coverage Type) appears at least once. This means we cover all important interactions with just 6 test cases instead of 27!

Permutations and Combinations in Testing

To understand combinatorial testing better, we need to understand permutations and combinations. These are ways of arranging or selecting elements from a set.

What is a Combination?

A combination is a selection of elements where order does not matter. The formula for combinations is: C(n, r) = n! / [r! * (n – r)!]

where:

  • n is the total number of items
  • r is the number of selected items
  • ! (factorial) means multiplying all numbers down to 1

Example of Combination in Insurance

If an insurance company wants to offer 3 different discounts from a list of 5 available discounts, the number of ways to choose these discounts is: C(5,3)=5!3!(5−3)!

So, there are 10 different ways to choose 3 discounts.

What is a Permutation?

A permutation is an arrangement of elements where order matters. The formula for permutations is: P(n, r) = n! / (n – r)!

where:

  • n is the total number of items
  • r is the number of selected items

Example of Permutation in Insurance

If an insurance company wants to assign 3 priority levels (High, Medium, Low) to 5 claims, the number of ways to arrange these claims is: P(5,3)=5!(5−3)!

So, there are 60 different ways to assign priority levels to 3 claims.

Why Use Pairwise and Combinatorial Testing?

  1. Saves Time and Effort – Testing fewer cases while maintaining coverage.
  2. Covers Critical Scenarios – Ensures every important combination is tested.
  3. Finds Defects Faster – Most bugs are caused by two interacting factors, so pairwise testing helps detect them efficiently.
  4. Reduces Costs – Fewer test cases mean lower testing costs and faster releases.

When Should You Use These Techniques?

  • When a system has many input variables
  • When full exhaustive testing is impractical
  • When you need to find bugs quickly with limited resources
  • When testing insurance, finance, healthcare, and other complex systems

Tools for Pairwise and Combinatorial Testing

To make the process easier, you can use tools like:

  • PICT (Pairwise Independent Combinatorial Testing Tool) – Free from Microsoft
  • Hexawise – A combinatorial test design tool
  • ACTS (Automated Combinatorial Testing for Software) – Developed by NIST

These tools help generate optimized test cases automatically based on pairwise and combinatorial principles.

Conclusion

Pairwise and Combinatorial Testing are powerful techniques that allow testers to find defects efficiently without having to test every possible combination. They save time, reduce costs, and improve software quality.

Next time you’re dealing with multiple input variables, try using Pairwise or Combinatorial Testing to make your testing smarter and more effective!

From the blog Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog

My task for Sprint 1 was to add a new date field that shows when the guest was created into the backend API. In this sprint, I worked closely with my teammate Sean Kirwin as he was working on the backend as well. I had to create a reference to the schema for the date of the first entry in the OpenAPI field. Below is the link to the merge request.

What worked well for me in Sprint 1 was being able to work on a task that I had experience with. I was confident to get what I needed to get done in a timely manner. I also appreciated the fact that I was able to work with one of my team members. 

As a team, I believe we worked well together. My team did a good job with the sprint planning and dividing the roles for each task effectively. Each team member was good at communicating what they had done each week of the sprint. I appreciated that my team members were always there to give constructive feedback each week and also helped me out when I had a question about how to navigate working on my task. A way my team could improve is show the work we did for the week instead of just explaining it. It would help visually. 

This task took me more time than it needed to. As an individual, I could improve my time management when it comes to working on my assigned tasks. Although I had improved my communication with the team throughout the sprint, I think I could do. I did not necessarily have issues with making the changes to the files, however, my partner and I had issues with the merge request. The pipeline kept failing because of the lint-commit-messages, but my partner and I were able to resolve this issue with research. 

The pattern I related to from the Apprenticeship Patterns book was “Learn How You Fail”.In this chapter, it highlights the significance of being aware of your weaknesses and areas of failure. It implies that although learning improves performance, shortcomings and failures endure unless they are actively addressed. The most important lesson is to seek self-awareness about the actions, circumstances, and habits that contribute to failure. Making deliberate choices either to accept and overcome limits or to do better in particular areas is made possible by this self-awareness. The pattern promotes a balanced approach to growth and discourages self-pity or perfectionism.

I chose this pattern because it is closely related to my experience during the sprint. I ran into issues with time management, working with others on code reviews, and managing merge request issues during the sprint. I became aware that I was frequently making the same errors, such as failing to consider edge scenarios or misinterpreting project specifications. I could have dealt with these failure patterns proactively rather than reactively when issues emerged if I had been more deliberate about identifying them early. The “Learn How You Fail” pattern would have helped me take a step back, identify recurring problems, and strategize ways to improve.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/107

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Sprint Retrospect Blog 1

When you have been in college for about 5 years, you start to think that there can’t be any more surprises and that you have been through pretty much everything, boy was I wrong on that one. This semester started in a way that I was at the same time familiar and a stranger to. Being divided into groups was nothing new to me, but sharing a long-term goal with a group of people was something that I was unaccustomed with.

We started this project together without any of us having any idea how to proceed, and I doubt anyone knew what they were doing the first week, but what we missed in knowledge we found in supporting each other. We have been part of groups before, but I can wholeheartedly say that this is the first time I’ve felt myself being part of a team. Through friendship and communication, we started to lay out a plan that helped us give form to a project we started from scratch. The best thing we might have done is to divide ourselves in sub-groups, each focusing on specific tasks that they felt comfortable working on. Be it by coincidence or instinct, I have always found myself to be the odd one out, being the only one working independently but this was very short lived in this setting as after the first week of actually working on the project I quickly found myself asking and finding a great deal of help and opinions from my teammates. We all ask and give help without even noticing it, learning new things along the way even though after years of being a CS student.

This leads me to one of the Apprenticeship Patterns called “The Long Road”. This pattern reminds us that becoming a true software craftsman isn’t about reaching a final destination. Instead, it’s an ongoing process where every project, challenge, and mistake is an opportunity to learn and rather than expecting immediate expertise, the long road emphasizes small, consistent improvements over time with each step building on the previous one. Reflecting on both successes and failures evolves or changes our goals and teaches us that on the long run we should not only value coding proficiency but also soft skills such as communication, teamwork and the ability to collaborate with mentors and peers. I was too fixated on the end-goals, finishing the project, and reading this pattern before starting to work would have saved me some good hours of unnecessary headaches.

This pattern became even more evident to me when I reviewed the first commits I did in this project. Working on the guest-info system the past semester, I thought it would be a breeze adding on to it and giving it shape to help our end-goals, which ended up in failure. I tried to do too much in a short amount of time, add new endpoints to the API, add the script to update our existing database with new objects with extra attributes. My whole work ended up failing at the end as my lack of knowledge caused irreparable errors in the code.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/newAPI?ref_type=heads – My initial branch where 85% of the added code went wrong.

Thankfully, I learned from these mistakes, and having great teammates helps a lot. Michael and Prince worked on shaping our schemas and API to match the attributes from the objects we were fetching from an external dataset, by adding a few tweaks and a quick script, I managed to fetch the correct object and lay the groundwork for our next sprint, which is combining all of our work together.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/src?ref_type=heads – The current folder containing the script and tweaks to the guest-info API.

I am happy to have communicative and capable teammates to help me and each other during this project. Being able to ask for help and share opinions without being judged is working wonders on our team and helping us understand each other’s work more efficently.

What I’m not happy with is myself and how I more than often take a bigger bite than what I can chew, working on small increments is something that I would improve for myself in the future.

I know that the upcoming spring will be challenging, but with a great team and gradual self-improvement, I’m confident that we will be proud of the end result.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Sprint-1

Evidence of Activity on GitLab

  1. Meeting with Customer to Identify Categories
    • A .js file named categories.js was built to help my peers start testing different category structures.
  2. Data Extraction for TeaSparty Project
    • The USDA FoodData Central downloadable data was extracted to build a comprehensive database.
  3. Database Optimization
    • The original database file was over 3.2GB and contained multiple unnecessary fields.
    • A Java file was developed to remove unnecessary fields such as foodNutrients, nutrients, rank, protein, and their respective IDs.
    • Successfully reduced the database from 3.2GB to 0.7GB, making it more manageable for our project.

Reflection on What Worked Well

  1. Customer Collaboration
    • Meeting with the customer to identify category requirements ensured that the project met their needs effectively.
    • The creation of categories.js provided a starting point for peer testing, helping streamline future work.
  2. Database Optimization
    • By removing unnecessary fields, the database was significantly reduced in size, improving efficiency.
    • The pre-cleaning process helped identify redundant fields early on, making subsequent steps more manageable.

Reflection on What Didn’t Work Well

  1. API Call Extraction Issue
    • Initially, I attempted to extract the database via API calls but encountered a limitation: API calls only supported retrieving 100 items at a time, whereas there were over 100 pages to extract.
    • Researching solutions, I found that automation was the best approach, but due to my lack of expertise in automation, I couldn’t implement it effectively.
  2. Challenges in Categorizing Products
    • A Java file was created to categorize all products, but it was crashing due to issues with object field descriptions containing multiple nested quotes.
    • Example issue: "description":"ORIGINAL SWEET & SMOKY BAR \"\"B\"\" \"\"Q\"\" SAUCE, ORIGINAL".
    • As a workaround, I manually cleaned some of the problematic entries but am still looking for a better solution.

Reflection on What Changes Could Be Made to Improve as a Team

  • Better Communication
    • Ensuring consistent updates within the team would help synchronize our work and avoid redundant efforts.
    • More frequent check-ins to discuss roadblocks and potential solutions could improve efficiency.

Reflection on What Changes Could Be Made to Improve as an Individual

  • Increase Work Hours on the Project
    • Spending more time on the project will allow my peers to see my progress and provide feedback earlier.
  • Dependency on Others’ Progress
    • I am currently waiting for Alex to finish the dev container. In the meantime, I am focusing on cleaning the db.json file so I can upload it as soon as possible.

Apprenticeship Pattern: “Expose Your Ignorance”

Summary of the Pattern

The “Expose Your Ignorance” pattern from the Apprenticeship Patterns book emphasizes acknowledging one’s knowledge gaps and actively seeking to learn. It encourages transparency about what you don’t know while making efforts to bridge those gaps.

Why This Pattern Was Selected

During this sprint, I faced challenges with API automation and data cleaning that slowed my progress. If I had openly acknowledged my lack of expertise in automation sooner, I could have sought help from peers or external resources earlier in the sprint. This pattern aligns with my experience because it highlights the importance of being upfront about knowledge gaps and taking proactive steps to fill them.

How This Pattern Would Have Changed My Behavior

Had I followed this pattern earlier in the sprint:

  • I would have sought advice from team members or forums on API automation instead of spending excessive time trying to figure it out alone.
  • I would have explored existing libraries or tools for handling JSON parsing issues more efficiently instead of resorting to manual cleaning.

Conclusion

This sprint provided valuable lessons in data handling, API limitations, and the importance of seeking help when needed. Moving forward, I plan to improve communication within the team, allocate more time to the project, and be more proactive in addressing technical challenges. Applying the “Expose Your Ignorance” pattern will help me become a more effective contributor in future sprints.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Sprint-[1]

GitLab Activity

During this sprint, I contributed to multiple aspects of the project, focusing on both collaborative research and frontend development. Below are the key tasks I worked on, with links to the related issues:

  1. Issue #26: Created a fake frontend – Designed and developed a simulated frontend to represent the user interface for testing and demonstration purposes.
  2. Issue #20: Researched Docker architecture – Collaboratively explored and documented Docker architecture with the team to establish a strong foundation for the project’s infrastructure.
  3. Issue #31: Created dummy pages for frontend login redirect – Built placeholder pages to simulate the login redirection process, enabling smoother navigation during development.

Reflection on Performance

What Worked Well

This sprint highlighted some clear wins for both myself and the team. Collaborating on Docker architecture research proved to be an invaluable learning experience. By pooling our knowledge and resources, we quickly gained a better understanding of Docker’s potential for our project. On the frontend, creating the fake frontend and dummy login redirect pages allowed me to apply and refine my skills in UI development. These tasks were particularly fulfilling because they provided tangible progress toward a functional interface.

What Didn’t Work Well

While the sprint had its successes, there were also challenges. Managing time effectively across multiple tasks was one of my personal struggles. For instance, balancing the research on Docker architecture with the development of the frontend required careful prioritization, and I occasionally found myself spending too much time on one task at the expense of another. Additionally, the lack of established workflows for testing the fake frontend made it harder to identify and fix issues early on.

Changes to Improve as a Team

As a team, we could benefit from setting aside dedicated time for pair programming or collaborative problem-solving sessions. This could enhance our understanding of challenging topics, like Docker architecture, and ensure that everyone feels confident in applying what we’ve learned. Regular check-ins or daily stand-ups could also help us address blockers more quickly and align our efforts more effectively.

Changes to Improve as an Individual

Individually, I want to work on improving my time management and task prioritization. Establishing a clear plan at the start of each sprint, with time allocated to specific tasks, could help me maintain better focus. I also aim to proactively seek feedback on my work, particularly when tackling new challenges like Docker architecture, so I can learn more efficiently and avoid unnecessary delays.

Apprenticeship Pattern Reflection

Selected Pattern: “Expose Your Ignorance”

For this sprint, I chose the Apprenticeship Pattern “Expose Your Ignorance” from Chapter 2. This pattern emphasizes the importance of acknowledging knowledge gaps and actively working to address them by seeking help, asking questions, and being open about what you don’t know.

Summary

The pattern advocates for embracing ignorance as a normal part of the learning process. It challenges the notion that developers should appear to have all the answers, encouraging honesty and curiosity instead. By exposing ignorance, individuals can learn more effectively and foster a collaborative environment where everyone feels empowered to grow.

Relevance to My Experience

This pattern resonated deeply with my experience during the sprint, particularly in the context of Docker architecture research. Initially, I felt hesitant to admit my lack of familiarity with some Docker concepts, but collaborating with the team and sharing our findings made the learning process much smoother. Similarly, while working on the fake frontend, I encountered unfamiliar scenarios where seeking guidance earlier would have saved time.

How It Would Have Changed My Behavior

If I had fully embraced this pattern from the beginning of the sprint, I would have been more proactive in asking questions and seeking clarification during our Docker research sessions. I might also have reached out to teammates or mentors for advice on frontend best practices when creating the fake frontend and dummy pages. In future sprints, I plan to actively apply this principle by fostering a culture of openness and curiosity, both for myself and within the team.

From the blog CS@Worcester – aRomeoDev by aromeo4f978d012d4 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

What worked best in this sprint was our team’s collaboration and the understanding I gained through independent research. From the get-go, our team had very few issues communicating. We checked in on each other during class and collectively made decisions on the project’s future without any conflict. Everyone seemed committed to their tasks, which allowed us to complete our sprint goals on time.
Throughout the sprint, I encountered many aspects of the project I was unfamiliar with, including RabbitMQ, MongoDB, and Docker. A lot of my time was dedicated to researching, reading blog posts, watching tutorials, and testing to understand how they worked. With the newest Sprint 2 goals involving the production and consumption of data using RabbitMQ and inserting it into MongoDB, I feel more confident handling these tasks.

What did not work well in the sprint were some complications with my operating system and a lack of documentation on GitLab. At the beginning of the sprint, I had trouble opening a port with my Mac, with my solutions working in some moments and not working in others. Eventually, that issue was fixed, but being unable to test during that time hindered my contribution. I worked locally to get things running with my Mac, testing the reporting backend and understanding how everything fits together, but I did not always push that work or create merge requests to show my progress. Much of my effort went into trial and error testing, and sometimes, my work felt redundant. I need to better communicate with the team so I can accomplish tasks more efficiently.

So far, we have been communicating well in class, and there has not been a need for constant checkups on Discord. That could change, and probably should, with the upcoming sprint. We will need to communicate effectively if our tasks end up conflicting. I could communicate better on Discord and will strive to do so in the next sprint. Working around work and school has been difficult, so I should discuss that with my group so we are on the same page.

The pattern from the Apprenticeship Patterns book that aligns well with my experience during Sprint one would be Confronting Your Ignorance. This pattern involves identifying gaps in your knowledge and actively working on them, even if the gaps are from areas people on your team assume you already know. It encourages you to fill these gaps through whatever methods work best for you, including reading, individual projects, or asking for help.
I selected this pattern because I recognized gaps in my knowledge and confronted them so I could contribute to the team effectively. I spent a lot of time getting familiar with RabbitMQ, MongoDB, Docker, and the Reporting System. I leaned on some of my teammates, who felt more comfortable with the tools, asking questions during class. I also did independent research, reading blog posts, tutorials, and documentation. These aspects of the sprint were most relevant to the Confronting Your Ignorance pattern.
I do not believe reading the pattern would have changed my behavior during the sprint. I understood that there would be different levels of expertise in a team, and not knowing something was not a weakness but an opportunity to learn. What’s important is that you take steps to fill the gaps in knowledge, which is what I strived to do during the sprint.

Link to Gitlab:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/37999a7f42ed4eb89d6f7ab2e2a4d530fec3010c

  • Updating the dev container file and fixing the issue where the 10350 port would close unexpectedly.

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

still thinking of a witty title

To start, this was my first real team project where I felt like all of the team members were highly capable of putting something of value together. It’s been a great experience to learn and collaborate with such a good group.

We started this project basically from scratch, learning just how difficult that actually is. Over time we worked out our goals and expectations along the way. Through some facet of peer pressure and blind faith I got elected to lead the team, though each member has done something to guide all of us in one way or another. 

This leads to the topic of what worked well with our team. First, we all tried to get to know each other a little better. Aside from having the same major and concentration, a friendly connection has absolutely benefited us when it comes to communicating and holding each other accountable. It also fostered an environment of being able to ask questions and for help when it was needed. It quickly became a good time coming to class and being on time just to see each other and show our work in person. Due to instinct or pure luck, the best move we made was breaking our group up into pairs, otherwise known as pair programming. This allowed us to have 2 people focusing on each aspect of our project making progress in all areas simultaneously. 

For myself, one part I would like us to improve is being more on top of explaining the finer details of what each pair is working on. Being the leader I am seeing the big picture of the project but I do feel at times the others get a little lost in their own portions. During the sprint reviews I think we did a good job showing each other what that meant, but we could certainly get better when it comes to the day to day aspect.

All of this culminates into one of the things that really stuck out to me in the second chapter of the book Apprenticeship Patterns referenced in a previous blog. This chapter was about “emptying the cup”. This phrase is an amazing metaphor for not allowing yourself to think you know too much to be able to learn from others. Too often have I myself fallen victim to my own thinking of already understanding all there is to know about a given subject. Sometimes it’s really beneficial to go into something with a fresh and open mind.

For example, while developing the inventory back-end there were at least 5 times where I had to start completely over. While this sounds like it would be extremely frustrating I was noticing that every time this happened, I was learning something new along the way. After having worked with the guest info back-end I thought I was going to breeze through replicating it. It wasn’t until doing it over and over that I realized just how much I was missing under the surface.

Nearing the deadline I was actually becoming a little worried that it wasn’t going to work out in time. We would have to move it into the next sprint. However due to having so much practice and my partners assistance making a mock version of what i was creating. We were able to very quickly and easily put together a working prototype of the true vision we had. This prototype is also proving to be fundamental to how we continue into the next sprint.

In the end my team came together and had 3 portions of this project ready to demo for the customer and our professor. It all worked exactly how we planned and it was so refreshing to witness. We all did a great job and should feel proud for how far we managed to come in just one month working on this and knowing each other.

Here are all 3 portions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/src?ref_type=heads

  • This is a 2 for one. 
  • The mock database itself was created by me and my pair partner Prince.
  • The script to fetch data from an API we are utilizing was done by our teammate Anairdo

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend

  • This directory is the front end our other teammates have been working on to pair up with our backend. Credit to Adam and Donna

From the blog CS@Worcester – Mike St G – 448 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

My first sprint was a trial of figuring things out. Had to get accustomed to my team members and the program that was already created before. I was assigned to the reporting system and going in with my teammates and I didn’t know how far along the project had been. We had to first get settled and understand what updates needed to be done to complete our first sprint. Our sprint planning went well we understood the issues left before from a different class could be used for our sprint in this class. We all selected an issue that each one of us would resolve including some minor ones that came later on. I was chosen to Determine the startup procedure for MongoDB and RabbitMQ in the development environment. 

At first, I was confused with understanding what I had to do but after reading the comments made I began to understand what needed to be done. It was more of a test by creating another docker-compose file to run the Rabbimq without the backend. I created a devDocker-compose to achieve my goal. I then created another index.js file. I did this to run the developer versions or production of the up scripts. I did minor updates during the sprint including updating devcontainer so it would work better on Macs. There were several things we had to update so we split up the work and committed the corresponding ones to the main. I helped my teammates in their projects as well by working in their branches and accepting their merges when needed. As a team, we worked united and we always made sure we were all on the same page. During this sprint, we learned new things that we could incorporate into our team including updating each other on what we are working on today to be on the same page. We never let any team get lost and we were always there to pick each other up. One moment I could recall is that one of our member’s computers was having issues and we all as a unit came to find the issue which we did. Even for minor mistakes like commit messages, we made sure to edit and fix them to pass the pipeline. 

The pattern I would choose from the Apprenticeship Patterns book would be to expose your ignorance. It’s great to work alone and do your own thing but if you get stuck don’t be scared to get help from teammates instead of figuring it out alone. It’s great to get feedback and ask questions to everyone. This pattern is key for the growth of a developer and being able to be humble when addressing gaps of knowledge. You don’t have to act like you know everything because of pride or embarrassment but be willing to learn and be curious without fear. During this sprint, if I didn’t ask for help in certain scenarios I wouldn’t have known how to continue my project but being able to discuss boosted my work progress. When you are first joining a team you want to be reliable instead of a burden but asking questions as a whole will strengthen your team. During this spring I wouldn’t have hesitated to ask more questions that I had figured out on my own.     

From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Created a separate branch from the frontend to solve the CORS/SSL issue

Created epics for larger tasks and broke them down

Organized tasks into issue boards

Prepared for Sprint 2 by adding new tasks

Documented important information regarding issues and how they were solved

In sprint 1, we were able to mostly complete everything we planned out; needing some revisions in certain areas. As a team, we performed well with eachother and communicated effectively to ensure all tasks were progressing at a timely manner. Additionally, we looked to eachother for help when we were stuck and didn’t know how to progress further, preventing teammates from falling behind in their tasks. What didn’t work well ocurred near the end of the sprint, where a teammate didn’t fully complete their task like they were supposed to, requiring one person to complete their task in sprint 2. This problem could have been solved if the team incorporated weekly code reviews to ensure that all areas of the task is looked over and nothing is forgotten. As the scrum master for the team, I plan to push for this element in future meetings.

Another improvement for the team that will be implemented in sprint 2 is better meeting time management. Since we only meet twice a week as a team, we should take this time to share progress we have made to the whole team. This could be any code written or any interesting articles that are useful to know. The primary goal of the capstone is to simulate a real development environment and solve tasks effectively. Equally important, however, is the opportunity to absorb and learn as much as possible. Something your teammates discover may prove valuable to you in your future career.

To improve as an individual, I want to get involved in other peoples tasks and try to offer my input in any way possible. Instead of being preoccupied by my own assigned tasks, widening my scope of work to my teammates tasks will allow me to grow as a developer and expose me to various tasks.

One pattern from Apprenticeship Patterns, that aligns with this sprint is “Confront Your Ignorance”. The pattern emphasizes the importance of recognizing and addressing gaps in your knowledge. Instead of avoiding unfamiliar topics, you should actively seek out challenges that push you to learn. This involves identifying areas where you lack expertise, setting goals to improve, and dedicating time to research, practice, and experiment. By taking on tasks outside your comfort zone, you develop problem-solving skills, adaptability, and a deeper understanding of new concepts. It pushes you to adopt a continuous growth mindset and helps you become a more effective and well-rounded developer. Going into capstone, I knew that I wanted to push myself to learn as much as possible, which is why for the first sprint I chose a task that I had zero prior knowledge about. In order to work on my issue, I had to research about CORS and SSL certificates, both of which are crucial concepts in web security and backend development. This process involved reading documentation, troubleshooting errors, and experimenting with different configurations to understand how they functioned. Choosing this issue to work on has also exposed me to the use of proxies, that route frontend requests to the backend. Utilizing a proxy will ideally allow the http backend url to connect to the https frontend url. In sprint 2, I plan to experiment more with proxies.

From the blog CS@Worcester – Computer Science Through a Senior by Winston Luu and used with permission of the author. All other rights reserved by the author.

Software Development Capstone Sprint 1 Review

After the completion of our first sprint, I believe our team performed very well. There were no issues left in the sprint backlog at the conclusion of the sprint, and, equally important, our understanding of how the Thea’s Pantry reporting system needs to work has grown significantly.

The divide and conquer approach taken worked well for us. Splitting up the issues gave us more flexibility in how we would approach our particular task. For me personally, I was able to do my research and development at a faster pace as opposed to having multiple people working on the same file. On the other hand, our team meetings were extremely useful for getting feedback and help with development issues. Having more sets of eyes to look at a problem often times got issues resolved quickly. The team dynamic in programming and software development, in my experience, is usually a balance between avoiding a “too many cooks in the kitchen” situation and making sure the team is communicating and engaged with each other. I believe our team balanced this reasonably well.

That said, I believe we should work to improve our inter-team communication. Having a good sense of what other members are working on is important if we’re going to continue to divide issue assignments. This is something I should work on specifically too. I want to avoid the habit of staying head-down in my laptop working, and do a better job of communicating on the status of what I’m doing, especially when working on my own.

My main focus for development was writing the code to create a properly-titled .csv report file to be sent and downloaded onto the user machine when the API call is executed. Here are links and descriptions on specific things I accomplished this past sprint:

  1. getReport API Endpoint – Developed and tested RestAPI endpoint to retrieve report file.
  2. buildReport Function – JavaScript function to build the report itself from RabbitMQ data. Currently, this generates a blank .csv file with the proper title with relevant dates of the report.
  3. JSDoc API Documentation – Began setup and use of JSDoc, a markup language for JavaScript to generate developer documentation.
  4. JSDoc Deployment Shell Script – Shell script to aid in building documentation files.

From the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave H. Hoover and Adewale Oshineye, the section regarding protecting one’s passion for software craftsmanship stuck out to me. Getting tired or frustrated when writing code is more or less inevitable; being able to separate those feelings from the field as a whole is key. The book mentions the idea of “Drawing Your Own Map”, a strategy for mitigating burnout. The core idea is setting limits for yourself can be as important as setting your goals. One can define the boundaries in which they allow themselves to work within, as even with short-term consequences (the book mentions missed raises and unhappy coworkers as examples), walking The Long Road rewards pace and longevity, not speed. I firmly agree with the statement made by the authors; quality craftsmanship does not come from short, intense periods of work followed by burnout, but by maintaining a steady pace forward across a decades-long career.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.