This week I decided to look up what was going on in the news for software
quality assurance. I found this article about a survey on the future of
quality assurance and found it interesting. The headline was more
specifically about the adoption of A.I. in software testing. I have already
covered some of the potential benefits of the use of A.I. in software
testing, so consider this to be a follow up to that. Keep in mind this
article was written back in December of 2023, so things could have
potentially changed in that time. 

The title of this article states that over 78% of software testers have
adopted A.I. into their testing. This kind of comes as no surprise since
people have been gushing about the new burgeoning technology for a while
now.  The tech industry has made a big effort to adopt A.I. into as
many different fields as possible. The automation of test cases is not a new
subject, but the use of A.I. is a fairly recent addition to the tools
testers have at their disposal. These tools are being implemented in
different sections of the quality assurance process, with an adoption rate
of 51% for test data creation,45% for test automation, 36% for test result
analysis, and 46% for test case formulation. And like I said before, these
are the numbers the end of 2023, who knows what the current numbers
are.

https://www.prnewswire.com/ae/news-releases/ai-adoption-among-software-testers-at-78-reliability-and-skill-gap-the-biggest-challenges-302007514.html

On a side note, the article says that software testers are being involved
much earlier in the development process. This ties in directly with what I
have been learning in class for the past two semesters about sprint
planning. Having testers be there in the sprint planning phase allows to get
the specifications for the test cases earlier than before, but could lead to
test cases without implemented code.

All of this data comes from a survey into the future of quality assurance
by Lambda Test. Some other interesting figures from the survey include
numbers on quality assurance budget and the ratio of QA testers to
developers. Companies, both big and small, seem to see quality assurance as
a valuable part of the software development process, and invest accordingly.
Interestingly, there is also data on the state of testing itself, with a
particularly interesting note about the benchmark for bug identification
being around 10%.

https://www.lambdatest.com/future-of-quality-assurance-survey?utm_source=media&utm_medium=pressrelease&utm_campaign=dec06_kn&utm_term=kn&utm_content=pr

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

This week I decided to look up what was going on in the news for software
quality assurance. I found this article about a survey on the future of
quality assurance and found it interesting. The headline was more
specifically about the adoption of A.I. in software testing. I have already
covered some of the potential benefits of the use of A.I. in software
testing, so consider this to be a follow up to that. Keep in mind this
article was written back in December of 2023, so things could have
potentially changed in that time. 

The title of this article states that over 78% of software testers have
adopted A.I. into their testing. This kind of comes as no surprise since
people have been gushing about the new burgeoning technology for a while
now.  The tech industry has made a big effort to adopt A.I. into as
many different fields as possible. The automation of test cases is not a new
subject, but the use of A.I. is a fairly recent addition to the tools
testers have at their disposal. These tools are being implemented in
different sections of the quality assurance process, with an adoption rate
of 51% for test data creation,45% for test automation, 36% for test result
analysis, and 46% for test case formulation. And like I said before, these
are the numbers the end of 2023, who knows what the current numbers
are.

https://www.prnewswire.com/ae/news-releases/ai-adoption-among-software-testers-at-78-reliability-and-skill-gap-the-biggest-challenges-302007514.html

On a side note, the article says that software testers are being involved
much earlier in the development process. This ties in directly with what I
have been learning in class for the past two semesters about sprint
planning. Having testers be there in the sprint planning phase allows to get
the specifications for the test cases earlier than before, but could lead to
test cases without implemented code.

All of this data comes from a survey into the future of quality assurance
by Lambda Test. Some other interesting figures from the survey include
numbers on quality assurance budget and the ratio of QA testers to
developers. Companies, both big and small, seem to see quality assurance as
a valuable part of the software development process, and invest accordingly.
Interestingly, there is also data on the state of testing itself, with a
particularly interesting note about the benchmark for bug identification
being around 10%.

https://www.lambdatest.com/future-of-quality-assurance-survey?utm_source=media&utm_medium=pressrelease&utm_campaign=dec06_kn&utm_term=kn&utm_content=pr

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

This week I decided to look up what was going on in the news for software
quality assurance. I found this article about a survey on the future of
quality assurance and found it interesting. The headline was more
specifically about the adoption of A.I. in software testing. I have already
covered some of the potential benefits of the use of A.I. in software
testing, so consider this to be a follow up to that. Keep in mind this
article was written back in December of 2023, so things could have
potentially changed in that time. 

The title of this article states that over 78% of software testers have
adopted A.I. into their testing. This kind of comes as no surprise since
people have been gushing about the new burgeoning technology for a while
now.  The tech industry has made a big effort to adopt A.I. into as
many different fields as possible. The automation of test cases is not a new
subject, but the use of A.I. is a fairly recent addition to the tools
testers have at their disposal. These tools are being implemented in
different sections of the quality assurance process, with an adoption rate
of 51% for test data creation,45% for test automation, 36% for test result
analysis, and 46% for test case formulation. And like I said before, these
are the numbers the end of 2023, who knows what the current numbers
are.

https://www.prnewswire.com/ae/news-releases/ai-adoption-among-software-testers-at-78-reliability-and-skill-gap-the-biggest-challenges-302007514.html

On a side note, the article says that software testers are being involved
much earlier in the development process. This ties in directly with what I
have been learning in class for the past two semesters about sprint
planning. Having testers be there in the sprint planning phase allows to get
the specifications for the test cases earlier than before, but could lead to
test cases without implemented code.

All of this data comes from a survey into the future of quality assurance
by Lambda Test. Some other interesting figures from the survey include
numbers on quality assurance budget and the ratio of QA testers to
developers. Companies, both big and small, seem to see quality assurance as
a valuable part of the software development process, and invest accordingly.
Interestingly, there is also data on the state of testing itself, with a
particularly interesting note about the benchmark for bug identification
being around 10%.

https://www.lambdatest.com/future-of-quality-assurance-survey?utm_source=media&utm_medium=pressrelease&utm_campaign=dec06_kn&utm_term=kn&utm_content=pr

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

This week I decided to look up what was going on in the news for software
quality assurance. I found this article about a survey on the future of
quality assurance and found it interesting. The headline was more
specifically about the adoption of A.I. in software testing. I have already
covered some of the potential benefits of the use of A.I. in software
testing, so consider this to be a follow up to that. Keep in mind this
article was written back in December of 2023, so things could have
potentially changed in that time. 

The title of this article states that over 78% of software testers have
adopted A.I. into their testing. This kind of comes as no surprise since
people have been gushing about the new burgeoning technology for a while
now.  The tech industry has made a big effort to adopt A.I. into as
many different fields as possible. The automation of test cases is not a new
subject, but the use of A.I. is a fairly recent addition to the tools
testers have at their disposal. These tools are being implemented in
different sections of the quality assurance process, with an adoption rate
of 51% for test data creation,45% for test automation, 36% for test result
analysis, and 46% for test case formulation. And like I said before, these
are the numbers the end of 2023, who knows what the current numbers
are.

https://www.prnewswire.com/ae/news-releases/ai-adoption-among-software-testers-at-78-reliability-and-skill-gap-the-biggest-challenges-302007514.html

On a side note, the article says that software testers are being involved
much earlier in the development process. This ties in directly with what I
have been learning in class for the past two semesters about sprint
planning. Having testers be there in the sprint planning phase allows to get
the specifications for the test cases earlier than before, but could lead to
test cases without implemented code.

All of this data comes from a survey into the future of quality assurance
by Lambda Test. Some other interesting figures from the survey include
numbers on quality assurance budget and the ratio of QA testers to
developers. Companies, both big and small, seem to see quality assurance as
a valuable part of the software development process, and invest accordingly.
Interestingly, there is also data on the state of testing itself, with a
particularly interesting note about the benchmark for bug identification
being around 10%.

https://www.lambdatest.com/future-of-quality-assurance-survey?utm_source=media&utm_medium=pressrelease&utm_campaign=dec06_kn&utm_term=kn&utm_content=pr

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

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

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

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

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

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

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

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

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

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

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

   Last week I started diving into the perpetual learning section of the
Apprenticeship patterns book, beginning with the expand your bandwidth
section. I talked about how I want to learn more about my field and explore
new discoveries in the industry. This time however I read up on the “Break
Your Toys” section from the book. This section covers the need to fail in
order to improve, and how to set up an environment where you can sort of
fail on purpose.

I am no stranger to failing and struggling when it comes to computer
programming, as I am sure we all are familiar with it. This section makes a
case for using a pet project, or a “toy program” as they put it, to test and
break to your heart’s content. This is supposed to allow you an environment
in which to practice whatever programming you desire, and most importantly
an environment to fail in. Failure in your job usually leads to you losing
the respect of your peers at best, or losing your job at worst. This is not
an environment where you can make mistakes comfortably, and mistakes are
necessary for growth. 

So basically the section is telling us to make a side project where we can
mess up all we want, and learn from it. Pretty basic advice, but it can go a
long way to making you a better programmer. In fact, it is a piece of advice
I have already implemented in other parts of my life. As a hobby, I build
and paint plastic miniatures, and use them in tabletop games. Recently I
have become much more focused on improving my painting skills. As a result,
I have taken up several side projects where I can experiment with different
painting techniques. I even keep around spare models to use as test
subjects. Not all of these projects pan as I would like them to, but that is
part of what makes them appealing to me. It allows me to fool around and try
new things, without the risk of failure being an impediment. Back in the
book they suggest maintaining a wiki as a way to practice without worry.
Personally, I am thinking of fooling around in some game engines as a way to
practice.

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