One of the biggest things that we finished from last sprint was that we were to got AddInventoryFrontend working. Last sprint was very difficult because the code that we were working on was messy and we had to change a few different approaches to the Frontend since our original approach to create a wireframe which would eventually become the UI did not come together. For this sprint, we had updated our code to be able to finally string together the Frontend with the Backend, like changing around our directory, adding in key files to run the Frontend, and then test through trial and error our Frontend. We used our current wireframe in order to build our Frontend to what we ended up with.

For AddInventoryFrontend, I had worked on updating the Documentation of AddInventoryFrontend since I wanted to be able to contribute more in this sprint. When I looked at the documentation in its original state, I was dumbfounded to find that there were almost nothing there to begin with. It must have looked liked a template since it specified that the linter being used was called test.sh instead of lint.sh. Because everyone on my team was doing so much work on the Frontend and its functionality, I wanted to be able to contribute more as a member of the team, so I decided to modify the documentation so that it would reflect the changes that we made as as a team.

Unfortunately, we were unable to completely fix some issue that we had with our Frontend before the end of the sprint. Our Frontend works great and loads properly now that we have fixed it. If we had another sprint left before the end of the semester, we would have worked on optimizing our Frontend so that the button could work so that you can add and remove units of food from the inventory, and also keep track of how much food is in the inventory through a viewable parameter that would check in the database for the inventory amount. With that being said, any issues that we had with AddInventoryFrontend will have to be resolved next year.

As a member of our team, I definitely could work on trying to practicing some code so that I would be able to make changes that they made with the Frontend. The Frontend was not impossible for me to read since I have played around with HTML before, but I was still trying to figure out all the formatting for our Frontend so I took a good look at our code. I could tell that at the very least that we did our best with creating the Frontend with the little time that we had following our previous sprint, but I would like to not forget about the things we did as a team to create our Frontend. I think that I better understand how AddInventoryFrontend works because I did run the environment on my own. For our presentation, I really hope that we can talk more about how we got our Frontend to work rather than just listing out the issues that we did in our sprint.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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

https://hackernoon.com/embracing-the-shift-left-approach-revolutionizing-quality-assurance-in-software-development

According to the article, the cost of testing and post-production vastly
outweighs the cost of development and planning. It posits that testing
earlier and more frequently catches bugs earlier on, and reduces the overall
cost of development. This goes very hand in hand with the agile software
development methodology we learned about last semester. The world of
software development has become much more fast paced, and the current
landscape pushes for finished products with minimal defects at
launch. 

I  have seen online the mentality that a product that ships with any
problems is often ostracized. Consumers want minimal issues and problems
when interacting with any kind of software, and that goes doubly for large
companies. Having software testers involved since the start of development
would allow teams a more seamless development experience.

One model for development that the article proposes has each stage of
development separated by a quality check gate, in which test cases are
implemented. When all defects are found and fixed, only then can the
development team move on to the next stage of the process. I think this a
very good system that could fit well within the agile sprint methodology.
Leave time at the end of the sprint, but before the sprint retrospective,
for the quality assurance team to check the code, then at the retrospective
they can sign off on the state of the project. If there are any bugs that
could not be fixed within this sprint, the testers can assign it as an issue
for the next one. 

During the Development Capstone project, this could be used to manage the
teams next semester. Have team members focus on quality assurance near the
end of the sprint, and then collect their feedback at the sprint
retrospective. Another way would be to have one or two teams act as quality
assurance throughout the whole semester. Either way it could save a bit of
headaches for everyone.

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