« Want vs.Need | Main| How I Escape the Techie World »

Application Testing


One of the first things I did when I arrived at Teamstudio more than 3 years ago was to look at our product portfolio to determine where there might be new product opportunities. Testing was one area that jumped out at me. It seemed to me that Lotus Notes did not offer much in the way of testing tools, which made this seem like a nice opportunity for Teamstudio. Furthermore, very little is available from anyone in the Lotus Notes space specifically targeting testing.

Before I had a chance to pursue new product opportunities, I was asked to lead a project to develop a series of best practices across the application development life cycle specifically targeted at Lotus Notes. This took several months to complete, but we got a great set of policy guides and implementation guides out of the effort as well as a book on IT Governance for Lotus Notes.

The policy guides proved to be quite popular among Lotus Notes Developers and Administrators. I had a great number of conversations with those who downloaded the policy guides about how they were performing various tasks, especially around testing. I heard everything from “we don’t do testing” to “we develop in production … that’s what the users are for”.

I quickly learned that the popularity of the policy guides did not necessarily translate to a good product opportunity. Testing within the Lotus Notes community seems to be at best, an informal phase in the development life cycle. I know a lot of Lotus Notes Administrators and a lot more Lotus Notes Developers. But I am yet to meet anyone with the title of Lotus Notes Tester.

Regardless of the formality of the processes used, one area of testing that is done regularly is that of User Acceptance Testing. Even when development is done in the production environment (OUCH!), the users usually get a crack at running through the application before it is “officially” released to the masses.

Depending on the size and scope of the release, different aspects of the system should be tested. For example, a limited release may only require testing of new functionality while a new system will require complete testing.

Remember, the purpose of user acceptance testing is more than getting one of your users to say “looks good to me”. Instead, you should be working to ensure that the application is compliant with business rules, meets the users’ expectations and performs as expected in the actual business environment.

User acceptance testing should include various aspects of the system including:
- Functionality:  Application perform the business functions as specified
- Completeness:  All necessary information to perform a business process or user transaction is present
- Accuracy:  Correct content from the user’s point of view
- Usable Results:  Information returned after an operation, reports generated, etc., including layout and content are in a usable format for the user
- Documented:  Accuracy, usefulness and usability of user documentation and procedures should be provided to the user
- Procedures:  Release, installation and configuration management process should be in place to support the application

This is an area that is subject to scope creep. Be careful! Sometimes there is a fine line between “what the system must do” and “what would be nice to do”. When in doubt, you can always go back to the requirements documents. At least I hope you can.

But documenting requirements is a subject for another day.

Category

Comments

1 - You left out one very important area which is often overlooked in testing:
Usability Testing (from the user's perspective). You mention the layout of any results that might be returned, but the actual interface presented to the user is critical as well. It needs to be tested for intuitive usability. Does the user immediately have a comprehension of what they're looking at, and do they seem to instinctively know how to use it? Does it use language they expect? Does it provide functions necessary to doing their jobs in a way that feels familiar?
The answers to these questions will determine not only whether a user can use the system correctly or easily, but whether they are inclined to use it at all. It may also determine what they say to others about the system.

Post A Comment

Feeds

Custom Button Custom Button

Category Cloud

Disclaimer

The views expressed by the authors on this blog do not necessarily reflect the views of Teamstudio, those who link to this blog, or even the author’s mother, father, sister, brother, uncle, aunt, grandparents, cousins, step relations, any other blood relative - and sometimes not even the author himself or herself.

Comments on this website are the sole responsibility of their writers and it is assumed those writers will take full responsibility, liability, and blame for any libel or litigation that results from something written in, or as a direct result of something written in, a comment. The accuracy, completeness, veracity, honesty, exactitude, factuality and politeness of comments are not guaranteed. Oh, how they are SO not guaranteed.
en-us,en;q=0.5OFFCCBot/1.0 (+http://www.commoncrawl.org/bot.html)38.107.191.88getthemostfromnotes.comHTTP/1.180Lotus-Domino/tsblog.nsf/d6plinks/KFRA-87AP5V