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!
Angels and Devils
Angels and Devils
I recently happened across this interesting article from Quality Digest magazine. The gist of the article that I took away is that we find mentors and anti-mentors wherever we go and it got me to thinking (like you knew it would… and I think I may have to contemplate a better descriptor than ‘anti-mentor’)
Some of the best Quality mentors I’ve had haven’t been in “Quality” per se. Sam is a brash man that I hired a few years ago. He had been Special Forces so I kind of just accepted his ego as part of him. 🙂 He hated stupid people and often engineers. He would complain about people who couldn’t think their way out of a wet bag or manage to use the drive-thru “correctly.” He once told me about working at the Aberdeen Proving Grounds as a jumper. He was handed a piece of expensive hardware to test jumping out of the plane. He promptly dropped it which caused all the engineers to panic, asking him, “Do you realize how expensive that is?” He didn’t bat an eye but rather asked them, “do you know how much shock this is going to receive when I jump out of an airplane with it?” They backed off and he conducted the tests as asked. Lesson learned that it’s important to ask the end user how the new product will be used.
I hired him because the man could build craft anything. Even if he was only given a doodle on a napkin. He’d roll his eyes when he saw me coming but he and I both knew we wanted something good to come out of our project. And I think that matters. When both parties know that the goal is to make a good product, you both give the other a little slack. We may egg each other on but we know, know that we are all professionals attempting to put Quality into our products. Our processes are designed to help us communicate with each other and sometimes we get so caught up in the documentation that we forget what we’re trying to communicate.
For example, together we once saved the company we worked for something in the 6 figures because we were able to “fab” a device to test a small component that was thought to be malfunctioning. Using a video camera that was on hand, we were able to demonstrate the part’s reliability, under a variety of attitudes, to the customer using $40 worth of scavenged parts and a metal desk protractor. The customer was happy that we ruled out (no pun intended) the part as a source of the defect, the CEO was happy for the continuing good will from the customer, and the FO was happy she didn’t need to write a huge check. And the team was happy because we now had a cool story to tell. 🙂
Nowadays, Sam is retired but I still look up to him. Quality is where you put it.