Black Box Testing

URL: https://www.testscenario.com/black-box-testing/

Black box testing is a great tool for improving functionality, identifying issues within the user interface, and, in many cases, it does not require any programming knowledge. It also plays a key role in validating system acceptance, pre-launch stability, security, and third-party integrations. These aspects make black box testing a highly valuable method not only for developers but also for testers and stakeholders.

It offers great advantages when it comes to presenting results to the customer in order to gain approval. Because it follows a more user-oriented approach, black box testing produces results that are of interest to clients and stakeholders. This approach is referred to as Functional Testing. Additionally, black box testing can be used to assess user-friendliness, usability, and reliability—all of which help ensure that the software runs smoothly and provides meaningful feedback. This type of testing is known as Non-Functional Testing.

Regression Testing, another form of black box testing, ensures that new features or updates do not break any existing functionalities. This is especially important when a software release includes significant or breaking changes. User Acceptance Testing (UAT) typically takes place in the final phase of the testing cycle, where end users verify whether the software meets the necessary business requirements before its official release. Lastly, Security Testing serves as a method of vulnerability assessment, aiming to expose a system’s weaknesses and protect it against potential cyber threats.

The main reason I chose this article is because black box testing, to me, always seemed a little meaningless. Why would anyone test something without reading the code? But after reading the article, I realized that developers actually perform this kind of testing quite often—especially in web development. We constantly test various inputs without necessarily diving into the source code. The article also helped me understand that black box testing is an excellent tool for non-developers, allowing them to effectively test and better understand the product without having to read hundreds of lines of code.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Gitlab activity:

The most important thing that worked well during this sprint, as addressed in all of the Team Project Effectiveness Reports, was communication. Our team communicates really well in person, and online after class. We use discord as our primary source of communication and everyone is really prompt in responding, whether it be in regard to simple questions or chronic issues that one of the systems is causing a team member. The use of the issue board in Gitlab improved during Sprint 2, which allowed the team to keep better track of what was happening, and more importantly, getting completed during the sprint. This allowed us to easily showcase our work during the Sprint Review because we were able to just look back at the issue board. 

The primary thing that didn’t work well this sprint was a clear idea of the work that should actually be getting done. Plenty of work was completed, but it was done on a basis that should have been pre-defined. Doing work as we find issues or come up with ideas is not the most efficient way to make beneficial changes to the “InventorySystem – Weight Based” and we need to work on this. 

Establishing stricter goals for the sprints will allow us to complete more meaningful work. This is the biggest change I think that needs to be made as a team. Personally, I think my best traits are ensuring that everyone’s voices are heard, and I’ve gotten positive feedback in this regard, and that my teammates are always informed of the work I’m doing. The team has decided that I should remain scrum master, and to fulfill my role, I will encourage us to define the stricter work goals that I previously mentioned.

Relevant Apprenticeship Pattern:

The pattern I have chosen to describe Sprint 2 is “Rubbing Elbows.” This pattern states that the act of collaboration can be referred to as “rubbing elbows” and if you reach a plateau in your individual abilities, collaborating with others may help you continue making progress. It is obvious that collaboration is taking place as this is a group project, but sometimes it is apparent that team members, myself included, struggle with our own work. I chose this pattern because I noticed the prevalence of it today actually. I was working on updating the design elements of AddInventoryFrontend and couldn’t figure out why my changes weren’t being made in the browser. I would’ve pondered over this issue for more minutes than I’d like to admit, but I “rubbed elbows” with Guilherme and was able to notice that merely a single line of code needed to be changed. Being more aware of this pattern during Sprint 2 probably would have encouraged more pair-programming, the use of the TV, or rubbing of elbows to navigate issues. The work doesn’t have to entirely be done alone. Overall, if stricter goals are defined for work that needs to be done, and we emphasize a greater sense of collaboration in class, Sprint 3 will hopefully reap the most benefits in terms of code contributions compared to Sprints 1 and 2.

Source of pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch04.html?_gl=1*1gf7b0t*_ga*MTQzNTk4ODQ5OC4xNzQ0NzQxNTgz*_ga_092EL089CH*MTc0NDc0MTU4Mi4xLjEuMTc0NDc0MTcyNC40MS4wLjA.#rubbing_elbows

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/merge_requests/14

This is my merge request for my finished task of writing documentation on how to implement and use nodemon for faster, more efficient development.

For Sprint 2, what worked well for me as an individual was being able to use the other pieces of documentation as a reference, and also being able to utilize Markdown’s formatting to give the documentation a clear and understandable look. I had also kept track of my process of installing nodemon with a Google Doc file, which made it immensely easier to retrace my steps and know what worked and what didn’t. Although it was my first time writing documentation, I didn’t feel lost at any points, and I was able to create a set of instructions I felt confident in and proud of.

As a team, we stayed very organized throughout the entire Sprint, keeping track of issues and merge requests as they were posted. Most merge requests were either discussed in-class or over Discord, which helped the other team members understand the changes being made. I feel like we really gelled well as a team, and morale was high, which enabled everyone to feel comfortable with bringing up issues or asking for help. Everyone has been great at completing their fair share of work, both when it comes to the project itself and the Sprint Review presentations. 

On an individual level, what didn’t work well was I felt as if I became distracted at times during class, when I could have been more focused on completing my work. This is something I am actively working on being better at. I could be a bit more productive in-class sometimes, but this is not to say I never get anything done. I also felt as if I wasn’t completely sure about how the documentation should be written, or if the instructions I wrote would be applicable to everyone. This is something I think is okay at this point, but it was a bit of a back-and-forth struggle when it came to making certain decisions.

On a team level, there was not much that did not work well. We’ve improved our communication from last Sprint, and we are getting issues done and merge requests out at a steady pace. I think something we might need to clear ourselves up on are certain issues regarding visuals, but otherwise I think we are in a good spot.

To improve as a team, we should ask either Professor Wurst, the client, or the Visual Identity Team some clarifying questions about our issues (what the visuals of the webpages are supposed to look like, for example). I think we could clean up our Issue Board a bit as well, as it seems a little cluttered with old Issues.

To improve as an individual, I should definitely try and focus a bit more during class. Productivity would increase, and hopefully I could get more done with the time we have left. I could do better in arriving to class on time, as the last couple of classes I was running late and had to search for parking for a long time. 

For this Sprint, not many of the Apprenticeship Patterns apply to me, so I’ve decided to go with “ Rubbing Elbows”. This describes a situation where one feels there are better techniques to the craft that are escaping them. This may not be exactly true, but it seems to be based on the apprentice’s experience and emotions about what they’re working on. It stems from stagnated learning, which can lead to one feeling inferior about their implementation.

I selected this pattern because while I was writing the documentation for implementing nodemon, I felt as if I was overcomplicating the whole process and that there was an easier way to accomplish the same goal. I felt that, realistically, installing nodemon shouldn’t have been too difficult, and that I was using an inferior way to implement it. It relates to my experience during this Sprint because I was feeling inadequate about my work being the “right” approach to implement nodemon.

If I had read the pattern before/during the Sprint, I would have asked another team member to work with me on installing nodemon to see if it was truly as convoluted as I was making it. The other developer might come up with a different solution, which would be a good perspective to have.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

During the second Sprint of this semester, me and my partner Hiercine worked on modifying all of the endpoints within the guestinfosystem backend to accept access tokens that will let the system know if the request comes from someone who is authorized to make that request. In other words, only admins/staff can delete guest information and normal guests cannot.

We had a lot more issues during this Sprint than we did in the previous Sprint. One of the major issues was how this Sprint was handled. We weren’t able to start our work until after one of the other groups finished determining how the tokens would be handled, as they were the ones creating the roles and assigning the tokens. By that point, we were almost halfway through our Sprint. Once they were able to determine how to use the tokens and we communicated with them, we came up with a draft for how to get the endpoints to accept the tokens and sent it to them. However, it turns out that they were using the tokens in a completely different way than we and the professor thought. On top of that, communication on both ends took multiple days just for a simple conversation. We didn’t come up with a solution to this issue during this Sprint, but we are going to continue to work on it and talk to the professor about it during the third and final Sprint.

Another thing we worked on during this Sprint was fixing some of the issues we had with the work from our first Sprint. It turns out that the format we used for the first visit date in the backend is different from the format that they are using in the frontend, so we had to match those formats in order or get them to work and communicate with each other properly.

While we did have a lot of issues during this Sprint, I think that we did a great job working together as a team. Me and Hiercine worked together on our issue all the time, even communicating outside of class in order to talk about potential solutions. On top of that, the rest of the group did a great job communicating with each other whenever needed. At the beginning of each class, we would check how everyone is doing and see if they needed help. Similarly, whenever helped was needed, we didn’t hesitate and asked each other right away. I don’t think we have much to improve upon as a team, however I would like to improve as an individual by doing more research on my own time instead of just in class.

A pattern from the Apprenticeship Patterns book that is relevant to my experience during this Spring is the “Use the Source” pattern. This pattern emphasizes the importance of digging into the actual source code when you’re trying to understand how something works instead of relying on secondhand documentation, assumptions, or waiting for explanations. I selected this patterns because of how Hiercine and I kept having to communicate with another group about how the tokens worked and had a couple misunderstandings, when we could have just looked at the code that was created. The “Use the Source” pattern encourages this behavior, allowing you to understand it yourself.

I think that depending on another group in order to be able to complete our task was the major issue we had during this Sprint. Instead of having us work on the issues at the same time, we should wait until the other group is completely finished.

We haven’t committed or merged anything yet, here is an image showing the draft we have so far checking the role in each endpoint as well as the link to the current issue we are working on.

Link to the issue: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues?show=eyJpaWQiOiIxNDEiLCJmdWxsX3BhdGgiOiJMaWJyZUZvb2RQYW50cnkvY2xpZW50LXNvbHV0aW9ucy90aGVhcy1wYW50cnkvZ3Vlc3RpbmZvc3lzdGVtL2d1ZXN0aW5mb2JhY2tlbmQiLCJpZCI6MTYzNzkwMTc2fQ%3D%3D

The image shows the draft of the code added in the comments:

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.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

Merge request: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/65

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Sprint [2]

During Sprint-2, my focus was on contributing to the tasks assigned to me through GitLab. These tasks included Issue 4 and Issue 2. Both were critical components in ensuring the functionality and reliability of the fake frontend module in the LibreFoodPantry project. As the sprint progressed, I had the opportunity to reflect on the highs, the challenges, and the lessons learned. Here’s my summary of the experience.

Evidence of Activity on GitLab

  • Issue 4: Task to implement functionality improvement in the fake frontend. This required debugging and making updates to enhance module performance.
  • Issue 2: Debugging and addressing existing issues with edge case scenarios in the fake frontend module.

These activities provided me with valuable experience in problem-solving and adapting to unexpected challenges, which were prevalent throughout the sprint.

What Worked Well

One of the key successes during Sprint-2 was the level of collaboration within the team. Regular communication ensured that tasks were clearly defined, and support was readily available when needed. I found that breaking down complex problems into smaller, manageable components made debugging much more efficient. Issue 2, in particular, benefited from this approach, saving considerable time and allowing me to focus on improving code reliability. Additionally, Issue 4 was completed with minimal revisions thanks to the clarity of the requirements and prior preparation.

What Didn’t Work Well

However, Sprint-2 also presented its fair share of challenges. Initially, unfamiliarity with certain aspects of the codebase slowed my progress. The intricate structure of the fake frontend module required extra time to understand before making meaningful contributions. Furthermore, testing processes revealed several edge cases that were not anticipated during planning, leading to some delays in resolving issues. These experiences underscored the importance of early preparation and thorough testing.

Changes to Improve as a Team

Reflecting on the sprint, there are several improvements the team could make to enhance our efficiency:

  1. Knowledge Sharing: Organizing sessions to familiarize team members with the codebase would help reduce delays caused by a lack of understanding.
  2. Proactive Testing: Incorporating more comprehensive testing during the earlier phases of the sprint could catch edge cases sooner.
  3. Clearer Documentation: Providing detailed documentation of tasks and processes can ensure everyone is aligned and reduce ambiguity.

Changes to Improve as an Individual

At a personal level, I identified several areas for growth:

  1. Skill Development: Spending dedicated time learning tools and frameworks used in the project would enhance my ability to tackle tasks with confidence.
  2. Proactive Engagement: Being more proactive in seeking clarification when tasks feel ambiguous would help minimize initial slowdowns.
  3. Time Management: Allocating focused work periods for specific tasks could improve overall productivity.

Apprenticeship Pattern Selection: “Expand Your Bandwidth”

  • Summary: “Expand Your Bandwidth” is a pattern that emphasizes the importance of stepping outside one’s comfort zone to learn new tools, techniques, and frameworks. By actively seeking opportunities to grow, developers can broaden their capabilities and handle more complex challenges.
  • Relevance: This pattern directly relates to my experience during Sprint-2, where unfamiliarity with parts of the codebase initially caused delays. By expanding my bandwidth through dedicated learning, I could address similar tasks more efficiently in the future.
  • Impact on Behavior: If I had read this pattern before Sprint-2, I would have approached the unfamiliar codebase with a proactive mindset, dedicating time to research and practice before diving into the tasks. This preparation could have prevented the slowdowns experienced during the sprint and improved my overall contribution.

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