Listing all possible test case names which could be extracted out of the scenario provided and classifying them in terms of priority and positive/negative/types is test case enumeration. Kindly comment if you need anything, here is an example for better understanding. Enumerate test cases for Login:(Classifying priorities into P1>P2>P3) Positive cases include:
P1-Verify the login dialog box
P1-Verify the login id
P1-Verify the password
P1-Verify the submit button
Negative cases include: 1. P3-Verify logging in with empty id and password fields
Note: Haven't covered all the test cases.
In my team we track tickets deviation by using two things:
Jira filters subscription for cases where we need plain(to one person/lead/manager) notification, but without fields analysis
https://github.com/dgroup/lazylead for cases where we need automatically check ticket fields, comments, links and alert corresponding person, assignee or reporter. Please note that i'm author of https://github.com/dgroup/lazylead app.
@zymir The pass/fail criteria of the test depends on the specification - on what result you expect from a particular module, in the case of integration testing - what do you expect as the result of the work of several modules in a bundle. The point of integration testing is to make sure that the modules work correctly in the process of interacting with each other, and not separately. For example, a criterion for the success of testing a class that filters data can be checking what data is found and whether there is extra data there. This is already at your mercy as a developer.
What are triangles?
On both sides:
Isosceles, not equilateral
At the corners: if the function can return a list of features, because they do not exclude those above
Acute (all angles less than 90)
Rectangular (One corner 90)
Obtuse (One angle> 90)
What are not?
a + b == c (degenerate triangle with zero area)
a + b> c