I started a new job today. It doesn’t involve robots (yet!) but it’s about setting up a testing lab to make sure the various devices we interact with work correctly with our products. The lead developer and I went to lunch today to discuss his plans for the team.
He’s very excited to have a professional tester on the team finally because he believes, as I do, that testers have a different mindset than the developers have. I agree with him completely. Testers want to “break” the code. They are curious to see what will happen when ___. Developers tend to want the code “to work.” Testers try entering invalid data or click the buttons out of order, Developers typically test the “happy path.”
There’s nothing wrong with these two viewpoints but we need to acknowledge them as different. And we need to realize that we are both working on the same team, it’s not Testers vs Developers. It should be that we’re both fighting the defects that will hurt/annoy/anger our customers.
We agreed on that. But, what he said next, really floored me, at first. He said he was thinking about bringing in some computer science majors as college interns. He wants them to test some basic/UAT kinds of tests and see if they want to continue with the company as developers. WHAT?! This seems diametrically opposed to what he claimed earlier about the mindsets being different. He asked me about my thoughts on this and I told him it seemed counter to his goals of having testers.
He defended his position by saying that Test Driven Development works better if the developers understand the idea of testing to begin with. He said he’s found the best way to teach testing is to have the “students” do it. I agreed with that. When I teach testing courses, one of the things we look at is the airport parking cost tool at Grand Rapids airport. http://www.grr.org/ParkCalc.php In the class we brainstorm what the requirements likely were, then test the finished product based on those requirements. We look at the site to find out what the rates are and manually calculate some of the prices, just to make sure the Calculator works correctly.
The Calculator is a simple form with a pulldown to select the parking type and a couple boxes to enter the start and stop dates and times. When you hit Submit, the Calculator should tell you how long you are staying at the airport and how much it will cost to park your car there. If you’re testing the Happy Path, all is good.
But, if you’re not… and you try February 30 as one of the dates, the Calculator accepts that and still performs the calculation. Turns out the Calculator accepts a lot of crazy dates like ‘9999999’ and ‘-9999999’ and 6/8/2015 and 2015/06/08 and “date”. Ack! Turns out I’m not the only one using this website. There are testing competitions to find out who can find the largest or the smallest payment required. Can anyone get a negative price? And it turns out the calculation is not always correct in any case, a regular functional defect that may require a fair number of test cases to find the error.
In this particular example, the fact that the Calculator is wrong is more amusing than problematic. But, what if the Calculator fed it’s number into a charge card or accounting process? Now would we care? You betcha!
So, I’m all for training folks to be testers. I’m all about showing Developers why testing matters and how they can be “more robust” in their efforts. And let’s face it, if the Developers are doing the testing and they get the idea that the same test with differing values and boundary conditions might be useful, they might start to think of testing as cyclic and that might make them think of loops and that might lead them to build some interesting tools to allow us to try a larger variety of tests than we typically do now. And I’m definitely all for that!
Especially once the robots start getting built!