Software Testing - Defect classification and Severity for the bugs found in TCDs (Test Case Design)

Author

Defect classification and Severity for the bugs found in TCDs (Test Case Design)

SUHAS

2007-02-28, 8:16 am

HI,

Need some help regarding how do we classify the defects found in TCD
and how can we assign the severity for the defects found in TCDs.

Eg Following are some defects for which i need to assign severity -

1.Missing input for a password field. ( min /max length is mentioned
but example is not given , viz- password more than 6 characters
eg:"welcome@123"

2.Missing a test case.

3.Improper/wrong expected result.

4.Incomplete expected results etc...

Thanks in advance.

Regards,
SUHAS.

Phlip

2007-02-28, 10:13 pm

H. S. Lahman wrote:

> Classifying defects and ranking their severity are orthogonal. Figure out
> what the defects are first and then worry about assigning severity.

Tip: Severity belongs to developers, and Priority belongs to the business
side.

Developer: This bugs will shred the hard drive, and might make a
USB drive explode.

Business side: Is there a work around?

Developer: Don't hit that button there.

Business side: We don't need that button for the Trade Show.
Work on all these sexy features first.

> input data. Every test case has input data to be used as stimuli that is
> unique to the test case. Depending on the degree of automation, there can
> be specifications of things like what to test. IOW, it includes anything
> that is specified in external data that the test harness reads.
>
> software state initialization. This is whatever setup the test case
> requires to get the software into a proper state for the test.
>
> execution mechanics. This is infrastructure needed to actually initiate
> the test, exercise the software, and extract the results. If one needs to
> stub return values for unit testing, it would be covered here because one
> is emulating the run-time execution.
>
> results data. This is the specification of expected results.

That is the Assemble Activate Assert pattern:

def test_foo
foo = assemble_foo()
bar = foo.activate()
assert_equal 42, bar
end

The test case:

. Assembles a foo object,
. Activates a method on that foo object,
. and Asserts the method returned the correct value.

> One can argue that any false pass is a Big Problem because it implies a
> field escape while false failures are Small Problems because they are
> always fixed internally without touching the software.

Ah, another way to say "hyperactive test case". My favorite kind, because
under TDD a "false" failure might also mean your edits should have been more
careful. A developer should revert and try again.

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

Michael Bolton

2007-03-01, 7:22 pm

> Need some help regarding how do we classify the defects found in TCD
> and how can we assign the severity for the defects found in TCDs.

Who is "we", and who is asking you to do this? What's the motivation?

---Michael B.

SUHAS

2007-03-02, 4:33 am

On Mar 1, 8:26 pm, "Michael Bolton" <michael.a.bol...@gmail.com>
wrote:
>
> Who is "we", and who is asking you to do this? What's the motivation?
>
> ---Michael B.

Replying to Michael,

I think i didn't put my question in a proper way. Thanks Michael for
asking this question.

Answering to your question , "we" here are the people who are
responsible to review and approve the TCDs.
During reviewing the TCDs, reviewer records all the defects in an
internal tool --Review Tracker.
While logging any defect, reviewer assigns the sevirity for the
defect. This data is used during data collection for QA activities
such as defect predection.
Once the data is collected, all bugs are analysed and during analysis
it was found that for most of the bugs the severity was not given
properly.

i.e for eg: For a defect for a test case which tests the password
field , step was written to test it by entering input more than the
maximum limit , but for the step input example was not given
("welome@123") and for this severity given for the defect was 1 by one
of the reviewer.

So as the severity was not given properly to the defects found the
defect predeciton was wrong.

To summarise it , "we" are the reviewing and approving authoroties of
the TCDs, the defect tracker "asks" us to give the severity and the
"motivation" is defect prevention and predection by defect analysis
(CAR- causal analysis & resolution)
Also the "motivation" to some extend is to identify the training,
awareness required for the person writing the TCD.

Hope I am more clear this time.

-- SUHAS.

Sponsored Links