Suppose you are starting work on a new piece of software that you will need to write automated tests for. Your goal is to cover the most relevant test scenarios that apply to the feature , without missing or forgetting one. Below are a few steps (guidelines) to help you achieve identifying those required scenarios (a sort of 'how i do it and it works for me' guide).
Assumptions: you have user stories/written requirements that cover the entire feature under development, which are refined by means of grooming / technical discussions / planning sessions before work starts.
At first, before writing any automated tests (meaning the code), you will need to identify the scenarios that will have corresponding tests. While you are trying to identify all of them, write them down somewhere. I usually put all of them in the first test class i will write, in my IDE, in a comment section, and will erase them one by one, once i have written the appropriate test case for that scenario. Some useful steps in identifying these scenarios are described below:
Evaluate the feature before all the details are known: before getting into the grooming meeting for the stories you will work on, try to read them with an open mind, trying to understand what the requirement is. This is a good exercise mostly because it helps you see whether you understand what the feature is supposed to do. Write down any questions you have and any test scenarios you might think of at the time. After the grooming you might realize some of them will not be needed. This is because the requirements were not clear enough at the beginning and they might have lead you a bit in the wrong direction. Still, do not erase those scenarios just yet (any wrong direction can become the basis for a useful corner case test).
During the grooming session, pay a lot of attention to the questions people are raising regarding the requirements. Simply listening to the conversation or understanding the point of view of others might lead you to think of ways of using the feature you did not initially consider when reading the stories all by yourself. Write down any keywords or scenarios that pop into mind.
After the grooming / planning, development starts. While developers are busy developing, you will have some time to read the stories again very carefully, this time with confidence that what you read is what really needs to be implemented. Take each acceptance criteria, and write down a happy flow and some negative flows regarding that acceptance criteria.
Think out of the box, think like your customers would. Imagine and go through all the scenarios a regular customer could go when using your application. Then, think about deviations from a regular flow that the customer might encounter. Write those scenarios also.
Talk to the developers randomly about the feature. Let them tell you what they have implemented or are going to implement, how they tend to solve different issues the customer might encounter. Most of them will even suggest some additional test cases (this is because during the previous steps, you were only thinking generically about a feature. That feature has some technology underneath that also has its' limitations or behaves in a certain way).
Draw one or several diagrams of the user's journey while using the product. Do this while all the people working on the feature are present. This helps to validate that everybody has a common understanding of the feature and how it will be used.
Have developers show you snippets of code. While talking directly over the code, you might better understand how the technology beneath the feature behaves and what limitations there are.
Now, the 'thought process' is complete. You feel there is no other scenario you could think of. Now is the time to go through the full list of scenarios you wrote down. Remove all those that are not applicable to your product (flows that a user could never access, those tests you wrote when you thought the feature did something but later realized you understood it wrong, and so on). Basically, remove the rubbish.
Group the scenarios that remain. Depending on the scenarios identified, you could either group them in, let's say, happy, realistic scenarios versus validation scenarios, or edge cases, or infrequent events. Also group them by priority - what are the most common situations the user will experience, what is critical functionality, what is not? Grouping them by priority will determine you to write the most important tests first, identifying possible critical issues early on. After you have identified all the scenarios that you feel comfortable with, start writing your tests, removing them from the list you generated (so that is easy for you to see what remains to be tested). Enjoy your test case writing :)