Java. Quality. Metrics (part3)
I'm writing this sitting in Lufthansa's 747 â€“ boy, I've seeing better planes in my life â€“ going towards Frankfurt. There I will change planes and fly for another two and a half hours to Saint-Petersburg, Russia. There I'll have a lecture at the Saint-Petersburg State University. And guess what would this lecture be about? Right, it's about Java quality again :-) (I'll write about this event as soon as I'll be flying back two weeks later). And I have to say that electronic technology is great and it's advancing much faster than all these last century's wonders like airplanes and stuff. Could you imagine that my 15â€ laptop doesn't fit between seats? I have to type these things sitting in a really awkward position :-( (I wish I'd have one of those tiny yet cool X40). And at the same time I'm online! Wow!
Speaking of quality: sitting here I got an idea, that a â€œqualityâ€ isn't about something good for anyone. It's more about a reasonably acceptable level of things and services. It's like these two entries in a flight's menu and both are â€œreasonablyâ€ good. (Well, I guess it, because I didn't dare to taste a chicken :-( ).
Perhaps, someone's flying in the first class and having caviar right this moment. But when I realize how much they are paying for this quality I start thinking that I'd rather be a reasonably cheap passenger, accepting a reasonable quality of public air transportation.
Did you start wondering what I'm up to? Well, I'm about software testing again.
Let's see: are your bosses willing to pay for finding all the bugs in software packages your company's making? Really? Well, then you're working at Microsoft and your QA department's budget is really fat (although, it is not helping much, isn't? :-) As rest of us are leaving real lives, more or less, we have to balance the cost of hunting bugs down and their harm to our business. No, really, don't consider me too radical or cynic. Let's just be real.
Will a bug in one of those debugging modules hurt much of your business and relations with customers? Naah, I don't think so. Will a dump typo in a help messages make a lot of troubles? Probably not. But what would you client think about it when noticed? They might not tell you, but I can say this. It'd be something like this â€œHmm, what are other bugs this POS (piece of software :-)) has that are not that harmless and obvious? Shall I invest into this platform any moreâ€? Then merely imagine all perturbs of discovering and writing tests for this debugging module's bug and simplicity of killing the bug of help messages? You got the point, right?
Of course, I'm intentionally simplifying the picture. It might not be that easy to prioritize one bug over another. So, let's discuss a few techniques you might find helpful in making such a decision. Of course, they are pretty much empirical and you'll have to decide how confident you are about them.
- Firstly, it is source code's prioritization by their scope of visibility. So, it says that a private code is unlikely to have much effect over what is seeing by customers. And, likewise, public method is more likely to affect some important functionality. Well, arguable, but it might be a fair-enough starting point. Especially in libraries writing business.
Actually, this is what unit testing is about, I believe. Due to the nature of unit testing approach (for Java at least) it is focusing on public methods testing. And if you ever want to test a private method â€“ hello, isn't it time to change its scope of visibility and make it public? As you can realize this technique has its benefits and shortcomings
- Secondly... Hey, wait. We're approaching a landing site and they asked to turn off any electronic equipment. Since I want to land safely and the battery is drying anyway, I'll post that small article now and will continue this interesting topic afterwards
Kinda hint: Deutsche bier â€“ this is what I call a reasonably great quality :-)