I find the assertion that one is never done learning to be very true
to life. One’s skills as a software developer should be iterated upon just
like the very programs we craft. The section on perpetual learning
provided  many interesting examples of ways to tackle improving one’s
own knowledge base and skillset. I want to cover some of my favorite
sections in this blog post and over the course of the next couple blog
posts.

Expand Your Bandwidth

I constantly get the feeling that my knowledge in my career is always much
shallower than it should be. The suggestions provided at the start with
Google Reader and following software luminaries seemed interesting, but I
was much more interested in looking at online courses and podcasts. I want
to be able to constantly expand my knowledge base and explore new
horizons.  This reminds me of when I was keeping up to date with a
subreddit that was all about mesh networks and peer-to-peer computing. It
sprung up in the aftermath of network neutrality being struck down, and a
lot of people on there were proposing creating a giant open source mesh
network to combat predatory internet service providers. It had the overly
ambitious goal of decentralizing the internet which ,suffice to say, has not
come to pass yet, although I’ve heard that the emergent Web 3.0 is supposed
to be it. I was fascinated by the ingenuity of using a bunch of Raspberry
Pis to create mesh networks all around a city. I want to reignite some of my
passion for obtaining new knowledge and explore what is new today. I know
A.I. has gotten a lot of publicity, to the point of becoming something like
a buzzword, but I want to see what the other sectors of the tech industry
are working on. Thanks to writing this blogpost I went and looked to find
new sources of information. I even started perusing reddit, specifically in
the technology and programming tag,  again to search for any new and
interesting developments. I have already checked out the r/webdev amd
r/learnprogramming for some tips.

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

 I find the assertion that one is never done learning to be very true
to life. One’s skills as a software developer should be iterated upon just
like the very programs we craft. The section on perpetual learning
provided  many interesting examples of ways to tackle improving one’s
own knowledge base and skillset. I want to cover some of my favorite
sections in this blog post and over the course of the next couple blog
posts.

Expand Your Bandwidth

I constantly get the feeling that my knowledge in my career is always much
shallower than it should be. The suggestions provided at the start with
Google Reader and following software luminaries seemed interesting, but I
was much more interested in looking at online courses and podcasts. I want
to be able to constantly expand my knowledge base and explore new
horizons.  This reminds me of when I was keeping up to date with a
subreddit that was all about mesh networks and peer-to-peer computing. It
sprung up in the aftermath of network neutrality being struck down, and a
lot of people on there were proposing creating a giant open source mesh
network to combat predatory internet service providers. It had the overly
ambitious goal of decentralizing the internet which ,suffice to say, has not
come to pass yet, although I’ve heard that the emergent Web 3.0 is supposed
to be it. I was fascinated by the ingenuity of using a bunch of Raspberry
Pis to create mesh networks all around a city. I want to reignite some of my
passion for obtaining new knowledge and explore what is new today. I know
A.I. has gotten a lot of publicity, to the point of becoming something like
a buzzword, but I want to see what the other sectors of the tech industry
are working on. Thanks to writing this blogpost I went and looked to find
new sources of information. I even started perusing reddit, specifically in
the technology and programming tag,  again to search for any new and
interesting developments. I have already checked out the r/webdev amd
r/learnprogramming for some tips.

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

  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.

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

  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.

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

  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.

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

  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.

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

  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.

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

  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.

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

  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.

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

  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.

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