Programmer Profiling - Don't Be Afraid To Use It
Posted by Eric Jacobson at Friday, February 11, 2011I promised I would post about my Lightning Talk, Programmer Profiling, per my Our First Tester Lightning Round post.
I came up with the notion of programmer profiling after listening to the Intelligence Squared podcast called “U.S. AIRPORTS SHOULD USE RACIAL AND RELIGIOUS PROFILING”
The TSA is responsible for finding bombs among some 3 million people participating in 20 thousand US airline flights per day. The TSA takes heavy criticism from people who believe racial profiling is wrong. But the TSA also takes heavy criticism for the opposite, searching little old ladies and children. Some firmly believe racial and religious profiling is one approach that should be on the table. Based on prior terrorist attempts, searching old ladies may not be the best use of the TSA’s time.
I noticed some vague similarities between the TSA and software testers.
- The TSA protects passengers by finding bombs among 3 million people.
- I protect users by finding bugs among 3 million lines of code.
Then I realized I already practice my own form of profiling to determine which areas may need more of my test attention. I profile the programmers. Not just based on their prior code quality history, but also based on their current behaviors.
For example:
- If I ask ProgrammerA how she tested something and she shows me a set of sound unit tests, and a little custom application she wrote to help her test better, I gain a certain level of confidence in her code.
- On the other hand, if I ask ProgrammerB how she tested something and she shrugs and says “that’s your job”, I gain a different level of confidence in her code.
When the clock is ticking, and all other things are equal, where do you think I’ll focus my time?
As is the case with potential TSA racial profiling, it should only be used as one of many approaches to finding the problems. It should be balanced with other considerations. But perhaps it should be on the table.
I call this “Programmer Profiling” and I think testers should not be afraid to use it.
5 comments:
Subscribe to:
Post Comments (Atom)
RSS
Yikes!
I'm not sure I'm comfortable with comparing TSA agents and testers. And I'm certainly not comfortable asserting that "The TSA protects passengers by finding bombs among 3 million people." Have they actually found any bombs?
That said, it sounds like ProgrammerA is a terrorist who just doesn't happen to fit your profile of worry.
And ProgrammerB might well be a little old lady or a child.
If you base your testing on a profile, you could be doing exactly the wrong thing.
Ha! Clever comment, Joe! Thanks for challenging me to re-think, once again.
To be sure, I did say "It should be balanced with other considerations." and "When the clock is ticking, and all other things are equal" (e.g., risk).
Skilled testers constantly make decisions about where to spend their energy. Knowing how well their developers test their own code can be a valuable aid...along with lots of other stuff.
I probably consider it every iteration. And especially when I am faced with the pressure of a production patch the users are staying up late waiting for.
"Skilled testers constantly make decisions about where to spend their energy."
Very true! And particularly so when the business is looking over your shoulder asking "is it ready to ship yet?"
Your Blog is one of the best top 100 software testing blogs listed in this article:
http://www.testingminded.com/2010/04/top-100-software-testing-blogs.html
but for me, it's just one of the best! Keep the great work!
I prefer to think of the phrase "know thine enemy". Not that programmers are the enemy of testers - as an automation specialist, I am as much a programmer as a tester - but its good to know the strengths and weaknesses of those whom you are working with. If the programmer designed the feature mostly on their own, I'm going to be a bit more vigorous in my testing than if the feature had been designed/speced by a group, especially if testing was represented in that group.