Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
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?
Usability testing, because while QA may assist in the process, the actual test participants are probably not QA people.
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.
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.
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.
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) :
1/ ISO 9001 VERIFICATION :
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.
2/ ISO 9001 VALIDATION :
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.
