You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the test strategy & approach for this feature, and describe how the approach verifies the functions delivered by this feature.
For any feature, be aware that only FAT tests (not unit or BVT) are executed in our cross platform testing. To ensure cross platform testing ensure you have sufficient FAT coverage to verify the feature.
If delivering tests outside of the standard Liberty FAT framework, do the tests push the results into cognitive testing database (if not, consult with the CSI Team who can provide advice and verify if results are being received)?
List of FAT projects affected
Test strategy
New and updated functionality:
extensions attribute added to most annotations 387
TCKs cover using the extensions attribute on one standard annotation, one container annotation and applying the @Extension annotation directly to a method.
More TCKs exhaustively cover each new extensions attribute
Improvements to the definition of security requirements 483, 468
Define behavior of @SecurityRequirementsSet and make it repeatable
Clarify that a individual @SecurityRequirement annotation applied to a class or method is equivalent to a @SecurityRequirementsSet annotation containing that @SecurityRequirement annotation
Add securitySets attribute to @OpenAPIDefinition and @CallbackOperation
Collectively as a team you need to assess your confidence in the testing delivered based on the values below. This should be done as a team and not an individual to ensure more eyes are on it and that pressures to deliver quickly are absorbed by the team as a whole.
Please indicate your confidence in the testing (up to and including FAT) delivered with this feature by selecting one of these values:
3 - We have delivered all automated testing we believe is needed for the golden paths of this feature and minimal coverage of the error/outlying scenarios. There is a risk when the feature is used outside the golden paths however we are confident on the golden path. Note: This may still be a valid end state for a feature... things like Beta features may well suffice at this level.
We currently only have manual testing for the UI, though it checks all of our customizations and touches all of the core functionality as well as some more obscure bits and we perform the testing every time we make any change to the UI projects.
We think we have good coverage of all new functionality added in this release including outlying scenarios, though there are a few unlikely error cases not tested.
The text was updated successfully, but these errors were encountered:
Test Strategy
Describe the test strategy & approach for this feature, and describe how the approach verifies the functions delivered by this feature.
For any feature, be aware that only FAT tests (not unit or BVT) are executed in our cross platform testing. To ensure cross platform testing ensure you have sufficient FAT coverage to verify the feature.
If delivering tests outside of the standard Liberty FAT framework, do the tests push the results into cognitive testing database (if not, consult with the CSI Team who can provide advice and verify if results are being received)?
List of FAT projects affected
Test strategy
New and updated functionality:
extensions
attribute added to most annotations 387extensions
attribute on one standard annotation, one container annotation and applying the@Extension
annotation directly to a method.extensions
attribute@SecurityRequirementsSet
and make it repeatable@SecurityRequirement
annotation applied to a class or method is equivalent to a@SecurityRequirementsSet
annotation containing that@SecurityRequirement
annotationsecuritySets
attribute to@OpenAPIDefinition
and@CallbackOperation
@SecurityRequirementsSet
, includes requirement for multiple auth methods and for optional authentication@SecurityRequirementsSet
on a resource method@SecurityRequirementsSet
in thesecuritySets
attribute of@OpenAPIDefinition
@SecurityRequirementsSet
in thesecuritySets
attribute of@CallbackOperation
(added in #539)additionalProperties
attribute to@Schema
423True
,False
andString
@APIResponse
to be applied to a class, indicating that every resource method on that class has that response 417@APIResponse
on a resource class@APIResponse
on an exception mapper classmp.openapi.scan.*
config properties 422Which FAT projects are affected?
io.openliberty.microprofile.openapi.3.1.internal_fat_tck
io.openliberty.microprofile.openapi.2.0.internal
,com.ibm.ws.microprofile.openapi_fat
What manual tests are there (if any)? (Note: Automated testing is expected for all features with manual testing considered an exception to the rule.)
Confidence Level
Collectively as a team you need to assess your confidence in the testing delivered based on the values below. This should be done as a team and not an individual to ensure more eyes are on it and that pressures to deliver quickly are absorbed by the team as a whole.
Please indicate your confidence in the testing (up to and including FAT) delivered with this feature by selecting one of these values:
3 - We have delivered all automated testing we believe is needed for the golden paths of this feature and minimal coverage of the error/outlying scenarios. There is a risk when the feature is used outside the golden paths however we are confident on the golden path. Note: This may still be a valid end state for a feature... things like Beta features may well suffice at this level.
We currently only have manual testing for the UI, though it checks all of our customizations and touches all of the core functionality as well as some more obscure bits and we perform the testing every time we make any change to the UI projects.
We think we have good coverage of all new functionality added in this release including outlying scenarios, though there are a few unlikely error cases not tested.
The text was updated successfully, but these errors were encountered: