Regression Testing
While looking for something that I could use for my 5th homework, I started looking into other software testing styles that we have not covered in class. There are tons of different styles that are implemented to introduce quality testing to software development. One such style I found this time is called regression testing, a testing style created to combat resurfacing bugs. Basically, regression testing is about implementing test cases every update, and maintaining them throughout future iterations. This is done to prevent old bugs from resurfacing and to check for any new bugs from being introduced in every update. Test cases should be created and implemented after every iteration to prevent bugs from piling up within your software.
https://www.browserstack.com/guide/regression-testing
While this may sound a lot like retesting , the main difference is that regression testing looks for unknown bugs rather than known. How this may look is the test cases are not for any specific bug but rather more general to catch any problems that came about during the last change. Other differences include the fact that regression testing can be automated, while Retesting cannot. In order to remain vigilant, one should implement both of these styles in order to avoid any problems from implementing new changes.
https://www.browserstack.com/guide/retesting-vs-regression-testing
Some examples that I saw listed of regression testing tools include Cypress, Playwright, and Puppeteer. These tools typically ensure that your software and test cases work across different platforms and operating systems. Last post I talked about how I found a website that uses A.I. to write test cases, and considering how regression is already inclined to be automated, I can’t help but wonder how long we have until we see an entirely automated software development pipeline using regression testing. I think it’s not too far in our futures.
In the article I linked above they give some examples of some regression test cases. They use the classic shopping cart program and the test cases are things like making sure the back end fetches the correct number of items in the cart, or checking if the elements on the front end are still visible despite scrolling down. These cases are general enough to catch both new and old bugs on subsequent updates. For the Mars Rover kata we did in class an example I could use would be updating the grid to be 100 squares big in each direction, and then creating a new test case to check if it still wraps around at the 99 mark.
Comments
Post a Comment