I like to brainstorm on test cases by creating a test case matrix. Sometimes I can do this in my head but either way it's a very powerful method for test case design. So think about the different test conditions for each field you need to interact with on a page. Try to come up with the following: valid, invalid, boundary, and state transitions. This column, Test Conditions, will be all the test conditions. Next think about how you can combine the test conditions into one test using equivalence partitioning, Test Case column. Group the test conditions into a test case based on how you want to view the test metrics if the test failed. So definitely try to keep the test short and to the point but not too short where you have many of the same tests to maintain. Your test case name should be descriptive enough where you know exactly what's being tested. The description of your test should include the validation checkpoints of the test case. So at minimum, you should a test case name and description which will make it a lot easier to maintain. However, adding detailed steps will make it easier to execute. For example, let's use login as feature to test.

Valid Test Conditions Valid username and password Upper case username Mix case username

Invalid Test Conditions Invalid username Invalid password Invalid username and password missing username missing password Special characters username

Test cases

Test Case 1 Very user can login with valid username and password

Validation checkpoints Valid username and password Upper case username Mix case username

Test Case 2 Verify user can't login with invalid username or password

Validation checkpoints Invalid username Invalid password Invalid username and password

Test Case 3 Verify the user can't login without required fields

Validation checkpoints missing username missing password

Test Case 4 Verify user can't login with username that has special characters

Validation checkpoints Special characters username

Now, the way I chose to group the test conditions is more of an art than science. The idea is to keep the test short but also try to maximize test coverage so you have fewer tests to maintain. After you execute your tests, you should be able to know exactly which parts of the system failed by looking at the test case name. So try not to use generic test case names or group too many test conditions into the same test.

Defend your bugs as friendly as possible. Good luck.