top of page

Software Defects


The main objective of developers is to write code to create software, while testers primarily aim to find defects or bugs in the developer's software. Let's examine what defects and bugs are.


Defects or Bugs in Software:

Software functionalities that do not match the requirement specifications are referred to as defects or bugs.


These occur when requirements are incorrectly coded, causing some components or functions to not align with the requirement specifications. These defects frequently arise due to:

  • Omission of code implementing the requirements listed in the requirement specification.

  • Coding of requirements not specified in the requirement document, often due to developer oversight.

Example: Requirement as per the specification: When a user clicks the 'Home' link on a webpage, the "Home" page should be displayed. The tester observes during testing that clicking the 'Home' link displays the 'About me' page instead, deviating from the requirement specifications. This is an example of a software defect.



software defect


2. 'Omitted Requirement Specification' Defects:

A valid requirement that must be coded (or implemented) is omitted. The root cause of this error is the failure to capture this requirement in the specification documents. Observations reveal that "requirements were omitted" because the requirements were missed in the requirement specification documents. These types of defects are typically caused by inadequate analysis and supervision processes.


Example: During website testing, the tester notices the 'Disclaimer' link is missing. According to website governance regulations/guidelines, displaying the "Disclaimer" link is mandatory. Therefore, testers conclude that the "Disclaimer" link is missing, and developers will fix this defect.


3. 'New Requirement Specification' Defects:

A requirement not initially within the project scope to be coded (or implemented) is later identified as necessary to address potential risks during development (or post-implementation). These types of defects are usually caused by inexperienced requirement analysts in evaluating the project's success or failure scope.


Example: According to the technical specification: System A transmits data to System B for processing. System B is responsible for:

  • Filtering student records of those who scored over 80% in exams.

  • Sending the filtered records to the scholarship department. During system integration testing, the tester discovers data not transferring to System B. Further investigation reveals the root cause is limited system memory, causing System B to fail to load any data, even though System A transmitted over 100,000 student records. To resolve this issue, project stakeholders decide to create an additional (or new) requirement. Hence, the additional (or new) requirement is documented as follows:

  • System A: Transmits student records (containing information on each student) to System C.

  • System C: Optimizes the process of transmitting (or handling) large data volumes, filtering records of students who scored over 80% in exams, and sends these to System B for further processing.

  • System B: Sends the filtered student records to the scholarship department.

Comments


bottom of page