Gunnar Kudrjavets - All Comments

re: How to Shoot Yourself in the Foot with Code Coverage? (Part I)

Vishvanath — Wed, 03 Jun 2009 11:18:43 GMT

I used Magellan in my previous project for Microsoft.. Now i don't know from where to get it, ... any idea?

re: What is BVT (Basic/Build Verification Test)? (Part I)

Zach — Tue, 14 Apr 2009 16:36:04 GMT

The info about BVT was extrodinarly exeptional.

re: Program testing can be used to show the presence of bugs, but never to show their absence!

Inder P Singh — Fri, 16 Jan 2009 11:52:04 GMT

Gunnar

I have a couple of personal comments:

1. Testing may not prove that something works correctly. However, testing shows if something works (either with or without problems i.e. defects) or does not work at all.

2. Simply increasing the quantity of test cases by varying the test data when duplicating the tests might have less value. However, if the test cases are well thought-out and cover the stated requirements thoroughly, they might be desirable to have.

3. In the light of the definition given above, validation is achievable. In the absence of a definition or context, validation of the software i.e. confirming that it works correctly is quite difficult, if not impossible.

Thanks,

Inder P Singh

re: The out-shuffle problem: solutions and acknowledgments

narayan — Tue, 30 Dec 2008 12:55:56 GMT

Hi, the link shared shows the O(n) solution with O(n) space. But according to the problem statement, we need a solution that uses O(1) space and O(n) complexity. The pdf link is not working. Could you share me the actual pdf please ?

Thanks,

Narayana

weblogs.asp.net/.../135584.aspx

re: Development:test ratio causing software quality to self-stabilize

Belal Raslan — Sat, 16 Aug 2008 10:06:46 GMT

Factors such as Function Point (FP), team experience and project schedule should be considered when defining the ratio.

re: Development:test ratio causing software quality to self-stabilize

Chris W. — Fri, 25 Jul 2008 16:44:05 GMT

Even within a single organization, the ratio can need to change by project. Consider the following two scenarios:

1. Brand new to the world product.

2. A one line change to a legacy product.

Certainly every organization will eventually be supporting an old product while developing a new one.

The first project seems like it would need relatively greater development resources vs. testing than the second.

So there may be industry averages, but the 'correct' answer would seem to depend on the project in question.

re: How to cut your couch into pieces? (Part II)

Chrystal — Tue, 17 Jun 2008 23:18:10 GMT

How funny cuz we live in Seattle and I am researching on how to safely load a couch from a balcony. Reading this was a pleasure but it seemed a little easy with the descriptions.

re: Development:test ratio causing software quality to self-stabilize

Terry — Thu, 08 May 2008 13:42:47 GMT

The development to testing ratio has been a point of controversy for years. In a recent project, given the complexity of the landscape, with 72 countries, 12 languages, a 100 plus interfaces and reports, and 7 functional modules, I found you had to have 1 test hour to 2 development hours. I've always used 1:3 ratio on other projects, but be cautious as not to quickly apply this industry standard, until you get a feel for what the landscape look's like.

re: Development:test ratio causing software quality to self-stabilize

erw — Sat, 26 Apr 2008 06:40:08 GMT

everyone talks about code to test ratio but does that go beyond development and include any functional , or system, testing elements?

buy hoodia

buy hoodia — Wed, 16 Jan 2008 12:46:20 GMT

5d03eb05ac:55 Thank you