Missed One
Wow, only the third day of my attempt to post every day and I missed already. Well, aside from the fact of the dog eating my homework, a lot of stuff happened last night (I planned to post in the evenings). Things like: fixing my wife's friend's computer (a bad update to the computer's video driver control panel applet mapped a DLL into the address space needed by one of the core Windows DLLs) and fighting with a company's secure message system (For some reason, when I registered it wouldn't take my email name and information. It just returned a very unhelpful email message telling me to call their tech support whose hours were from 8:00am to 7:00pm. I absolutely needed to get the message last night, though. After getting pissed off for a while, I tried entering my wife's email and information and it took it! Once I was registered, I was able to add my own email to the registered account and get the message. Sheesh...).
I guess those two incidents say something about the need for quality in software we need to use in our day to day life. And reminded me of something I meant to say here.
Lately at work, there is a big push for all our testing to 100% automated. At the meta level, this is a reaction to having not enough automation in the past and unthinkingly moving from one extreme to the other. That idea itself is a different conversation and perhaps a later post but one aspect of why that sucks, and what I want to talk about in this post, is that it takes testers away from actually interacting with the product. More than one time, I've seen obvious embarassing bugs missed by a test team because no one's actually interacting with the product. They're too busy building and maintaining the test automation infrastructure.
Why does this happen? Off the top of my head, one reason I can think of for this happening is that the test team doesn't value testing. This can lead to bad hiring, where you hire people who don't have an aptitiude or a love of testing and who see a test position as a stepping stone to development. So they spend their energy trying to get experience in or prove they are good developers. The opportunity to do this on the test team is in building the test infrastructure and so they focus on that to the exclusion of actually testing the product. In an organization like this, management can be a cohort. When development is valued to the exclusion of testing, managers may tend to promote development-type projects as an example of how great their team is rather than rewarding testers actually doing their job.
I wonder if the team that developed the video driver update short-changed their testing of the update mentioned above. I wonder if the team that implemented the secure message system actually tried out the system as a real user would. The second example is particularly troubling. Not only did the system reject the person who legitimitely needed to use its functionality, but it also gave access to the system to someone who didn't actually have the credentials to get the message and allowed that account to get the message intended for the account it erroneously blocked. Late last night I was pretty happy it did because I needed the work-around. But today, in the cold light of the morning I'm not so ecstatic.
Since I missed posting last night, look for another post this evening.