Or checking for correctness? When you test your code, do you look for all the wrong things that can happen, or do you make sure it’s working properly first?
Of course, you should be doing both. But you’ve got to do one or the other first. You can’t do both at the same time, because they’re completely different. One is where you don’t know what will happen, like rolling your head on the keyboard to come up with random input. One is where you know exactly what has to happen, like a textbox accepting numeric input, and only between 10 and 23.
Correctness is defined here as “working according to what’s reasonably expected”. If you have specs, there you have it. Negatives can count as correct too. For example, “must not show information of other users” is a negative requirement. If the application indeed does not show other users’ information, then it’s working correctly according to the requirement.
The fastest way to complete a project is to code according to specs, test for correctness, then test for flaws. Because the specifications are known, there are thus well defined finite areas of correctness, which provide a basis for deadline estimation.
Flaws on the other hand, are practically infinite. You can always find something to change for the better. When you test for flaws first, you will find tons of minor irritating aspects of the application that you can change. None of which will significantly bring you any closer to what’s required.
You’ll only stop because the deadline has mysteriously gotten closer, so you decide it’s better to stop nitpicking and actually start testing for the requirements.
Let’s take the example given before, a textbox accepting numeric input, and only between 10 and 23. Reading through the specs, you find out that it’s for hours of operation, as in anything between 10 am and 11 pm. So the value obtained from the textbox is used as an integer.
So you test by punching in numbers and making sure only numbers 10 through to 23 are accepted. Numbers outside the range as input will give an error. You also make sure alphabets and symbols give errors too. This satisfies the correctness requirement.
Then you test for flaws. Things like 12.0 or +19 are accepted, but preferably not.
Alright, as a contrived example, the textbox input requirement seems rather lame. But I hope you got the point. Testing for correctness means you get a working application quickly. Then when you test for flaws, you’re just adding on to the correctness.
The thing is, some people must overcome whatever their misgivings about your application before they even check how cool your application is and how correct it is. These people are usually your users, or your managers, or whoever uses the application but don’t really give a rodent’s behind about your code.
I’ve met some of these people. And I understand their position and view point. They don’t quite like this colour, or they want that button somewhere else. I get it. There’s a reason why I understand this behaviour, and that I even expect it of them.
They already assume your application is working correctly. Hence they go nitpicking. They have a right to nitpick. In their minds, the application is working according to specifications, and they’re tuning it to better suit them.
Now, the authors of defect reports… I don’t understand them. Dedicated testers are supposed to give feedback on the application, which includes both correctness and flaws. And correctness should be a higher priority. They should be the safety net, catching the uncommon cases that escaped the programmer, but contribute to the correctness of the application.
Yet the testers I know seemingly focus exclusively on the flaws with zero regards to the correctness. Once, my colleague had to come up with a suitable image for a trashcan, for use as a delete button in a datagrid. The original image was done by me, bluish in theme. My colleague even apologised to me that he’s not using my image. It was fine. The image wasn’t artist-grade, but it serves its purpose.
He had to do it, or the testers refuse to test the intended web form at all. They don’t want to test if a new record can be correctly inserted into the database. They don’t want to test if they can update existing records correctly. They don’t want to do anything on the web form, refusing to understand how it works, until they’ve got their trashcan image.
One image after another was sent. They don’t like the look. They don’t like the colour. They don’t think it looks like a trashcan. Finally I suggested to my colleague, just ask them for an image instead.
They couldn’t. They don’t like the images submitted to them, and they couldn’t give us an image they approve of. After wasting many days over this trivial matter, my colleague came up with an image, digitally manipulated to fit what hopefully suits the testers’ perceived requirements.
It was ugly. It was dull red, like someone had a nosebleed and sneezed, and one of the blood drops happened to hit the floor in a vague squarish pattern. Then a digital photograph was taken of it, and the result had a slight yellowish-green cast to it. And because of the looming deadline, the testers finally went with it.
I am working hard with the users to bring the application to live status as soon as possible. The sooner it goes live, the sooner users get to benefit. The testers, on the other hand, seem bent on delaying the project. Their fears of causing calculation errors, of users using their approved interface design (but might possibly be perceived as unfriendly), of maybe tens of other irrational fears have stopped them from growing. And their fears have essentially stopped the company from growing.
It’s about mindset. Do you expect greatness and code and test for correctness? Or do you fear and nitpick on minutiae?