Testing in the Absence of Proof
I was inspired to make a blog after reading this. The context under which the word Religion is used is really interesting to me. Partly because it indicates that testing ideas and methodologies which can't be quantified aren't scientific and are just matters of belief.
As a touchy feely type person, and also a person from an artistic background who has since gained an interest in science, I feel sorry for people who have no belief beyond what they can verify. I think that the things that matter most in life can't be verified or quantified. I think that innovation can't be proven. You can't prove a new idea is good before you try it. This way of thinking makes some people feel really uncomfortable, but I'm not sure why. The most basic of scientific principles starts with a hypothesis. That is scientific curiosity. Even if an idea proves to be false after testing the theory, I have great respect for those who "wonder if" and will go find out. Those are the people making a real contribution to the testing profession. Those who seeks to stabalize, quantify, assure rather than test, and compartmentalize all testing really depress me. Trying to quantify testing is not a new idea. I find it rather boring. It is something I do because I have to, and as quickly as possible. I don't think it really adds much to the end quality of software.
I'm not suggesting that we shouldn't verify our assumptions, test our ideas, improve and adjust based on the findings, only that lack of evidence and proof is no reason to prevent us from trying something new. If we are to make true advances in human testing, small or large, we must have the courage to apply new ideas. Then as we are trying the new ideas, still have the humility to logically figure out what is working and what is not and make changes. Would the same idea work in another context?
As a touchy feely type person, and also a person from an artistic background who has since gained an interest in science, I feel sorry for people who have no belief beyond what they can verify. I think that the things that matter most in life can't be verified or quantified. I think that innovation can't be proven. You can't prove a new idea is good before you try it. This way of thinking makes some people feel really uncomfortable, but I'm not sure why. The most basic of scientific principles starts with a hypothesis. That is scientific curiosity. Even if an idea proves to be false after testing the theory, I have great respect for those who "wonder if" and will go find out. Those are the people making a real contribution to the testing profession. Those who seeks to stabalize, quantify, assure rather than test, and compartmentalize all testing really depress me. Trying to quantify testing is not a new idea. I find it rather boring. It is something I do because I have to, and as quickly as possible. I don't think it really adds much to the end quality of software.
I'm not suggesting that we shouldn't verify our assumptions, test our ideas, improve and adjust based on the findings, only that lack of evidence and proof is no reason to prevent us from trying something new. If we are to make true advances in human testing, small or large, we must have the courage to apply new ideas. Then as we are trying the new ideas, still have the humility to logically figure out what is working and what is not and make changes. Would the same idea work in another context?
TDD and acceptance testing, create value and optimize quality. Importance of UI and domain knowledge. 40 hour workweek? A craftsman is at least at 60; Source UncleBob and
personal conviction. Results not testing, results not code. TDD is the solution for quality code output. Agile is the overall umbrella for iterative, effective and efficient
development efforts. Pair programming would boost my productivity by a factor of 3-5, no doubt about that. Test before, during and after. Raising the bar, first paragraph
nails it perfectly down. Engaging customers from the project launch, Use Case, pair programming, desk check code inspections, watch the tests like a cop, arrest the bugs,
design by contract, driving the process with usability experts, good usability testing... This is getting religious. Agile is about involving the user TDD about engaging
the code, TDD is about tools and processes over people and interactions, a healthy combination of both. Focus on quality. Got to know design-by-contract, design by example
and clean room. Focus on quality and the thought process rather than on techniques.
Innovation is 10% inspiration and 90% PERSPIRATION (sweet sweat); Everything must be measure and can be quantified. Fully agree to take risks and try new techniques, experiment
always aware of the opportunity cost. And quickly backtrack if it leads nowhere. Avoid wasting time at all cost. Time is the most precious resource we have and time
well invested provides tremendous satisfaction. As an aside, when everybody has stopped, that's when I really start accelerating, gives me satisfaction. Be open minded
and apply new idea, if it works adopt it if it doesn't be quick to ditch it. Good question, if one has time to think how I could apply that in another context. That's when you start
putting the pieces of the puzzle together and magic happens. It is recommended in my industry to learn a new language each year. That could be a new testing technique, the opposite of what you have been practicing in depth the previous year. I will do that beginning of next year. First in depth understanding and mastery of a weapon before focusing on a new one. 5000 hours of intensive playing with the technology seem to be a good start. And by the way: Happy Valentines Day.
Reply to this