Author Archives: c-braley

Tackling your to-do list

Ok so this week I found a blog that was fairly insightful to me. It was on tackling a to do list. I find that I have a hard time at this and I think it is partly because my mind wanders around and I get an idea or thought and next thing I know I am off to the races on something completely different than what I was just doing. So this guy talks about 8 strategies to help getting your list done and I think I am going to try and put this into practice.
1       Priority
The idea is this, the whole list is not a priority and just doing the things on the list and marking them as done does not necessarily determine your progress, focus on priorities.
2       No second thoughts
Do not overthink things or starting your project. Jump right in and get it going. This is by far one of my not so good qualities, I tend to overthink everything and make it far more difficult than it needs to be.
3       Limit distractions
This is another biggie for me as I can easily get sidetracked. Focus on the task at hand. Whatever that something is that is distracting you now can be taken care of later.
4       Learn from mistakes
I am a proponent of this and I think it is key no matter what environment. Mistakes are unavoidable, it’s what you do with them or about them that counts. Learn from them and move on.
5       Set a short-term goal
Making a goal helps to force us to get things done.
6       Break big activities into small pieces
Do not overwhelm yourself because of the size of the task, big problems are best solved by breaking them down into smaller, easier manageable tasks.
7       Fire the perfectionist
Do not demand perfection because rarely if ever is it going to be or ever will be perfect. He quotes Voltaire who warned against letting the perfect be the enemy of the good. You will never make a perfect decision.
8       Think about it
Very important. Replace counterproductive thoughts with positive ones that help motivate and keep you on track.
Links:
http://www.franksonnenbergonline.com/posters/8-ways-to-tackle-your-to-do-list/
http://qahiccupps.blogspot.nl/2016/11/the-anatomy-of-definition-of-testing.html
https://testkeis.wordpress.com/2016/11/14/back-end-and-front-end-validations/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
http://blog.coverity.com/2014/11/14/dissecting-19-year-old-bug/
https://testkeis.wordpress.com/2016/11/14/some-basic-stuff/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Tackling your to-do list

Ok so this week I found a blog that was fairly insightful to
me. It was on tackling a to do list. I find that I have a hard time at this and
I think it is partly because my mind wanders around and I get an idea or
thought and next thing I know I am off to the races on something completely
different than what I was just doing. So this guy talks about 8 strategies to
help getting your list done and I think I am going to try and put this into
practice.
1       Priority
The idea is this, the whole list is not a
priority and just doing the things on the list and marking them as done does
not necessarily determine your progress, focus on priorities.
2       No second thoughts
Do not overthink things or starting your
project. Jump right in and get it going. This is by far one of my not so good
qualities, I tend to overthink everything and make it far more difficult than
it needs to be.
3       Limit distractions
This is another biggie for me as I can
easily get sidetracked. Focus on the task at hand. Whatever that something is
that is distracting you now can be taken care of later.
4       Learn from mistakes
I am a proponent of this and I think it is
key no matter what environment. Mistakes are unavoidable, it’s what you do with
them or about them that counts. Learn from them and move on.
5       Set a short-term goal
Making a goal helps to force us to get
things done.
6       Break big activities into small pieces
Do not overwhelm yourself because of the
size of the task, big problems are best solved by breaking them down into
smaller, easier manageable tasks.
7       Fire the perfectionist
Do not demand perfection because rarely if
ever is it going to be or ever will be perfect. He quotes Voltaire who warned
against letting the perfect be the enemy of the good. You will never make a
perfect decision.
8       Think about it
Very important. Replace counterproductive
thoughts with positive ones that help motivate and keep you on track.
Links:
http://www.franksonnenbergonline.com/posters/8-ways-to-tackle-your-to-do-list/
http://qahiccupps.blogspot.nl/2016/11/the-anatomy-of-definition-of-testing.html
https://testkeis.wordpress.com/2016/11/14/back-end-and-front-end-validations/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
http://blog.coverity.com/2014/11/14/dissecting-19-year-old-bug/
https://testkeis.wordpress.com/2016/11/14/some-basic-stuff/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Tackling your to-do list

Ok so this week I found a blog that was fairly insightful to
me. It was on tackling a to do list. I find that I have a hard time at this and
I think it is partly because my mind wanders around and I get an idea or
thought and next thing I know I am off to the races on something completely
different than what I was just doing. So this guy talks about 8 strategies to
help getting your list done and I think I am going to try and put this into
practice.
1       Priority
The idea is this, the whole list is not a
priority and just doing the things on the list and marking them as done does
not necessarily determine your progress, focus on priorities.
2       No second thoughts
Do not overthink things or starting your
project. Jump right in and get it going. This is by far one of my not so good
qualities, I tend to overthink everything and make it far more difficult than
it needs to be.
3       Limit distractions
This is another biggie for me as I can
easily get sidetracked. Focus on the task at hand. Whatever that something is
that is distracting you now can be taken care of later.
4       Learn from mistakes
I am a proponent of this and I think it is
key no matter what environment. Mistakes are unavoidable, it’s what you do with
them or about them that counts. Learn from them and move on.
5       Set a short-term goal
Making a goal helps to force us to get
things done.
6       Break big activities into small pieces
Do not overwhelm yourself because of the
size of the task, big problems are best solved by breaking them down into
smaller, easier manageable tasks.
7       Fire the perfectionist
Do not demand perfection because rarely if
ever is it going to be or ever will be perfect. He quotes Voltaire who warned
against letting the perfect be the enemy of the good. You will never make a
perfect decision.
8       Think about it
Very important. Replace counterproductive
thoughts with positive ones that help motivate and keep you on track.
Links:
http://www.franksonnenbergonline.com/posters/8-ways-to-tackle-your-to-do-list/
http://qahiccupps.blogspot.nl/2016/11/the-anatomy-of-definition-of-testing.html
https://testkeis.wordpress.com/2016/11/14/back-end-and-front-end-validations/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
http://blog.coverity.com/2014/11/14/dissecting-19-year-old-bug/
https://testkeis.wordpress.com/2016/11/14/some-basic-stuff/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Tackling your to-do list

Ok so this week I found a blog that was fairly insightful to
me. It was on tackling a to do list. I find that I have a hard time at this and
I think it is partly because my mind wanders around and I get an idea or
thought and next thing I know I am off to the races on something completely
different than what I was just doing. So this guy talks about 8 strategies to
help getting your list done and I think I am going to try and put this into
practice.
1       Priority
The idea is this, the whole list is not a
priority and just doing the things on the list and marking them as done does
not necessarily determine your progress, focus on priorities.
2       No second thoughts
Do not overthink things or starting your
project. Jump right in and get it going. This is by far one of my not so good
qualities, I tend to overthink everything and make it far more difficult than
it needs to be.
3       Limit distractions
This is another biggie for me as I can
easily get sidetracked. Focus on the task at hand. Whatever that something is
that is distracting you now can be taken care of later.
4       Learn from mistakes
I am a proponent of this and I think it is
key no matter what environment. Mistakes are unavoidable, it’s what you do with
them or about them that counts. Learn from them and move on.
5       Set a short-term goal
Making a goal helps to force us to get
things done.
6       Break big activities into small pieces
Do not overwhelm yourself because of the
size of the task, big problems are best solved by breaking them down into
smaller, easier manageable tasks.
7       Fire the perfectionist
Do not demand perfection because rarely if
ever is it going to be or ever will be perfect. He quotes Voltaire who warned
against letting the perfect be the enemy of the good. You will never make a
perfect decision.
8       Think about it
Very important. Replace counterproductive
thoughts with positive ones that help motivate and keep you on track.
Links:
http://www.franksonnenbergonline.com/posters/8-ways-to-tackle-your-to-do-list/
http://qahiccupps.blogspot.nl/2016/11/the-anatomy-of-definition-of-testing.html
https://testkeis.wordpress.com/2016/11/14/back-end-and-front-end-validations/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
http://blog.coverity.com/2014/11/14/dissecting-19-year-old-bug/
https://testkeis.wordpress.com/2016/11/14/some-basic-stuff/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Tackling your to-do list

Ok so this week I found a blog that was fairly insightful to
me. It was on tackling a to do list. I find that I have a hard time at this and
I think it is partly because my mind wanders around and I get an idea or
thought and next thing I know I am off to the races on something completely
different than what I was just doing. So this guy talks about 8 strategies to
help getting your list done and I think I am going to try and put this into
practice.
1       Priority
The idea is this, the whole list is not a
priority and just doing the things on the list and marking them as done does
not necessarily determine your progress, focus on priorities.
2       No second thoughts
Do not overthink things or starting your
project. Jump right in and get it going. This is by far one of my not so good
qualities, I tend to overthink everything and make it far more difficult than
it needs to be.
3       Limit distractions
This is another biggie for me as I can
easily get sidetracked. Focus on the task at hand. Whatever that something is
that is distracting you now can be taken care of later.
4       Learn from mistakes
I am a proponent of this and I think it is
key no matter what environment. Mistakes are unavoidable, it’s what you do with
them or about them that counts. Learn from them and move on.
5       Set a short-term goal
Making a goal helps to force us to get
things done.
6       Break big activities into small pieces
Do not overwhelm yourself because of the
size of the task, big problems are best solved by breaking them down into
smaller, easier manageable tasks.
7       Fire the perfectionist
Do not demand perfection because rarely if
ever is it going to be or ever will be perfect. He quotes Voltaire who warned
against letting the perfect be the enemy of the good. You will never make a
perfect decision.
8       Think about it
Very important. Replace counterproductive
thoughts with positive ones that help motivate and keep you on track.
Links:
http://www.franksonnenbergonline.com/posters/8-ways-to-tackle-your-to-do-list/
http://qahiccupps.blogspot.nl/2016/11/the-anatomy-of-definition-of-testing.html
https://testkeis.wordpress.com/2016/11/14/back-end-and-front-end-validations/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
http://blog.coverity.com/2014/11/14/dissecting-19-year-old-bug/
https://testkeis.wordpress.com/2016/11/14/some-basic-stuff/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Whether or not to use old test data

This week I read a great blog on starting from scratch or using old test documentation. The writer formed the blog based on a question asked by one of his fellow testers, “How can I find old test documentation for a completed feature so I can re-use those test on a similar new feature?”.
My initial thought was that’s actually not a bad idea, but the more I read the more I was swayed and started thinking about times when I was either asked about a similar situation or posed the same question. Though I wasn’t software testing at the time nor even in the industry this can be applied to other scenarios as well.
While I do think that it is a good idea to track and refer to past tests to see what has been done, I agree with the writer that “a skilled tester can usually come up with better tests…today, from scratch.” He makes many valid points and I will go over a couple that I thought to me stood out, you can read the blog to get the rest if you’d like.
  • ·         A skilled tester knows more about testing today than they did last month.

         How true. The more you do something the more you learn about it and the better you become at          it.
  • The product-under-test is different today than it was last month.  It might have new code, refactored code, more users, more data, a different reputation, a different platform, a different time of the year, etc.

          As the development process moves through the different iterations, things change. Looking at             past tests may help, but more probably than not it will probably slow you down. You have first           locate the tests that were done and figure out what the tester was thinking if it wasn’t you, and             then try and decide whether or not it even applies to the new code. By the time you figure that             stuff out I would imagine you could have written several test cases according to the latest                     iteration.

  • The test environment might be different.

          This is true as well, things seemingly change frequently so you may have changed the                         environment and once again wasting time seeing what you or someone else did.

The bottom line here is that while in some cases the old data may help, but more than likely it will, in my opinion slow you down. One more thing I think can happen is can stagnate your thought process as you are looking at old ideas instead of coming up with new ideas.
http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/03/couple-automated-checks-with-product.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/02/automated-checking-is-very-human.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.softwaretestingmagazine.com/knowledge/how-to-give-better-code-reviews/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29
http://www.developsense.com/blog/2016/05/testers-dont-prevent-problems/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Whether or not to use old test data

This week I read a great blog on starting from scratch or
using old test documentation. The writer formed the blog based on a question
asked by one of his fellow testers, “How can I find old test documentation for
a completed feature so I can re-use those test on a similar new feature?”.
My initial thought was that’s actually not a bad idea, but
the more I read the more I was swayed and started thinking about times when I
was either asked about a similar situation or posed the same question. Though I
wasn’t software testing at the time nor even in the industry this can be
applied to other scenarios as well.
While I do think that it is a good idea to track and refer
to past tests to see what has been done, I agree with the writer that “a
skilled tester can usually come up with better tests…today, from scratch.” He
makes many valid points and I will go over a couple that I thought to me stood
out, you can read the blog to get the rest if you’d like.
  • ·        
    A skilled tester knows more about testing today
    than they did last month.

         How true. The more you do something the
more you learn about it and the better you become at          it.
  • The product-under-test is different today than
    it was last month.  It might have new code, refactored code, more users,
    more data, a different reputation, a different platform, a different time of
    the year, etc.

          As the development process moves through
the different iterations, things change. Looking at             past tests may help, but
more probably than not it will probably slow you down. You have first           locate
the tests that were done and figure out what the tester was thinking if it wasn’t
you, and             then try and decide whether or not it even applies to the new code. By
the time you figure that             stuff out I would imagine you could have written
several test cases according to the latest                     iteration.

  • The test environment might be different.

          This is true as well, things seemingly change
frequently so you may have changed the                         environment and once again wasting time
seeing what you or someone else did.

The bottom line here is that while in some cases the old
data may help, but more than likely it will, in my opinion slow you down. One
more thing I think can happen is can stagnate your thought process as you are
looking at old ideas instead of coming up with new ideas.
http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/03/couple-automated-checks-with-product.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/02/automated-checking-is-very-human.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.softwaretestingmagazine.com/knowledge/how-to-give-better-code-reviews/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29
http://www.developsense.com/blog/2016/05/testers-dont-prevent-problems/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Whether or not to use old test data

This week I read a great blog on starting from scratch or
using old test documentation. The writer formed the blog based on a question
asked by one of his fellow testers, “How can I find old test documentation for
a completed feature so I can re-use those test on a similar new feature?”.
My initial thought was that’s actually not a bad idea, but
the more I read the more I was swayed and started thinking about times when I
was either asked about a similar situation or posed the same question. Though I
wasn’t software testing at the time nor even in the industry this can be
applied to other scenarios as well.
While I do think that it is a good idea to track and refer
to past tests to see what has been done, I agree with the writer that “a
skilled tester can usually come up with better tests…today, from scratch.” He
makes many valid points and I will go over a couple that I thought to me stood
out, you can read the blog to get the rest if you’d like.
  • ·        
    A skilled tester knows more about testing today
    than they did last month.

         How true. The more you do something the
more you learn about it and the better you become at          it.
  • The product-under-test is different today than
    it was last month.  It might have new code, refactored code, more users,
    more data, a different reputation, a different platform, a different time of
    the year, etc.

          As the development process moves through
the different iterations, things change. Looking at             past tests may help, but
more probably than not it will probably slow you down. You have first           locate
the tests that were done and figure out what the tester was thinking if it wasn’t
you, and             then try and decide whether or not it even applies to the new code. By
the time you figure that             stuff out I would imagine you could have written
several test cases according to the latest                     iteration.

  • The test environment might be different.

          This is true as well, things seemingly change
frequently so you may have changed the                         environment and once again wasting time
seeing what you or someone else did.

The bottom line here is that while in some cases the old
data may help, but more than likely it will, in my opinion slow you down. One
more thing I think can happen is can stagnate your thought process as you are
looking at old ideas instead of coming up with new ideas.
http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/03/couple-automated-checks-with-product.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/02/automated-checking-is-very-human.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.softwaretestingmagazine.com/knowledge/how-to-give-better-code-reviews/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29
http://www.developsense.com/blog/2016/05/testers-dont-prevent-problems/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Whether or not to use old test data

This week I read a great blog on starting from scratch or
using old test documentation. The writer formed the blog based on a question
asked by one of his fellow testers, “How can I find old test documentation for
a completed feature so I can re-use those test on a similar new feature?”.
My initial thought was that’s actually not a bad idea, but
the more I read the more I was swayed and started thinking about times when I
was either asked about a similar situation or posed the same question. Though I
wasn’t software testing at the time nor even in the industry this can be
applied to other scenarios as well.
While I do think that it is a good idea to track and refer
to past tests to see what has been done, I agree with the writer that “a
skilled tester can usually come up with better tests…today, from scratch.” He
makes many valid points and I will go over a couple that I thought to me stood
out, you can read the blog to get the rest if you’d like.
  • ·        
    A skilled tester knows more about testing today
    than they did last month.

         How true. The more you do something the
more you learn about it and the better you become at          it.
  • The product-under-test is different today than
    it was last month.  It might have new code, refactored code, more users,
    more data, a different reputation, a different platform, a different time of
    the year, etc.

          As the development process moves through
the different iterations, things change. Looking at             past tests may help, but
more probably than not it will probably slow you down. You have first           locate
the tests that were done and figure out what the tester was thinking if it wasn’t
you, and             then try and decide whether or not it even applies to the new code. By
the time you figure that             stuff out I would imagine you could have written
several test cases according to the latest                     iteration.

  • The test environment might be different.

          This is true as well, things seemingly change
frequently so you may have changed the                         environment and once again wasting time
seeing what you or someone else did.

The bottom line here is that while in some cases the old
data may help, but more than likely it will, in my opinion slow you down. One
more thing I think can happen is can stagnate your thought process as you are
looking at old ideas instead of coming up with new ideas.
http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/03/couple-automated-checks-with-product.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/02/automated-checking-is-very-human.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.softwaretestingmagazine.com/knowledge/how-to-give-better-code-reviews/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29
http://www.developsense.com/blog/2016/05/testers-dont-prevent-problems/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Whether or not to use old test data

This week I read a great blog on starting from scratch or
using old test documentation. The writer formed the blog based on a question
asked by one of his fellow testers, “How can I find old test documentation for
a completed feature so I can re-use those test on a similar new feature?”.
My initial thought was that’s actually not a bad idea, but
the more I read the more I was swayed and started thinking about times when I
was either asked about a similar situation or posed the same question. Though I
wasn’t software testing at the time nor even in the industry this can be
applied to other scenarios as well.
While I do think that it is a good idea to track and refer
to past tests to see what has been done, I agree with the writer that “a
skilled tester can usually come up with better tests…today, from scratch.” He
makes many valid points and I will go over a couple that I thought to me stood
out, you can read the blog to get the rest if you’d like.
  • ·        
    A skilled tester knows more about testing today
    than they did last month.

         How true. The more you do something the
more you learn about it and the better you become at          it.
  • The product-under-test is different today than
    it was last month.  It might have new code, refactored code, more users,
    more data, a different reputation, a different platform, a different time of
    the year, etc.

          As the development process moves through
the different iterations, things change. Looking at             past tests may help, but
more probably than not it will probably slow you down. You have first           locate
the tests that were done and figure out what the tester was thinking if it wasn’t
you, and             then try and decide whether or not it even applies to the new code. By
the time you figure that             stuff out I would imagine you could have written
several test cases according to the latest                     iteration.

  • The test environment might be different.

          This is true as well, things seemingly change
frequently so you may have changed the                         environment and once again wasting time
seeing what you or someone else did.

The bottom line here is that while in some cases the old
data may help, but more than likely it will, in my opinion slow you down. One
more thing I think can happen is can stagnate your thought process as you are
looking at old ideas instead of coming up with new ideas.
http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/03/couple-automated-checks-with-product.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.testthisblog.com/2016/02/automated-checking-is-very-human.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+EricJacobsonSoftwareTestingBlog+%28Test+This+Blog+-+Eric+Jacobson%27s+Software+Testing+Blog%29
http://www.softwaretestingmagazine.com/knowledge/how-to-give-better-code-reviews/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SoftwareTestingMagazine+%28Software+Testing+Magazine%29
http://www.developsense.com/blog/2016/05/testers-dont-prevent-problems/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.