Unlocking Success Through Understanding Failure

Throughout the long road of lifes, we always strive to find success, but sometimes we may hit roadblocks and fail. Some of us choose to accept those failures and learn from them, but others may neglect those failures and choose to take an alternative route. The Learn How You Fail pattern, emphasizes the importance of embracing failure. Embracing failure is a crucial aspect of not only personal growth but also professional growth. This pattern encourages us to look for our weaknesses and patterns of failure, and instead of avoiding them, accepting and learning from them. If we can gain knowledge on how, why, and what led to our previous failures, we can learn from them, make adjustments, and pave a path to success in the future.

When we think of the word failure, we often think that it carries a negative connotation, referencing setbacks or disappointments. Yet, in our journey as aspiring craftsmen, failure is not just part of our professional learning, it is possibly one of our greatest teachers. We’ve all experienced some sort of failure at some point in our lives. But the most important part of dealing with failure is pinpointing why we failed, fixing it, and taking those issues head on.

I found this pattern to be extremely interesting considering many people give up after they fail. Failure isn’t something that should be feared or avoided. Instead it should be embraced as a catalyst for learning and self development. It underscores the idea that true growth comes from a willingness to confront our failures and adapt. What I find particularly interesting about this pattern though, is its emphasis on self-awareness and introspection. By actively seeking to understand our patterns of failure, we can empower ourselves to make better decisions about our personal and professional development.

After reading more, I was able to connect the pattern to the software development field. In the field, we cannot just expect to find success. Through lots of learning, practice, and trial and error, we can eventually find success. Instead of viewing failure as a setback or embarrassment, I view it more as an opportunity for reflection and growth. I now realize the importance of acknowledging my successes but also embracing my failures as learning experiences. In the future, I plan on having a more proactive approach towards identifying and addressing any of my weaknesses, rather than just ignoring them.

With this being said, the Learn How You Fail pattern, offers valuable insights into the importance of embracing failure as a means of personal and professional development. By learning from our failures, we can ultimately find success in our chosen fields.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

What Worked Well:

Sprint #3 was our last sprint as a team and appeared to be one of our easier sprints since we were all familiar with our team workflow, who was doing what, and reviewing processes. In Sprint #3, we were tasked with completing seven different issues for a total weight of 25 points. As a whole, we completed six out of our seven issues for a total weight of 24 out of 25 points. We managed to complete many issues as a team, which was extremely helpful. By combining five minds, we could work in an efficient manner. Something worth noting was our communication this sprint. In all three Sprints, we conducted weekly meetings either in person or over Discord. Additionally, we had weekly standup meetings informing the group with what everyone was currently working on, doing next, or needs help with. I noticed that once we finished one issue, nobody hesitated to start another issue. This helped propel the project forward. Connecting all three sprints, Sprint #1 was a learning process, Sprint #2 was learning how to efficiently work with each other and complete tasks in an effective manner, and Sprint #3 was combining everything we have learned and putting it together. Sprint #3, whether it was our workflow, completing issue process, review process, or communication, we were able to combine everything and find success. One thing I particularly enjoyed was the comments we made on issues. Everyone on the team wrote comments informing the team what was going on within an issue, what the issue needed for completion, and any changes made to contribute.

Improvements As A Team:

We made some drastic improvements from the previous sprints in regards to how we took on work, the time we worked on it, our review process, and much more. Considering this is our final sprint as a team, I believe we are more than capable of bringing what we have learned into the workforce. To continue growing individually on our own teams, I believe it would be important to continuously build on communication. Regardless of the group or team we are on, it’s important to always provide updates, feedback, and details upon what we are working on, completing, any problems, any help needed, and so on. By continuously building on communication, asking questions, and continuing to refine and develop our skillset, we can set ourselves up for success in the future regardless of the team we are on. 

Improvements As An Individual:

During Sprint #3, I was able to work on four different issues. My first issue I completed individually and it was Update and Review InventorySystem/Documentation. This issue required me to go through the different files and add any files, comments, or updates, so that everything was corrected for future sprints. My other three issues I completed with my team included, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryAPI, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryBackend, and Determine what needs to be done for GuestInfoFrontend. For the Verifying issues, these involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes to correct them. For the Determine what needs to be done for GuestInfoFrontend, involved the team building the frontend to view its contents and code. Here we created new issues for future sprints in regards to what needs to be completed, what can be changed or implemented better, and how we can improve the GuestInfoFrontend. For individual improvements, I’d like to continue being more of a team player where I’m open to help and support anyone on my team and voice my thoughts and opinions. Even if it’s just reviewing work and mentioning some tips or ideas, it can be extremely valuable. Additionally, when writing code or fixing documents, I’d like to add more comments. By doing so can allow anyone to understand my thought process while I’m working on issues. It would also allow other people to understand my work and not get lost or confused, allowing for anyone to contribute, add on, or provide feedback on what I’ve completed. Keeping that in mind, I believe it’ll help me grow as an individual and a teammate, and help me in numerous ways with my professional career.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Record What You Learn

The Apprenticeship Pattern “Record What You Learn” emphasizes the importance of documenting the journey and lessons that a software developer has learned to enhance personal and professional growth. This pattern addresses the common issue that many developers share of repeatedly encountering similar tasks or problems without retaining valuable insights. By maintaining a record of experiences in a journal, personal wiki, or blog, individuals can create a chronological account of the lessons they’ve learned, serving as both inspiration and a valuable resource.

Recording the solutions made to problems encountered along the software journey involves actively documenting experiences, insights, and solutions encountered. The primary problem of not documenting lessons learned is that it causes a lack of learning from past experiences, leading to repetition and inefficiency. Without a record of lessons learned, individuals may find themselves continuously getting slowed down by the same challenges without making much progress.

Maintaining a record of experiences offers several benefits. Firstly, it enables individuals to mentor others by making their journey explicit, sharing insights, and providing guidance based on past learnings. Additionally, it makes it easier to reflect, allowing individuals to identify patterns, make connections, and discover new insights.

To avoid falling into the trap of forgetting valuable lessons, individuals are encouraged to regularly revisit and review their records. By engaging in this process, they can prevent stagnation, identify areas for improvement, and continue evolving. Moreover, have access to and using both internal and external feedback allows the developer to receive more accurate self-assessment which motivates continuous learning and growth.

There are several examples in Apprenticeship Patterns that illustrate how individuals can implement this pattern in practice. For example, maintaining two instances of the same wiki — one for private thoughts and the other for shared lessons — allows for effective self-reflection. Similarly, transcribing ideas that shaped one’s learning into a text file allows it to be kept as a valuable resource for future reference and inspiration.

I believe that recording one’s learning progress it super important to any skill. So often I find myself making the same mistakes over and over again, but then I remember to look at my notes and the past resources I’ve logged for myself, and I find them super helpful in guiding my work to be more efficient and effective.

In conclusion, “Record What You Learn” encourages proactive documentation of experiences and insights to help developers apply what they’ve learned to everyday problems they may face. By methodically recording and reflecting on the lessons learned, programmers can discover valuable insights, avoid repeating past mistakes, and progress on their journey towards mastery.

From Chapter Five, “Record What You Learn” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Combinatorial Testing

One of the last types of testing techniques that we learned about this semester is known is Combinatorial Testing. Combinatorial testing is a testing technique that is used for software applications with a lot of different input possibilities and a high complexity. Even if you create a large number of different test cases, you will most likely still miss a test scenario. I’m not the best at explaining what something is, so I did some research in order to find an article that helps describe the aspects of combinatorial testing as well as how to use it and what its benefits are. This website is called testsigma.com

I think that this website does a great job at explaining what combinatorial testing is as well as all of its different benefits. In the article by Shanika Wickramasinghe, it states “Combinatorial testing is a testing method that uses multiple combinations of input parameters to perform testing for a software application. The main goal of combinatorial testing is to make sure that the software product can handle different combinations of test data as input parameters and configuration options.” This means that combinatorial testing takes a bunch of different input parameters, similar to pairwise testing, and uses it to test a bunch of different cases for the program. This can be extremely useful because some of the errors with a program can only be found with specific inputs. I’ve actually had this happen to me before in one of my classes. I wrote a program and testing a bunch of different inputs and they all worked, but when my teacher tried an input I never used, it failed. I think combinational testing is going to be extremely useful for me in the future. I know it seems like combinatorial testing can only be used in certain scenarios so it might be better to not learn it, but it actually has a lot of benefits according to Wickramasinghe:

  • Covers a broad range of input combinations using a minimum number of test cases.
  • Increases test coverage compared to normal component testing since it always considers multiple input combinations.
  • Helps to detect bugs, defects, vulnerabilities, and unexpected outputs that might not be detected during the usual component and regression testing phases.
  • Reduces testing effort, cost, and time. (Since combinatorial tests use fewer test cases to cover a wide scope of testing.)
  • Identifies issues at the earliest while allowing the team to address and fix those earlier in the software development life cycle.
  • Optimizes the testing process by removing unwanted test cases while ensuring that the cost and effort are not wasted on repeating the same test scenarios again and again.
  • Helps to test complex software applications with a large number of parameters, settings, and options.
  • Reduces the risk of critical defects going unnoticed, which can occur only when handling specific input combinations.

I recommend that everyone tries to use combinatorial testing at least once so they know how it works in case they ever need to use it again in the future to make sure all of their different input possibilities work.

Link: https://testsigma.com/blog/combinatorial-testing/

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Blog #8: Intro to Security Testing

Throughout the cumulative experience I’ve had with testing, most of it focuses on the program’s logic and ensuring that it yields a correct result. One aspect of testing I have no experience with is security testing. Here one must find flaws within a system/program’s security and report them to developers so they cannot be exploited later in the product’s lifespan. Security testing has much higher stakes than that of unit testing as vital information such as consumer personal information and system source code may be leaked if there is a security breach. Therefore, testing security is of utmost importance when releasing a service to the public, as failing to do so will damage the service’s integrity.

Security testing hosts several different types of tests, each of which focuses on different aspects of a system. The article Security Testing posted by user pp_pankaj highlights the principles upheld by this testing and what each test achieves. Some of these tests, Posture Assessment, I found quite interesting. Posture Assessment combines the testing methods of ethical hacking, risk assessment, and security scanning into one report to provide an overall security posture of a system (pp_pankaj). Each of these subtests has a shared goal of having a hacker, hired by the development team, find security vulnerabilities within their system and report it to the team. Another form of testing I found interesting was social engineering testing. This deviates drastically from what we as programmers come to understand tests as. These are emulated attacks through communication such as email. The purpose of this test is to train developers to avoid suspicious engagement and to find new ways to breach a system without making direct contact. Whether a development team gets successfully breached through the socially engineered test is dependent on the team’s understanding of who they must respond to. A few weeks ago I was researching a data breach that happened earlier this year at Microsoft. Hackers were able to control a testing account and had direct access to employees on the project. From here they were able to obtain information they naturally should not have access to. All of this occurred due to developers not knowing that they must not communicate with a testing account.

A general metric as to whether security testing is vital to a project is to consider whether your product is liable for holding personal information that is not your own. If this is the case, then it’s in the development team’s best interest to uphold their principle of confidentiality and integrity by running security tests throughout the lifespan of your product.

-AG

Source: https://www.geeksforgeeks.org/security-testing/

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

Blog #7: Intro to Combinatorial Testing

Beyond Unit Testing, there are several ways one may go about testing a developed system. One of these ways is through combinatorial testing. While researching this topic I’ve seen a couple of steps that I’ve taken in testing that match with this testing method. For example, earlier this semester I learned about how behavior tables can help guide Unit Testing by showing what aspects of a program will be covered by one test. Combinatorial testing achieves a similar effect by first taking all possible inputs (from a pool of predetermined inputs) and then creating a set of tests that will test each unique combination from the pool. A source that helped me grasp this topic is Combinatorial Testing by Shanika Wickramasinghe. In this article, Wickramasinghe provides an example of how they would develop tests. It’s important to note that in this example only combinations are created, NOT permutations, meaning that overall much fewer tests would be needed to fulfill a combinatorial test. This does raise a question for future reading of whether there is such thing as “permutative” testing and how that and combinatorial testing differ.

Using combinatorial testing does provide benefits despite the time it may take to achieve a successful test. Combinatorial tests are all designed to try multiple inputs simultaneously, meaning that both single-fault and multi-fault assumptions will be made in a full combinatorial test. Once these tests are complete, the developer can better understand which inputs cause a problem within their code. Additionally, once the pool of potential inputs is determined, the tester will have a set number of tests they must conduct. These tests may find faults in the program that require specific input that the development team may not have accounted for. Through feedback such as this, the development team can resolve the bug and create ways of handling errors caused by unexpected input. These benefits do come with equally heavy drawbacks. Manual combinatorial testing is possible, however the testers may struggle with creating combinations from a larger input pool. A way this can be solved is by using an automated combinatorial tester. It’s important to note that this can be limited by how intensive the tests are on the hardware of the automated tester. Lastly, the combinations that the test may provide could be so random that it’s nonsensical to test such a thing. This becomes an issue of resources which will vary from developer to developer. Ultimately whether one uses combinatorial testing or not is up to the developer. There are some instances where the cost of conducting one of these tests would be beneficial to the development process, but this is not a “one size fits all” type of test. By using some of the team’s resources, whether it be labor or hardware-bound, combinatorial tests will yield meaningful results as to which areas of the program need further testing.

-AG

Source: https://testsigma.com/blog/combinatorial-testing/

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

Sprint Retrospective

Sprint 3 Retrospective

Introduction

  • In this sprint, our primary focus was on rigorously testing the frontend developed during sprint 2, applying the insights and frameworks we had discussed with team 2. This sprint appeared significantly shorter than the extensive sprint 2, partly due to the lighter workload with a target of only 16 points. This more manageable workload allowed us some capacity to address and rectify lingering issues from the previous sprint.
  • The brevity of this sprint highlighted the importance of continuous integration and testing, which enabled us to quickly identify and resolve issues. Our collaborative efforts with team 2 proved invaluable, as their feedback directly influenced our troubleshooting and refining processes. Moving forward, maintaining this synergy and applying these practices consistently will be crucial for smoothing out any future bumps in our development process and enhancing the overall quality of our project.

Links to Activity on GitLab

Reflections on the Sprint

What Worked Well:

The standout success of this sprint was our group communication. Facing challenges as a team, rather than individually, significantly eased our problem-solving process. Our review procedures were effective, facilitating a focused approach towards achieving our objectives.

Areas for Improvement:

The primary challenge we encountered was time management, particularly as progress on the front end depended on having a working template. This dependency delayed our efforts, resulting in a hectic sprint conclusion. Better planning or earlier template availability might mitigate similar issues in future sprints.

Improvements for Team Performance

The team’s collaborative communication and problem-solving were key strengths this sprint, continuing a positive trend from the previous sprint. It’s crucial to sustain this momentum into the next sprint, incorporating some strategic improvements:

Improvements for the Next Sprint:

  1. Consistent Scheduling: To avoid the congestion experienced towards the end of the last sprint, establishing a more consistent schedule for meetings could help in better time management and distribute tasks more evenly throughout the sprint.
  2. Balanced Division of Labor: We should continue to monitor and adjust the workload among team members to ensure tasks are evenly distributed, preventing any team member from being overwhelmed while others have less to do.
  3. Streamlined Communication Channels: Building on our previous success, maintaining all critical communications in a centralized, organized, and easily accessible system will enhance clarity and continuity, aiding in more effective decision-making and problem-solving.

Personal Improvements

Reflecting on my personal challenges during this sprint, specifically around managing merge requests correctly, I see valuable opportunities for growth:

  1. Proactive Communication: To prevent and swiftly address any uncertainties or errors in my work, I commit to being more proactive in seeking feedback and clarifications from team members.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

This was our third and final sprint for the semester and I believe we improved greatly when it came to working as a team compared to our previous sprints.We completed all of our issues during this sprint as a team during our various meetings which allowed us to collaborate more and learn about the project together. These issues included getting our frontend properly running in gitpod, figuring out which files were needed from guest info frontend and changing the existing scripts as well as updating documentation in order to leave the frontend in a good state for the next team to work on it.

Overall I did not have any trouble with working on any of the issues this sprint and I feel as though our collaboration on the issues helped us complete them more efficiently. The issue we worked on regarding getting the frontend to run in gitpod was straightforward and we were able to complete it without much delay as we were able to effectively reference the guest info frontend as it was already able to run in gitpod. The second issue that we worked on as a team regarding the addition of more frontend files/file structure and changing the scripts also went well and we were able to complete that as a team without any major issues.. The final issue we worked on as a team included updating the documentation which was rather easy to complete as a team as we had good references and experience with documentation between all of us. We had two other issues regarding making a confirm page but we were not able to finish those during the sprint as we did not want to leave unfinished work for the next team to have to deal with.

We did not have many problems during this sprint and I feel as though we all improved and worked together efficiently as a team. We all attended every meeting that we had scheduled and we all contributed directly to the project through code, documentation etc. The more collaborative nature of the work we did this sprint with each issue relying on the previous issues being completed first allowed collaboration to be a vital part of the process as we were able to finish issues in a timely manner when having all of our ideas going towards the completion of each issue. I feel as though we were all able to draw on one another’s strengths when working during this sprint which is something we were lacking slightly in the previous sprints. We also improved even more when it came to usage of Gitlab as we are all more experienced in both gitlab and gitpod now and able to understand the processes used as well as the workflow. The two issues we were unable to complete regarding a confirmation page are set up so that the next team can work on them when they begin their first sprint and we made sure to update the wireframe along with the documentation to provide the best start possible for the next team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/46

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/12

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/48

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/51

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/52

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/49

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

 


In Sprint 3 I worked on finishing the checkinventoryfrontend. With the
shorter time of the sprint, I went to work on fixing an issue I encountered
in the previous sprint where the frontend would only display an error
message saying that there was some problem in the html. At the same time I
was trying to figure out how to get npm to work in the new file structure,
since when I try calling npm in the terminal it kept failing. For the
longest time I couldn’t figure out how to get the frontend to display
correctly, trying all sorts of solutions from moving the package.json file
around to deleting the deprecated yarnlock file. Eventually, I settled on
figuring out how to change the npm files to allow npm to reach the new
frontend folder I made. At some point, Jason asked if there was anything the
rest of the team could work on in checkinventoryfrontend, and I said the
documentation needed to be updated and that nodemon needed to be
implemented. Jason then created a separate branch based on mine called implementing-nodemon, where he changed the package.json and gitpod.yaml files to have nodemon
and other dependencies. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/tree/implementing-nodemon?ref_type=heads


Somehow, over the course of these dependencies being added, the frontend
started working again. The error must have been rooted in one of the
dependencies not working properly, or something to that effect. I looked int
o the changes Jason made, and he added a section to the gitpod.yaml that
would of implemented certain npm dependencies.


https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/997bd2bd2197def31c8ae29efea071f9d07e077f


 Either way I’m just happy to be able to finish up the work in the
frontend. I went into Jason’s branch and cleaned up some of the shell files
so that they work as intended. The frontend-dev-up.sh file needed to use
frontend-dev instead of dev since that is what npm recognises in this repo.
Also, frontend restart needed to use the proper name of frontend-prod-down
and up.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/480596810546e3286f8821d24cafe68bcd0fc1df

Then I started on cleaning up my own work for the next semester. I removed
the branches I had created since they either were redundant or straight up
didn’t work. Then I cleaned some deprecated files out of the implementing
nodemon branch while I was fixing the shell files, like an extra package
json file that was created in the base repo. 

I learned a lot about working with the frontend throughout this sprint, and
the entirety of the semester for that matter. I definitely want to brush up
on how npm works and functions, because I feel like most of my problems stem
from a lack of understanding. I also want to give credit to my team, who
have helped me out more than they realize, especially since I have been
balancing my work and school life. Hopefully the final presentation
represents all of our efforts over the semester.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog

As we conclude Sprint 3, it’s essential to take a moment to reflect on our experiences, the hurdles we overcame, and the knowledge we’ve gathered. This sprint has been a time of significant learning and adjustment, marked by both challenges and achievements that have contributed to our team’s development and cohesion. In this retrospective, we will explore the difficulties we encountered, the lessons we learned, and outline our strategies for future improvement.

One of the primary challenges this sprint was writing test cases for the frontend using Vue.js and Jest. What we anticipated as a routine task turned into a more complex issue due to the nuanced behaviors of Vue components and their interaction with Jest. Initially, our team struggled with the integration of Jest into our existing Vue projects, facing issues with mock dependencies and asynchronous data handling. However, this challenge provided a profound learning opportunity. We dedicated time to in-depth research and team discussions, which enhanced our understanding of both Vue and Jest. This ordeal not only improved our technical skills but also highlighted the importance of persistence and in-depth understanding in tackling software testing.

Another significant aspect that defined Sprint 3 was our collaboration with another team regarding testing strategies. Initially, communication gaps and differing expectations on testing methodologies posed substantial challenges. These issues were exacerbated by our remote working arrangements, which sometimes led to misunderstandings and delays. To address these issues, we implemented more structured communication protocols, including regular joint meetings and shared documentation. This approach not only smoothed out the wrinkles in cooperation but also fostered a stronger relationship between the teams, setting a foundation for more efficient and effective collaboration in future projects.

Despite the hurdles, Sprint 3 has been pivotal for our team’s growth. We’ve sharpened our skills in frontend testing, deepened our understanding of effective cross-team collaboration, and strengthened our adaptability to new tools and environments. Open communication has once again proved to be the bedrock of our success, ensuring that every team member was engaged and that issues were addressed promptly and transparently.

Moving forward, we aim to build on the lessons learned during this sprint. Our focus will be on refining our testing practices further and enhancing our communication strategies with other teams. We plan to conduct workshops to share knowledge and best practices on Vue and Jest, aiming to elevate our collective expertise. Additionally, the establishment of a cross-team “best practices” repository for testing is in the pipeline, which will serve as a central resource to aid in future testing endeavors.

In conclusion, Sprint 3 was a testament to our team’s resilience and capability to adapt to new challenges. We’ve not only navigated through complex technical issues but also improved our collaborative processes, setting a robust precedent for future sprints. With a commitment to continuous improvement and a supportive team environment, we are well-equipped to tackle upcoming challenges and work towards our collective goals. The road ahead is promising, and with our team’s shared dedication, we are poised to continue our journey of growth and success.

Issues addressed during this sprint:
Write test cases for Header.vue
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/51

Get in touch with Team: 01-2 and discuss Frontend Tests and their findings
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/92

From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.