The Source for Java Technology Collaboration
User: Password:



Konstantin I. Boudnik's Blog

October 2005 Archives


Java events in Saint-Petersburg, Russia

Posted by cos on October 27, 2005 at 02:46 AM | Permalink | Comments (0)

Two events are happing meanwhile in Saint-Petersburg State University, Russia: Do not try to follow the links above if you do not understand Russian :-)

Java. Quality. Metrics (part3)

Posted by cos on October 21, 2005 at 11:34 PM | Permalink | Comments (3)

Hello everyone!

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 :-)

Auf Wiedersehen,
Cos

Java quality's open-source tools

Posted by cos on October 04, 2005 at 03:26 PM | Permalink | Comments (1)

Hello again.

Since I posted my first article here I've been asked a number of times: "Why there's no open source tools for quality process? Are there any?"

Being a lazy enough, I decided to reply just once in this public forum. Ok, here's the answer:
there's a number of open source tools to do a neat automation of one's software quality process.

    To schedule and execute jobs execution in a heterogeneous environment you might want to use
  • Sun's donated project RIO
  • or
  • Sun's opensourced GRID engine
  • instead of Distributed Tasks Framework, we wrote.

    and to run actual tests
  • Tonga harness can be replaced with JTiger or TestNG
I encourage you to look around and find a tool, fits your needs in a best way possible. Enjoy,

Yours,
Cos



Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds