Software Defect Process
The below standards are followed for TTEC Digital product bug classifications for the Outbound Contact Manager application.
Software defect nature
The initial bug triage is to classify a bug nature, based on the type of defect that has been found. Any user raising / triaging a bug can classify the bug’s nature. To do this, we use the following nature types levels:
Functional defects
Functional defects are the errors identified in case the behavior of software is not compliant with the functional requirements. Such types of defects are discovered via functional testing. For example, in one of our recent testing projects, a functional defect was found where a search didn’t return any results when a user typed in an email address.
Performance defects
Performance defects are those bound to software’s speed, stability, response time, and resource consumption, and are discovered during performance testing. An example of a performance defect is a system’s response time being X times longer than that stated in the requirements.
Usability defects
Usability defects make an application inconvenient to use and, thus, hamper a user’s experience with the software. A content layout that is difficult to scan or navigate and an overly complex signup procedure are examples of usability defects. To identify such defects, VoiceFoundry test engineers and business analysts (or UX designers) validate software against usability requirements and Web Content Accessibility Guidelines (WCAG) during usability testing.
Compatibility defects
An application with compatibility errors doesn’t show consistent performance on particular types of hardware, operating systems, browsers, and devices or when integrated with certain software or operating under certain network configurations. Compatibility testing is carried out in order to discover such issues. For instance, testing uncovered that it failed to behave according to the requirements of Google Chrome. The defects were related to the changes in font size, content alignment, and scroll bar.
Security defects
Security defects are the weaknesses allowing for a potential security attack. The most frequent security defects in projects we perform security testing for are encryption errors, susceptibility to SQL injections, XSS vulnerabilities, buffer overflows, weak authentication, and logical errors in role-based access”.
Software defects severity
After classifying a defect by Nature, we assign a severity based on the technical impact a defect has on a system. A TTEC Digital Senior developer identifies the defect severity. To do this, we use the following severity levels:
Critical defects usually block an entire system’s or module’s functionality, and testing cannot proceed further without such a defect being fixed. An example of a critical defect is an application returning a server error message after a login attempt.
High-severity defects affect the key functionality of an application, and the app behaves in a way that is strongly different from the one stated in the requirements, for instance, an email service provider does not allow adding more than one email address to the recipient field.
Medium-severity defects are identified in case a minor function does not behave in a way stated in the requirements. An example of such a defect is a broken link in an application’s Terms and Requirements section.
Low-severity defects are primarily related to an application’s UI and may include such an example as a slightly different size or color of a button.
Software defects priority
A defect priority characterizes a defect's business impact. After classifying a defect's nature & severity, we identify a priority in which that defect needs to be resolved. The product owner or an authorized business stakeholder identifies the defect priority. To do this, we use the following priority levels:
Urgent defects take all precident over other workload priorities, after being reported. Only Defects with a critical severity status fall in this category. All other work must be deprioritised and efforts focused to resolve in the shortest possible time. However, low-severity defects may be classified as urgent-priority as well. For instance, a typo in a company’s name on an application’s home page doesn’t have a technical impact on software, but has a major business impact, hence, is classified as urgent.
High-priority defects are the errors that must be fixed in an upcoming release in order to meet the exit criteria. An example of a high-priority defect is an application’s failure to navigate a user from the login page to the home page even though a user has entered valid login data.
Medium-priority defects are errors that may be fixed after an upcoming release or in the subsequent release. An application returning the expected result, which, however, formats incorrectly in a particular browser, is an example of a medium-priority defect.
Low-priority defects are the errors that do not need to be fixed in order to meet the QA exit criteria of of a release but require fixing before an application becomes generally available. Typos, alignment, element size, and other cosmetic UI issues are usually included in this group.