Today I re-realized the importance of sharing a screen with your users to see exactly what they're doing and the paths they are taking through your software.

I always knew it was important but never thought of it as a way of testing beta software. Users will often come up with ways of doing stuff that you never thought of.

So in my realization of this today I pose the question of; What are the forms of testing that testers commonly forget?

  • 3
    I like this question, but it does fall into a category of 'avoided subjectivity', specifically "every answer is equally valid." I'm not sure how to rephrase the question such that it conforms, and I don't really want to vote to close as it has great potential to be a useful resource, but I do have a small issue with it's current form.
    – corsiKa
    Commented May 12, 2011 at 16:37
  • 2
    Rather than just "most important", how about editing it to just "What are the forms of testing that testers commonly forget?" That allows for the same kinds of answers that are already being given without the subjectivity of opinion of the words "most important". Commented May 13, 2011 at 2:39
  • 1
    Updated as suggested Commented May 13, 2011 at 10:30

11 Answers 11


Usability testing, because while QA may assist in the process, the actual test participants are probably not QA people.

  • This is a good one too. I often have usability testing low on my list, especially for internal applications. Commented May 12, 2011 at 15:20
  • +1 Usability as some would stress so much about making sure what is required is fixed that usability is not stressed enough
    – user205
    Commented May 12, 2011 at 15:32
  • +1, and I find the problem is exaggerated by people thinking it's not necessary. I remember usability testing, but it's politically inconvenient (company politics, not government), so it still tends not to happen. Commented May 13, 2011 at 17:43
  • I found that when UI or programmable API are designed without usability in mind, then they are not only hard to use to end-users, but also ambiguous to implement by developers.
    – dzieciou
    Commented Jan 24, 2013 at 19:44
  • It depends upon the product, but I have first-hand experience with low-cost, low-effort usability testing that provides valuable feedback.
    – user246
    Commented Jan 24, 2013 at 19:52

Basic exploratory testing for the most simple of functions..

Historical usage examples tend to push people into a direction of "that's always broken" or "that's always worked" .. the worst thing is not checking either, to find out whether they work now.

  • Would you cover this with up-to-date regression testing? Commented May 12, 2011 at 15:19
  • I believe that you 'could' to a certain degree yes. The same applies however. I've been guilty of this from time-to-time. i.e. - I ran Control Panel Regressions for 16 months solid (repetitively, not one set ;) ) - this lead me to 'historical' knowledge of things that just didn't get prioritised and thus never got fixed. I started ignoring them and blindly setting the status. --- This doesn't happen anymore, but you're right that regressions must be 'Up-To-Date' to be useful. Commented May 12, 2011 at 17:19

The question is quite broad I think and depends on what sort of application/software you are testing. However if you're testing a gui app one common thing that can slip your mind is Usability and those annoying grammar/spelling mistakes. But again depends on what you are testing and how deep you will be willing to go.

  • Grammar/Spelling mistakes often plague me as well. I'll be demo'ing a product and I'll see it and hope that the client doesn't. Commented May 12, 2011 at 15:41
  • 1
    Agreed. That's something that goes towards the "polish" of a finished product. There's a lot of focus on the big functionality but what makes users come back to a product is not just whether or not it meets their needs, but whether it is clean and polished while doing so. Commented May 13, 2011 at 12:50

Negative testing is one that, while not forgotten, gets left behind when the time crunch comes in. For example, say a message response has a limited set of valid numeric values (1, 2, 3, 4). What if a response is sent that is outside of that range of numerics (6, 10, 0, -1)? What if the data type sent back doesn't match (1.5, 0.2, "blue", BLOB)? What if the response back is empty or null? Especially when working with an application that is open to the general user public (as many web applications are), there's the problem of end user training that is always missing and so the end users may enter in unexpected values.

Too often, from developers, I've gotten the response "No user will ever do that" only to have, once the feature is released, a user doing precisely that action and having it cause major problems in the application.


We tend to skimp on performance testing. We all know it needs done, but it always seems to be left for last/dropped completely when we get to the end of a project window.

My guess is you are going to get as many different answers as there are testing methods out there. Depends on the person & the shop they are currently working in.


Where I work, load testing is often forgotten because it's not easy to coordinate and it consumes a lot of scarce resource.

On a more generic note, functions or features that don't get a lot of use in the general run of things are very easy to forget. A lot of "one time" "set and forget" features fall into this category, especially if you work with predefined data sets and don't do all that much configuration as part of the standard testing process.


Verifying what version is loaded on the machine I'm testing... I tend to miss the very basic things and jumps to the more interesting things, checklists helps to avoid misses like that.


Tester's usually tend to forget usability and random testing. I am sure usability is a very low priority in major application's but this kind of testing helps in getting major credibility.

  • By random testing do you mean fuzz testing? I found it to be the same in this paper.
    – dzieciou
    Commented Jun 4, 2012 at 23:03

The "non-intended use case" scenario -- using a feature in exactly the wrong way. Most rookie testers have a tough time conceptualizing this in their nuts-and-bolts testing.


My view point will be based on QUALITY (ISO 9001) :


Quality is compliance with requirements. Testing is making sure requirements are fullfilled.

So a large part of the answer is : What are the types of requirements that specifiers commonly forget.

If something is not explicited in the requirements, it can't be tested (tested against what : ? the tester opinion ?).

Example : usability. Proper usability should be explored as part of functional analysis, with eg prototypes. If it's not in this upstream phase, then it will raise issues in downstream phase for sure ...

Traceability is here not to forget testing requirements. It implies some "requirement management" and in case there are "forgotten tests", it may be a good approach for improvement.


ISO 9001 also proposes to tests against intended usage (called "validation" as opposed to verification). This is when you drive the car live on the road to "test" it.

Here usability comes back in light ... So here the question is : in the project construction, is there a phase like "customer validation" ?


Most of the times, it is the UI related things (cross-browser).

From functional point of view, I keep a checklist so that nothing is missed what was tested in previous release. Still combinations are n so covering all is not possible leading to non-intended issues.

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.