I would also question that any activity that you ultimately have to observe must have Sapient input, ie you become part of the test. (this also echos some quantum mechanical stuff by Heisenberg or Schrodingers moggy). Needless to say short of the Non-Sapient testing that those aliens with the long fingers do when UFO’s kidnap Americans from dark roads in Buttsniff Idaho, I suspect we will not have Non Sapient Testing until we achieve Fredrick Brown’s Computer in Angels and Spaceships (Dutton 1954)….Is there a GOD?, Yes,now there is a GOD… ZAP! I am more worried that the testers who read your comments do not do an ambiguity review on the contents…..
[James’ Reply: There are non-sapient processes that can be part of testing. But testing as an entire activity is necessarily sapient, in my terms. I see no ambiguity here. It’s actually very simple. Can a machine do the same thing? Then it ain’t a sapient process (unless that machine is not available to you and you are forced to use humans). Of course most people think they have automated tests when they haven’t. What they automated is something different than what the humans were actually doing.]
GURT
Genuinely Uncertified Real Tester
]]>Brett
[James’ Reply: Great example! Thanks.]
]]>Seems to me that there are some aspects of testing which are somewhat repetitive. Not just rerunning a set of tests across a new version of the code, but also given a new api there are sets of standard edge conditions that we need to explore – does it work with nulls, negative number, very big numbers, empty strings, missing files, empty files … Essential tests I guess, but somewhat dull to enumerate. Can we use tools to at least reduce this drudgery and focus our sapience where it’s needed? Would this be test automation?
[James’ Reply: Repetition bores me, too, but I also know that I can learn from it. Each time I repeat an action there is the possibility of something new happening– something I didn’t anticipate and wouldn’t have programmed for. I have ways to overcome boredom. For instance, I vary my inputs, or I vary what I’m looking at. I add probes to my process, or run it on different platforms.
In many cases, I think repetition is a sign of poor test design. It is often variation, not repetition, which maximizes the chance of finding bugs.
Having said that, I often use tools in my testing. I use them sapiently. I adjust things, I add randomization. On whatever level I am working, I try to keep my mind fully engaged.
It is not a bad thing to use tools. It’s a bad thing to believe you can automate a sapient process, because automation changes the process into something else that cannot involve the same sort of reasoning and learning that the original process had. A sapient process doesn’t “get automated” it gets replaced by something materially different. Have you ever courted somone, Dave? Can you imagine “automated courtship”?
If you are not reasoning and learning with your testing, I suspect you are doing it wrong.]
]]>Quite true in general I guess…I have to be very disciplined not to work 100% with automation because it is so fun to work with and the response from other testers and stake-holders are great for the things that you accomplish.
However some automation/tools in testing is really good to have so I normally do 30% automation testing/”tool forging” and 70% “sapientâ€? testing on a normal day. I think that it is good sometimes to change your mindset a number of times a day from testing to coding and vice versa (some sort of focus/de-focus) so you “keep-in-touch” with both worlds.
Thanks for your great contribution to the software testing community – keep up the good work!
/Stefan
]]>[James’ Reply: Thank you. I’m glad to hear that. Do you think most programmers are like you? If so, I’m puzzled, because I have not found it a common thing among programmers to wish to learn test design.]
]]>