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/

Insights from the Test Obsessed Blog

This week I found the Test Obsessed blog interesting. The title of the post is “I Prefer This Over That’. The blogger goes on about a tweets she had made about her preferences. They are: Recovery over perfection, Predictability over commitment, Safety nets over change control, and Collaboration over handoffs. I will talk on just two of them and if you seem interested check her blog out at the bottom of this page. It will be the first in the list.

·         Recovery over Perfection

The overall gist of this is that something will go wrong. Basically the software might not do what its suppose, the server may crash, or any other plethora of things, but the key is not to aim for perfection otherwise you’ll be too afraid to actually deploy. She says basically that there is the plan B. Make sure you can roll back if the deployment fails, and update the software quickly if it behaves badly.

I like her idea on this as I often find myself trying to perfect things only to have a setback along the way and end up mildly discouraged. She makes a good point and I will try and put this into practice. I mean nothing is perfect, there will always be some sort of speed bump. The question is will you be prepared? As long as you plan for unforeseen events all should be ok.

·         Collaboration over Handoffs

The overall theme of this is pretty straightforward. Instead of passing the buck and blaming others for issues that go wrong over bad communication, work together on issues.

I may not have any experience in the programming world as far as employment, but I will say that it never ends up pretty when you hand off work or a checklist to someone without actually going over it with them. Something generally goes wrong, the boss gets ticked, starts yelling and people look for other people to blame. It all comes down to communication and collaboration. I mean when you are at work you are all supposed to be on the same team, not a bunch of solo artists. I have seen it work beautifully when the team works together and communicates. So much less stress involved and I think that this comes into play in the programming industry when multiple people are working on different parts of the whole. If there is no communication or bad communication things go wrong and you end in a mess of in fighting.

Here other points are well written in my opinion and hit the nail on the head. A lot of it is common sense, but we all lose sense at times and need to be grounded. Overall I thought there were some good points she made and I hope that you think so too.

http://testobsessed.com/2015/05/i-prefer-this-over-that/

http://www.satisfice.com/blog/archives/1649

http://agiletesting.blogspot.com/2016/10/creating-ec2-and-route-53-resources.html

http://martinfowler.com/articles/refactoring-adaptive-model.html

http://testertested.blogspot.com/2014/06/a-question-on-exploratory-testing-from.html

A bit off topic on Agile

I think this week I would like to go off topic and talk about Agile development or Extreme programming. I believe we were able to stray off for one blog if I recall correctly. Up until now I haven’t really given much thought to actual processes for design patterns and how an actual project is created using Extreme programming and test driven development. I am finding that I may have to take a step back rethink what I have thought to be the way things were done. As I have zero experience in an actual programming position in a company and only know what I read or learn here at school, I find that I am having to rethink things out often. Anyways my thoughts on TDD and XP. I am finding some of the concepts hard to grasp, not intellectually, but just in a common sense strategy sort of way. We just finished a lab on TDD and XP and the method of programming to me seems counterintuitive in ways, but I think it is just because it is new. I do like the idea of writing a test and then the method and just doing the basics to get it to work and building from there. I have never given this much thought, but hey if you write the test you know what to code for so it’s pretty cool. I also will have to get use to the idea of not using inheritance when possible and using many smaller methods to make up the project as whole. I don’t think I will have too much of a hard time adjusting to that though as I think that this is a very effective way to do things as it is easier to compartmentalize when there is an issue with the code and to track bugs down I would imagine as each small part is part of a whole so you only have to weed out a small potion and make changes instead combing over mass quantities of code. Over all I think that once I get use to this way of thought it will only help to make me a better programmer.

On learning

As I made my way through some blogs this week, one in particular really stuck with me. It is a testing blog, but the post the blogger made wasn’t really necessarily about testing, well not any method of testing anyhow. It was about learning. What struck me about it is this. I sometimes wonder how I am going to actually make sense of everything I am doing in school and how I am going to put good use to the skills when I graduate and how can I better my skill set in ways beyond coding, testing etc. The blogger starts out by saying that she likes to learn and she thinks of testing as an exploratory process and that testing is a learning activity. She has some really good ideas that I may try in the near future. She speaks at conferences and such and learns from the people she meets there and recommends going out and volunteering to help set up and organize a meet up or volunteer to speak and such. I have been to meet ups and try to go as often as I can with my schedule, but have never thought about volunteering to set one up or given much thought that it is actually a learning experience in itself. I have started to do more I this area at school with trying to get the ACM chapter going with the help of some peers and faculty and I can’t wait until it happens. I see good things from it and it can only benefit people. I am always looking for new ways to learn something or new ideas on programming and I wonder what other people do to help become better at what they do or to better themselves. Ultimately I would like to get into a mind set that the blogger has about testing and think of it as a learning activity. That and other things and challenge myself to find new ways to learn.

Here are the links of my weekly reads:

http://visible-quality.blogspot.com/2016/10/sharing-is-way-of-learning.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

http://james-willett.com/2016/10/finding-the-balance-between-unit-functional-tests/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29

https://www.stickyminds.com/print/article/testing-unexpected-shift-right-devops-testing

http://feedproxy.google.com/~r/mottestingfeeds/~3/R8IdhiiCjUI/

http://testavimas.blogspot.com/2016/10/how-can-i-break-it.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29