I'm an intern at a small custom software company that was hired to help test some of their in house software. They didn't have the time or resources to hire a full time person for testing so they are starting out with an internship.

My main responsibility is to come up with business scenarios, use cases, and turn those into test cases.

I didn't know anything about testing before this and the internship has not been as structured as previous ones that I have had, so I feel like my productivity has not nearly as high as I would like.

So far I have documented a few test scenarios for some features, and I have made a proof of concept of how I would expect an automated test suite to work with selenium2, sauce labs, and some spreadsheets converted into CSV files.

I also stumbled on a BIG hole on their website as far as security goes, but they don't seem all that concerned. I'm glad I've at least found something.

I have learned a lot from the internship but I'm just not sure if I've given them much value back.

I apologize if my issue appears to be vague. I'm really just kind of venting.

My main question is really what does a schedule/workflow for a QA tester look like? How do you work your way through one feature on a webpage app?

I feel like my biggest weakness is just my lack of focus/organization.

  • 2
    Mate, you are an intern. You're not supposed to know what to do coming in, they're supposed to support and mentor you. If the company doesn't get much value back from you, given what sounds like a complete lack of feedback and structure, then that's exactly what they deserve. I hate companies who are too cheap to hire professionals, so they hire an intern and then surprise!, because they don't have any professionals or any semblance of a clue about what the pro does there's nobody to support the intern! It's not you. It's them. Learn, and move on to a more clueful company as fast as you can!
    – testerab
    Jan 1, 2014 at 12:47
  • @testerab I appreciate the supportive comment. To be fair to the business I don't think they're trying to cut costs or that they don't value testing, I feel that they thought an internship was the best solution to a tough issue of finding out how to get rolling as far as testing is concerned.
    – ebgranger
    Jan 2, 2014 at 13:49
  • 2
    Honestly? Using an intern without mentorship as a way to do proof of concept for hiring a "real" tester is a pretty rough way to treat the intern and testing. It looks like you're on the right track with what you're doing, which is good, and Ktash's answer covers everything I'd suggest. The main thing is that in any testing situation, there's NO "typical". I swear most of my answers here start with "it depends".
    – Kate Paulk
    Jan 2, 2014 at 17:44
  • @KatePaulk I can agree with that for sure. I just want to be clear that I don't really have any animosity towards my employer. I've learned a TON from this internship and even if things haven't been ideal, I still know their mind/hearts were in the right place when they decided to do this.
    – ebgranger
    Jan 2, 2014 at 18:21
  • @ebgranger - I understand. You and your employer are gaining from this experience even if it's a long way from ideal. Hopefully they will see from the experience that they do need a permanent test specialist and they need to mentor their interns! It sounds to me like you've learned plenty already and will keep learning - you have the right mindset for it.
    – Kate Paulk
    Jan 3, 2014 at 12:56

1 Answer 1


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.

  1. Talk to the engineer about the feature
  2. 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
  3. Write down the proper "perfect" use case
  4. Go through each step, and think of every way the dumbest person you know might mess up that step
  5. Go through each step, and think of how a malicious user might try and exploit that
  6. Go through each step, and think of all the possible valid values/interactions a user might use
  7. Go through each step, and think of all the possible invalid values/interactions a user might use
  8. Pat yourself on the back
  9. Now think of every possible feature that this feature might interact with
  10. Repeat the steps above for each of these other feature interactions
  11. Remember to breathe. Always breathe. This is important.
  12. Panic a little
  13. Now think of how the combinations of each of the above feature combinations might interact with other features
  14. Panic a lot
  15. Stop panicking, and repeat all of those steps above for each of these features
  16. Make sure you've written stuff down outlining the steps above, so that someone else can panic about this all later
  • Thank you very much for the feedback. I'm glad to know that I'm at least a little bit on the right track by writing down the "sunny day" use case first, and figuring out all the possible bugs from there.
    – ebgranger
    Jan 2, 2014 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.