It is hard to say what your workflow will be. I've worked a few SDET/QA jobs, and it really seems to vary quite a bit. I'll try to cover some of my experiences, though, and hopefully that will be helpful.
Everyday Things
I usually like to start my day with a little bit of blackbox, just to get my brain into motion. I'll spend a little while every morning just playing around with an area of the app that I haven't used in a while. I'll do some boundary testing, maybe a bit of workflow, and some UI/UX stuff, just to keep it lively. For me, I think of this like stretching before your workout. Just get your brain in the proper mode to break stuff.
Now, I say this as someone whose job involves both black box and white box testing, but as I said early, this varies depending on your place. At this point, I'll focus a bit more on each type of testing, though I personally feel being good, or at least understanding both sides of the coin is important.
Black Box
In the black box parts of my day, most of the time it will vary slightly by where in the release cycle we are in. If we are early in the release cycle, I spend my time talking with engineers about features they've been working on, and looking at and testing these things in a very focused manner. As the feature develops, I'll start to branch out and test more broadly the integration with other features, and the interactions between all the moving pieces, but I usually start small. If you have formal written test cases (I'd recommend you always do), this is a great time to write down what the feature does get workflows and usage scenarios written down. The amount of detail you go into and the granularity of your cases and scenarios varies by company, and by person. I tend to write more broad overviews of things so I don't spend a lot of time rewriting things as they get out of date, but some prefer step-by-step instructions so they don't miss anything. Just a matter of taste (in my opinion).
If we are late in the product cycle, I usually step back from the product, and work on the end to end workflows. This is when I stop focusing on the areas, and start focusing on everything as a whole. I write scenarios that will take me through several different features, but be more typical to a user experience. It is important to remember that your use won't do the right thing, though, so you'll want to make sure to include "bad" workflows too. Taking notes during meetings with engineers early in the cycle, and calling out specific areas that might cause trouble can be a life saver at this stage. The focus here is on the whole thing, and less on the pieces.
Now, if you're in a continuous deployment system (like a website), this breaks down a bit. And in these cases, you'll want to make sure you're aware what is changing, and have staging environments to do testing as things get modified. This type of testing is a lot more chaotic, but not uncommon.
White Box
As a white box tester, my day is spent looking at what code is changing in the code base. I watch what check-ins come in, look through the code, and see if there are any repercussions they may have missed. A lot of times this means bouncing back to black box to test things out, but with educated guesses on what might be wrong. Having a good knowledge of the source code is very helpful, but knowing how the code works on a higher level is even more important in my opinion. Making sure you know which Jenga pieces might cause the tower to fall.
Now, at my current job, unit and integration tests are written by the developer checking in the code, but I've had other jobs where that is the responsibility of the QE. This will vary, but if you are writing the tests yourself, you'll want to make sure you are writing thorough unit and integration tests for almost all the code going in. Throwing crazy things at the function is the best way to get it to break. And on the web, with all the chaos out there, crazy things will hit every function that will ever see any input, believe me. On a day to day, though, I found myself more looking at code then writing the tests, but this is one case where you are really always playing catch-up. That's ok. Your priorities will shift quickly as new code comes in, and boundary testing may have to wait for the 1 function that only gets called once. Just make sure you're on top of code changes is the key.
My Days are Chaos
I'm not sure I've ever had two days in a row where I've done the same thing, and I know that most weeks I don't accurately guess what I'm going to have accomplished by the end of the week. Things change quickly as a QA. You'll spend a lot of your time filing, verifying, and testing bugs, and a lot of your time doing everything but that. Some days will be about writing scenarios, talking with engineers and UX people, and thinking through workflows, and some days you'll be testing the crap out of that one little piece of code and won't even be thinking about the role that cog plays. And that's ok.
What's my average day look like? I don't have one. I spend a lot of time, doing a lot of testing, and can get pulled in several different directions at once. Some days I'm pouring over code, and some days I'm just copy/pasting Romeo and Juliet into every text field I can find. It is just going to vary. At least in my experience, at the pace things operate at these days. Especially on the web.
Working through a web app feature
Your other question, about how to work through a feature on a web app, varies a lot. But here's a simple checklist for what I usually do when starting with a new feature.
- Talk to the engineer about the feature
- Talk some more to the engineer about the feature
- Seriously, it may seem obviously, but often times they can give you some good ideas on areas that you might want to test. You don't always want to let them limit you, but sometimes they may point out areas you hadn't thought of
- Write down the proper "perfect" use case
- Go through each step, and think of every way the dumbest person you know might mess up that step
- Go through each step, and think of how a malicious user might try and exploit that
- Go through each step, and think of all the possible valid values/interactions a user might use
- Go through each step, and think of all the possible invalid values/interactions a user might use
- Pat yourself on the back
- Now think of every possible feature that this feature might interact with
- Repeat the steps above for each of these other feature interactions
- Remember to breathe. Always breathe. This is important.
- Panic a little
- Now think of how the combinations of each of the above feature combinations might interact with other features
- Panic a lot
- Stop panicking, and repeat all of those steps above for each of these features
- Make sure you've written stuff down outlining the steps above, so that someone else can panic about this all later
