For my blog post Craftsmanship over Execution I had read about teams that were doing Agile, – i.e. Scrum – had practices – i.e. test-driven development. The point by that time concerned that another development team would hear “Oh, they succeeded with Scrum, let’s take Scrum and be successful, too!” There are several reasons why this is a bad idea and I decided to write about some of them.Continue reading Succeeding with project methodologies
Michael Bolton brought up a series of blog entries on Testing vs. Checking recently with follow-ups here and here. He perfectly explains the differences between the mindful job of testing and the checking attitude. While both have a reason to be done, checking is too often confused with testing. From my experience this has a negative impact on how testing and testers are perceived by the organization around them. If people in the organization get told about testing and indeed have checking in mind, the lowered expectations about testing gives a negative impact on respect towards this mindful and thought-provoking activity.
Michael defines testing as a sapience based activity. You need the human to perform it. On the other hand checking is a pure act that anyone can do – even the computer. Based on my work experience, usually we think up new test cases, which we then start to automate and put into our revision control system and have them run on a regular basis. The former, the invention of the test case, is a testing activity. You need a human for this, since we are not capable of automating this step in our software development cycle. The latter, the mere execution of the automated test is a checking activity. Any computer can do this, and mostly we have this even done in our continuous integration server without required attendance of a human. If something goes wrong, well then we could have a problem and need a human to investigate in the test result and whether or not we have a problem with this outcome. This again is a testing activity.
This is not everything we do as testing activities, of course. There are documentation reviews, bug reporting, etc. that also needs to be done on our course. These also require a sapient to conclude. (I thought about automating that bug reporting in the past directly when an automated test case fails, but didn’t do it – so far.)
Matt Heusser noticed recently that there are few blog entries on testing recently. Personally I have cut my blog posts in the last two weeks down since I had to work on my submission for the Agile Testing Days conference in Berlin in October. There is bunch of blog entries I would like to point my readers to that I have piled up since then. In case you’re seeking for new testing blogs to read, Matt has compiled a list of worthy blogs in his entry on best new software test writing.
Finally I would like to point out to Joe Harters blog. Yesterday he made a great first post. Worthwhile to read and a great story on how to teach testing to your colleagues.