For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

 For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

 For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

 For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

 For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

 For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

 For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

 For my last blog post for this class, I found an article online that
talks about the practice of shifting-left in software quality assurance.
This approach more or less emphasizes the importance of introducing quality
assurance to earlier phases in the development process. Testing from the
initial phase of development is supposed to prevent the amount of defects
and issues from piling up at the end of development. Having testing done
throughout the development phases can also lessen the workload for the
quality assurance team.

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.

For my final blog post for my Software Testing course, I wanted to go over something that also ties with other projects I’ve been working on during this semester in some way. In our Softawre Development Capstone team, we’ve had a couple of issues where we’ve had to touch upon the Thea’s Pantry continuous integration system through GitLab to have linter tests run automatically when pushing commits, so that commits that don’t match up to specification, the pipeline fails and the person who pushed those changes gets notified to fix any issues that arise. In this post, I want to go over a bit more detail about what continuous integration is and how it’s useful for developers.

According to Stephen Roddewig’s blog post on HubSpot, contiguous integration is an approach to development where code changes are regularly merged into a shared repository, built into a test application automatically, and the results of running this test application go back to the developer if any bugs or defects are found.

In practice, a continuous integration tool typically is an automated system where the source code is compiled with tests being automatically run on every individual push from a developer. This means that the developer’s contribution to the project is automatically tested on push, then either pushed forward to the maintainers or pushed back as a result of a pipeline failure.

The benefit of this is clear: bugs are caught quicker, the source code is updated on a regular basis with greater confidence because of the automated tests, and the pipeline provides an explicit and clear vision of what the specifications are for the project.

While working with the Thea’s Pantry system for my capstone, I could see these benefits in action. If a developer forgets to run tests locally (in the case of the Thea’s Pantry system, all tests are run in a script, and linters are run in their own script as well), the pipeline will catch any problems seamlessly, and the developer can easily see the pipeline failure, look at the output on GitLab, and determine what they need to fix in their branch.

In addition, it clarifies the specifications of what commits should look like, and what code should look like as well, on the basis that you can even add linters to the pipeline. It’s very useful in case someone forgets that we use conventional commits to have our changes be more clear with what they do, as the pipeline will detect that and function as a reminder of what things should look like.

All around, continuous integration is always a benefit for everyone involved in the software development process, creating a smooth system for testing that functions automatically rather than requiring developers to remember to run tests so they don’t mess up their branch.

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

The blog post titled “Pairwise Testing: A Complete Guide” by Rajkumar (https://www.softwaretestingmaterial.com/pairwise-testing/) delves into the concept of pairwise testing, also known as all-pairs testing. I chose this blog because of its in-depth examples of  how to implement pairwise testing. These examples really made it easier to understand how pairwise testing can be used to reduce the amount of test cases while still maintaining high test coverage. The post also outlines the importance of pairwise testing and its advantages. Additionally, it compares pairwise testing with other testing techniques, highlights tools available for automating pairwise testing, and discusses its application in various scenarios.

What is Pairwise Testing?

Pairwise testing is a black-box testing technique used to reduce the number of test cases while still maintaining high test coverage. By focusing on combinations of input pairs, pairwise testing ensures that all possible pairs of input parameters are tested at least once. For example, if you had a program that took three inputs, X, Y, and Z, pairwise testing would create test cases for each combination of input pairs: (X, Y), (X,Z), and (Y,Z). At first glance this may seem like you have to create a ridiculous amount of test cases, but by following the steps for pairwise testing you can see how quickly the number of test cases is reduced.

Applying Pairwise Testing

The first step of pairwise testing is to identify all of your input variables. Next list all possible values for each variable. Variables that have numeric values may be reduced to valid and invalid to begin reducing the number of test cases needed. Then, by creating a table content columns of each variable and its possible outputs, you can get a list of each test case. 

This blog’s examples use tables to illustrate how each test case is created by filling in each column one by one.

The example from the blog uses a bookstore and creates a table of every variable. In this example you can see how each pair of variables covers all unique combinations except the book category and enquiry. These variables only test fiction with valid and non fiction with invalid. The other columns fixed this by simply reversing the order of one of the test pairs, but doing this would create the same issue for another combination of variables. In this instance two more test cases are added to the list to ensure the unique combination of book category and enquiry.

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