Sunday May 11, 2008

Non-functional testing

Where are the bulk of your test efforts focused on ? Am sure most testing teams would be focused on testing a product's functionality or at least a majority of the time spent in testing could be involved in testing for the functional requirements; which is not a bad thing at all ! But, how much focus is given to testing the non-functional requirements, assuming there are a set of well defined non-functional requirements and the same has been suitably incorporated into the product and tests have been developed for verifying the same.

What are the common non-functional requirements and why do we need to even spend time talking of them let alone have specialized resources dedicated and assigned to test them ?  Put it simply, assuming a condition of cetirus paribus (all other things being equal and similar functional features in two competing products), non-functional requirements often play a significant role in differentiating between a product that is well received by customers vs one that may not do well in the market place. Some of the key non-functional requirements include Usability, Performance, Security, Interoperability & Compatibility.

As an end user, how many of us would be willing to use - a multi-user application that has tonnes of great functional features but simply crawls or frequently hangs up when several users try to use the system; an application that has sensitive data but is fairly easily susceptible to security breaches and exposure of sensitive information; a web application that works best only in a limited set of browser types and versions on limited platforms and unfortunately there are users using and comfortable on other verions of browsers and platforms or even a scenario where usability was not given much thought to and users feel frustrated trying to use the application's features on offer .... it is not difficult to envisage many such scenarios which can drive users and customers away  into the out-stretched arms of the competition and functionality is'nt the one aiding this move.

While common reasoning states that a product that does not meet its functional requirements is incomplete, do we do the same for the non-functional requirements too or do we agree to address non-functional requirements / issues found in an upcoming patch or subsequent release? However, this line of thinking exposes the chinks in the armor when the product is being deployed at the customer site or when it is moved to production. A product that is'nt suitably performance tested and does not meet well laid out performance criterion, could fail miserably in a production deployment. Similarly with other items such as security, usability or compatibility. It is'nt hard to visualize the impact each of these non-functional items can have in a real usage scenario.

Non-functional risks need to be evaluated and considered during project planning. During requirements phase, both functional and non-functional requirements need to be spelt out and considered by both development and testing teams. Also, meeting non-functional requirements does involve a certain degree of trade-offs and arriving at a suitable balance between focusing on non-functional requirements vs. other areas of the product is needed.

About

John Morrison

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today