Software Errors
One common definition of a software error is a mismatch between the program and its specification. In other words, we can say, a software error is present in a program when the program does not do what its end user expects.Categories of Software Errors:
User interface errors such as output errors or incorrect user messages.Function errorsHardware defectsIncorrect program versionRequirements errors Design errors Documentation errors Architecture errors Module interface errors Performance errors Boundary-related errors Logic errors such as calculation errors, State-based behavior errors, Communication errors, Program structure errors, such as control-flow errors. Most programmers are rather cavalier about controlling the quality of the software they write. They bang out some code, run it through some fairly obvious ad hoc tests, and if it seems okay, they’re done. While this approach may work all right for small, personal programs, it doesn’t cut the mustard for professional software development. Modern software engineering practices include considerable effort directed toward software quality assurance and testing. The idea, of course, is to produce a high software with the probability of satisfying the customer’s needs.There are two ways to deliver software free of errors:
Preventing the introduction of errors in the first place. Identifying the bugs lurking in program code, seek them out, and destroy them. Obviously, the first method is superior. A big part of software quality comes from doing a good job of defining the requirements for the system you’re building and designing a software solution that will satisfy those requirements. Testing concentrates on detecting those errors that creep in despite your best efforts to keep them out.
Classification of Defects / Bugs
There are various ways in which we can classify. Below are some of the classifications:
Severity Wise:
Major: A defect, which will cause an observable product failure or departure from requirements.
Minor: A defect that will not cause a failure in execution of the product.
Fatal: A defect that will cause the system to crash or close abruptly or effect other applications.
Work product wise:
SSD: A defect from System Study document
FSD: A defect from Functional Specification document
ADS: A defect from Architectural Design Document
DDS: A defect from Detailed Design document
Source code: A defect from Source code
Test Plan/ Test Cases: A defect from Test Plan/ Test Cases
User Documentation: A defect from User manuals, Operating manuals
Type of Errors Wise:
Comments: Inadequate/ incorrect/ misleading or missing comments in the source code
Computational Error: Improper computation of the formulae / improper business validations in code.
Data error: Incorrect data population / update in database
Database Error: Error in the database schema/Design
Missing Design: Design features/approach missed/not documented in the design document and hence does not correspond to requirements
Inadequate or sub optimal Design: Design features/approach needs additional inputs for it to be completeDesign features described does not provide the best approach (optimal approach) towards the solution required
In correct Design: Wrong or inaccurate Design
Ambiguous Design: Design feature/approach is not clear to the reviewer. Also includes ambiguous use of words or unclear design features.
Boundary Conditions Neglected: Boundary conditions not addressed/incorrect
Interface Error: Internal or external to application interfacing error, Incorrect handling of passing parameters, Incorrect alignment, incorrect/misplaced fields/objects, un friendly window/screen positions
Logic Error: Missing or Inadequate or irrelevant or ambiguous functionality in source code
Message Error: Inadequate/ incorrect/ misleading or missing error messages in source code
Navigation Error: Navigation not coded correctly in source code
Performance Error: An error related to performance/optimality of the code
Missing Requirements: Implicit/Explicit requirements are missed/not documented during requirement phase
Inadequate Requirements: Requirement needs additional inputs for to be complete
Incorrect Requirements: Wrong or inaccurate requirements
Ambiguous Requirements: Requirement is not clear to the reviewer. Also includes ambiguous use of words – e.g. Like, such as, may be, could be, might etc.
Sequencing / Timing Error: Error due to incorrect/missing consideration to timeouts and improper/missing sequencing in source code.
Standards: Standards not followed like improper exception handling, use of E & D Formats and project related design/requirements/coding standards
System Error: Hardware and Operating System related error, Memory leak
Test Plan / Cases Error: Inadequate/ incorrect/ ambiguous or duplicate or missing - Test Plan/ Test Cases & Test Scripts, Incorrect/Incomplete test setup
Typographical Error: Spelling / Grammar mistake in documents/source code
Variable Declaration Error: Improper declaration / usage of variables, Type mismatch error in source code
Status Wise:
Open
Closed
Deferred
Cancelled
Bug Life Cycle
The steps in defect life cycle varies from company to company. But the basic flow remains the same. However, below I'm describing a basic flow for Bug Life Cycle:
A Tester finds a bug. Status --> Open
Test lead review the bug and authoriza the bug. Stats --> Open
Development team lead review the defect. Stats --> Open
The defect can be authorized or unauthorized by the development team. (Here the status of the defect / bug will be Open (For Authorized Defects) & Reject (For Unauthorized Defects).
Now, the authorized bugs will get fixed or deferred by the development team. Status of the fixed bugs will be Fixed & Status will be Deferred for the bugs which got Deferred.
The Fixed bugs will be again re-tested by the testing team (Here based on the Closure of the Bug, the status will be made as Closed or if the bug still remains, it will be re-raised and status will be Re-opened.
The above-mentioned cycle continues until all the bugs / defects gets fixed in the application.
Software Testing Bug Report
If you are doing manual Software Testing and reporting bugs withour the help of any tool, assign a unique number to each bug report. This will help to identify the bug record.
Clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step.
Be Specific and to the point
Apart from these tips, below are some good practices:
Report the problem immediately
Reproduce the bug atleast one more time before you report it
Test the same bug occurrence on other similar modules of the application
Read bug report before you submit it or send it.
Never ever criticize any developer or attack any individual.
Software Testing Bug Report Template
If you are using any Software Testing Management tool or any Bug reporting tool like Bugzilla or Test Director or Bughost or any other online bug tracking tool, then; the tool will automatically generate the bug report. If you are not using any tool, you may refer to the following template for your software bug report:
Name of Reporter:
Email Id of Reporter:
Version or Build:
Module or component:
Platform / Operating System:
Type of error:
Priority:
Severity:
Status:
Assigned to:
Summary:
Description:
No comments:
Post a Comment