Home » Testers Paradise
Category Archives: Testers Paradise
I have had a couple of interviews recently for Tester/Test Automation positions. The strange thing is that the interviewers didn’t seem too interested in my test certifications or test automation experience. Or, my experience using automated tests in Continuous Integration servers, or in higher environments in a Continuous Delivery pipeline. But, they were very interested to know if I do Java development. <:-?
It seems a strange request, since when I am testing I am usually up to my ears “testing” and writing test automation. It’s hard to imagine when I would have time to write Java, or what I would be writing it to do. So, what is this fixation all about? I keep wondering what I am missing. Maybe testers telling developers how to write more testable code or is it just more code review? There are some good automated test tools for that; they run in your CI server. A tester’s life is hard enough without going toe to toe with development at the code level. Who in management is trained to referee a cat fight?
I suspect that Kent Beck is at it again/still, I guess he is never going to figure out that 98% of the people who develop, don’t want to test for a living, and trained testers who do test automation are busy developing test automation.
Don’t get me wrong, developers can do good testing, but you have to train them to test. Testing is a discipline; it has a body of technical knowledge behind it, just like development. I used to train developers how to test. There was a market for this in regulated and safety critical industries just before the turn of the century. It took a mandate from high up to get them into the right mood, and they were almost always very skeptical in the beginning, but once they got started they found testing techniques very useful. They became very good testers for the most part, and their code quality improved greatly.
It seems to me that the real question here is about the tester’s technical competency. (As well it should be after all the off shore testing fiascoes. ) But, if you want to make sure that the tester has enough technical background, an engineering degree and two years coursework in a Masters in Computer Science is probably a better indicator. Better yet, give the candidate a test that will tell you if the candidate has enough understanding of programming techniques and the language to meet your goals. (You do know what your goals are right?)
That said, I would love to be part of this great new experiment where you, “give every developer a pet-developer-to-test-for-him.” I have been working next to developers for years, but they would not let me write any code; that would have taken me away from testing their code. So, I am most curious to see what is different this time.
Quality means a lot of things to a lot of people, just ask them and you will find out. They will tell you about all sorts of “things” that represent quality to them. The problem is that quality is not a thing, it is t he measure of a thing. Quality is a metric. Quality measures how much excellence a thing possesses.
Think about it, a “high quality” item is an item that is “excellent”. So when someone describes quality as a thing, they are describing a thing that they believe has a great deal of excellence. We have come to use the word quality and excellence interchangeably. But they are not really the same ‘things’.
I see the meaning of these terms changing over time, just look at these responses. Clearly they are in Techlish. Definition migration is a natural phenomenon in any living language, but its only a good thing if the definitions become more precise, not more subjective. I prefer the more classic meanings based on the English dictionary.
Verification is “checking” that something is what it should be. Since in the simplest form “test” means to compare an actual result to a standard (expected result) Verify is basically “test” with a positive expectation. If you don’t have a STANDARD to compare to, you can’t actually test or verify.
Validation means “to prove to be wholesome and correctly executed.” – Validation does not automatically provide the “expected result.” Validation requires proof. The proof is accomplished by providing a convincing argument. Hopefully this is an argument, like a lawyer presents in a court of law. Building a convincing case based on facts that support their assertions of proof and validity. – Unfortunately arguments can also be supported by a show of brute force and intimidation.
Verification only requires a script with expected results. An automation tool can do verification. Validation requires depth of knowledge, and a compelling argument to support the testers opinion of validity. A good tester does both verification and validation.–Compare the outcome to the expected result, AND, judge the validity of thing they are examining. V & V is not limited to requirements, or applications, or systems. It’s how we judge everything.
Is something doing what it is supposed to do? (verification) Is what it is doing wholesome and correctly executed? (validation)
Remember, you can’t Verify if there is no expected result.
You can Validate, but you must create a convincing argument to support your opinion. The most convincing arguments are based on facts and measurements; two skills every tester needs to develop. So, for our picture,
Verify: Ok, she is there on a pony in the parade. Pass!
Validate: Is this a real pony? Doesn’t a pony have 4 legs? Is she the real queen? Is she a ‘she’? etc…
Validity is a funny thing, you may know it when you see it, but how will you convince everyone else.