Quality Testing

Quality is delighting customers

What are non testable requirements? Can pls anyone  give a couple of examples?

Views: 6885

Reply to This

Replies to This Discussion

Testable requirements: The requirements which we are going to test it in current release are called as Testable                                                      Requirements

Non-Testable requirements: The requirements which we are not going to test in current release are called as Non-Testable                                      requirements.


Based on the release only  we can classify the requirements.

Here are examples of non-testable requirements:

  • The user interface must look modern and attractive.
  • The application must be fast.
  • The user interface must be very responsive.

These Requirements are not complete and needs further investigation / demonstarion/discussion to make them more testable requirements.


In my opinion, the non testable requirments could be something like, proudct to be "ready to release " before the close of this FInancial Year.  SHould not exceed A definite Manmonths of effort, SHould be based on specific technologies and not Vague term (like Latest Technologies) etc.

@Bill:Do u think "The application must be fast" is non testable requirements?

@Chandan Pandit: Yes, I do.  The problem with "The application must be fast" is that "fast" is not quantifiable.  As A Krishna R Sarkar suggested, if the requirement were more specific, it might be made testable.  In a perfect world, requirements like this would never show up on a test person's desk, but sometimes they do.


Regarding the other examples above, "ready to release before close of this financial year" and "should not exceed N man months" are requirements for the project schedule, not for the product itself.  


I think "Should be based on XXX technologies" is testable.


Sometimes a requirement is non-testable because of a lack of resources.  If you have a requirement that your cricket website handle 100,000 transactions a second, but you don't have enough client machines (or network bandwidth, or server machines, or whatever) to perform that test, then for you, the requirement is not testable.

The application must be fast does not describe you how fast it should be.Like it should respond within 3 seconds etc.Thats why it is non testable requirement.It does not describe exactly to decide of an out put.

In my knowledge,If any requirement takes time to find an reasonable output by a tester to check whether it is correct or not  is non-testable.

Yes.  For example, if you are testing optimization software, and the requirement is that the product always determines the best solution to a problem, you as a tester might have to compare every other possible solution against the product's solution.  For big enough inputs, that won't be possible in a reasonable amount of time.

@Bill:Tell me one thing.

If some one will give you bank website to test & in the requirement respond time is not specified then what you will do?

You will test speed or not?


That's a reasonable question, Chandan.  And as a matter of fact, I once worked in a QA group at a bank!  (I work somewhere else now.)


Sometimes the bank doesn't particularly care about performance.  Or to put it another way, the bank already knows that the performance is good enough for how the product will be used.  Or if the product does not have any competitors, it may be acceptable for the product to be slow because it provides a function that no other product can provide.  (In my experience, banks are not usually innovative in that way, but other companies are.)   Of course, other times they do care about speed but they may not know how to quantify the requirement.  That's how it was at the bank where I worked.


Another way to approach this is to ask why we have response time requirements in the first place.  Sometimes there are quantified reasons for response times, i.e. the software doesn't solve the problem unless it performs actions fast enough.  For most software, there isn't a solid number like that.  Instead, the response time is a guess at what it takes to keep the user satisfied.  


If the requirements don't specify a response time, you might try some user testing.  With user testing, you ask individuals -- not professional QA people, but individuals who might actually use the product -- to use the application, and you gather their feedback.  You may have specific use cases that you want them to attempt, or you  might just sit them down in front of the app and watch what happens.  If the app feels slow, they'll probably let you know.  If they don't, it's probably fast enough.


Thats what i am telling, that in the requirement if response time is not specified but system is responding after 10 min then there is no use. So at least we have to check once & report that issue as "System is very slow".
Agreed; surely there are response times that are so long that everyone would agree there is a problem, and a test person should report problems like that.
The items listed in Out-scope in test Plan is something which is not testable.


TTWT Magazine





© 2021   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service