To round out my semester, before beginning my summer research opportunity, I looked into extraneous material for my classes as I finish up. In looking for a blog for the final week of finals, I went with something more akin to basic general information regarding testing. I selected an article based around the common mistakes or sins in mobile testing. This connected with my most recent final project for another class regarding mobile development. I struggled to test my project for this class, and I am sure I committed many of these sins. The article’s title is Five Sins of Mobile Testing by Josh Galde

This article is quite dated, and Galde begins with describing the demand for mobile devices, which has since skyrocketed. Companies at the time aimed to expand their web presence to mobile platforms, but often overlooked the constraints, leading to rushed development and potential errors. This is something I experienced in my own project, having trouble with the visual aspect of app development. The necessity to develop multiple versions of the same app to accommodate different devices and configurations. Is something of an issue outlined by Galde, and one I experienced when switching between different size devices. This is similar to a non-responsive website in web development. Glade explains that to create successful, user-friendly, and reliable mobile apps, we should follow the best practices and avoid common mistakes, or “sins,”. The first sin is relying solely on emulation software, as problematic because emulators can’t fully replicate real device behavior, especially with carrier networks.This is something I experienced through only emulator testing. The second sin is using jail broken devices, which can alter their functionality, leading to inaccurate testing results. The third sin is not utilizing automation. Automated testing can save time and reduce errors by efficiently handling the repetitive testing process across multiple devices and platforms, which might be tedious to do individually. The fourth sin is ignoring the need to support internal apps. This can be a dangerous error for applications developed for businesses, as it ignores the possibility of employees or members utilizing their own devices for organization apps. And one of the most egregious, and fifth sin is skipping testing on real devices. This is a common but risky practice, rushing app development without thorough testing. This can lead to catastrophic failures in the app. Proper testing is critical to ensure app reliability and success.

At the end of the semester, reflecting on my learning is paramount to actually achieve a change in how I think. My final project presentation just ended a week ago, and already I reflect on mistakes and poor practices to improve going forward. These sins are many I have committed and will now avoid going forward to improve as a programmer.

Source:https://www.stickyminds.com/article/five-sins-mobile-testing

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

My second post this week will recover the three elements of unit testing: Boundary Value Testing, Equivalence Class Testing, and Decision Table-Based Testing. Each play a crucial role in validating software behavior and functionality. Boundary Value Testing focuses on the edges of input ranges. This technique identifies defects at the boundaries of input domains, where errors are most likely to occur. By testing the minimum, maximum, and edge values, testers can catch issues that might arise from off-by-one errors or other boundary-related bugs. This method is particularly effective because boundary conditions are common sources of defects in software applications. To utilize boundary value testing, first determine the minimum and maximum values for each input field, and second create test cases that include the boundary values (e.g., minimum, maximum, just inside, and just outside the boundaries).

Equivalence Class Testing divides input data into equivalent partitions, or classes, where test cases are expected to produce similar results. Instead of testing every possible input, testers select representative values from each class, significantly reducing the number of test cases needed. This method ensures that different inputs within the same class are treated equally by the software, helping identify any inconsistencies or unexpected behaviors across various input ranges. To utilize equivalence class testing, first group input values that are treated similarly by the system into classes, and second choose one representative value from each class for testing.

Decision Table-Based Testing involves creating a table that maps different input conditions to their corresponding actions or outputs. This technique is especially useful for testing complex business logic and decision-making processes. By systematically covering all possible combinations of inputs and their respective outcomes, decision tables help ensure that all scenarios are accounted for and validated. This method enhances the thoroughness of testing by providing a clear and structured approach to handling diverse input conditions. To utilize decision table-based testing, first list all possible conditions (inputs) and actions (outputs), and second create a table with all possible combinations of conditions and their corresponding actions.

Boundary Value Testing, Equivalence Class Testing, and Decision Table-Based Testing are powerful techniques that enhance the effectiveness and efficiency of software testing. These testing techniques help ensure that software applications are robust, reliable, and capable of handling various input scenarios effectively. By incorporating these methods into your testing strategy, you can enhance test coverage, identify potential issues early, and deliver high-quality software that meets user expectations and business requirements.

Blog Post: https://celestialsys.com/blogs/software-testing-boundary-value-analysis-equivalence-partitioning/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu 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.