A quality characteristic is an aspect of system quality used to organize testing risks and focus analysis on what matters to users. Examples include functionality, data integrity, security, accuracy, accessibility, performance, interoperability, usability, and reliability-related concerns. section 1.2.2 section 8.1.1
Use quality characteristics to constrain and structure testing work:
- Specify the characteristics an LLM should use when generating test ideas from a feature and its acceptance criteria. section 1.2.2
- Generate questions that expose ambiguities in user stories, with multiple questions allowed for each selected characteristic. section 4.2.1
- Review code for risks grouped by characteristics such as performance, security, and interoperability. section 4.2.2
- Expand an existing risk list while excluding duplicates and irrelevant characteristics. section 8.1.1
File-upload risk analysis
A prompt for a secure document-upload feature asks an LLM to suggest test ideas focused on Functionality, Data Integrity, and Security. The resulting checks cover supported formats, the 20MB boundary, upload progress, initial access permissions, document content, and audit records. The selected characteristics keep the analysis aligned with concrete risks rather than inviting unrestricted suggestions. section 1.2.2
###
public BookingResult createBooking(Booking bookingToCreate) throws
➥SQLException {
if(dateCheckValidator.isValid(bookingToCreate.getBookingDates())) {
if (bookingDB.checkForBookingConflict(bookingToCreate)) {
return new BookingResult(HttpStatus.CONFLICT);
} else {
CreatedBooking createdBooking =
➥bookingDB.create(bookingToCreate);
if(bookingToCreate.getEmail() != null &&
➥bookingToCreate.getPhone() != null){
MessageBuilder messageBuilder = new MessageBuilder();
Message message = messageBuilder.build(bookingToCreate);
messageRequests.postMessage(message);
}
return new BookingResult(createdBooking,
➥HttpStatus.CREATED);
}
} else {
return new BookingResult(HttpStatus.CONFLICT);
}
}
###
Inspect a booking method to see how code can be reviewed for characteristic-specific risks, including nested validation and message-posting performance concerns. section 4.2.2
