One of the courses I teach, which I’m quite proud of, is the capstone course for the CS and IT majors. In the two semester course, we design, build, and release something to the world. The projects are based on interests in the various groups, usually 2-4 people per group. We’ve built robots, network sniffing tools, video games (some better than others ;)), and a variety of web portal kinds of tools. This cycle, one student team built an existential video game called Unbearable which was impossible to win and whose arcade-style high score tracker published random numbers. It was a silly game on the surface but had lots of ironic and fun easter egg kinds of behavior.
The other teams collaborated to build what was functionally a tele-presence device. The intent of the device when they started was to be able to “call home” to see your dogs and make sure they were ok. They had promised “bark recognition” software that would send you a text if the dog was barking too much and a Pan-Tilt-Zoom functionality for the camera so you could watch the dog. Early designs had a ball thrower so you could play with the dog remotely but that was simply too complex for the time we had. There had been some discussion about blowing bubbles for the dog to chase instead or perhaps giving the dog “some kibble” to get it to come to the device. The “kibble launcher” became the in-joke for the two semesters but was kind of moved to “nice to have” instead of a requirement.
Last night, the team demo’d their product with the intent of showing the customer that the product should be funded to actually be built. One of the team members brought their dog in to show the reaction to the device. Generally, the dog was less than impressed 🙂 We joked that they should have included the “kibble launcher” after all to get the dog’s attention. The student responsible for the case that the telepresence device lived in reached under the desk and pulled out a small box-like object which he hooked onto the side of the device. You could see there was a place for wires and a motor though they had not actually been installed. He then reached into his backpack and pulled out a baggie of dry dog food which he loaded into the new add-on. It was manually activated but the dog was excited to get some “kibble” so at least hung around the device during the demo. Network issues in the classroom prevented the demo from working well but we had seen the process work in the past.
The reason I bring this all up is that the “kibble launcher” started as a joke with the team while we were brainstorming the functionality of the product. In brainstorming, you write down all the ideas that come up, no matter how odd they may seem. Using Affinity Diagrams and other tools, we pared down the ideas to a manageable number of requirements to build. The launcher was decided to be a “if we have time” kind of feature and it was shelved. But, we made so much fun of the idea that the cabinet builder kept thinking about how to actually do it. He mocked up a prototype which he proudly displayed last night. It helped their product and would have differentiated it on the market if we had really built it.
My point is that we often come up with crazy ideas in brainstorming sessions and we filter them out right away because they’re silly/stupid/too expensive. But sometimes, those ideas live on and we find a way to incorporate them into the product. And we should. Those “crazy ideas” are how we sometimes get new, cool products.
Month: June 2015
Testers and Developers
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!