Friday, August 8, 2008

Rights of an End-User.

More great information on the rights of an End-User. Taken from the source and not modified.


When considering product usability issues, testers should take the stance that these issues are not merely "Requests For Enhancement", but are violations of the end-users inalienable rights to workable and usable software. With that in mind, I've started a list of the "Bill of Rights" for End-Users, which are those things that I see, which testers should have in the forefront of their minds when performing usability testing.

These rights are not features, they are not version 2.0 enhancements, they are the inalienable and intrinsic to every user of our software.
  • The end user has a right to change their mind.
    * Anything that can be installed must be able to be easily and completely (cleanly) uninstalled restoring the system to it's previous state without damage to other dependent software.
    * Users have the right to use the installer program to not only install and uninstall the program, but also to reinstall and repair.
    * Anything that can be configured can be unconfigured...
    * Anything added can be removed...

  • Users have a right to simplicity. They should not have to know about inter-library dependencies and the like. The install should take care of all of these things auto-magically behind the scenes for the user, or when that is not possible it should explain clearly to the user in simple terms, what is needed and how the user can go about getting it.

  • Users have a right to quiet control. Do not pop up windows in front of a user and take the focus. Users have other things in their world besides your crappy application; they don't want to be interrupted every time your application wants attention. Do not ever capture and mess with control keys .
  • Users have a right to non-interference. Never, ever, mess with the value in the clipboard (Firefox). The clipboard is in the users space and belongs to the user, even though you have the means, you do not have the right to copy anything into the clipboard unless explicitly instructed by the user.

  • Users have a right to privacy and peace of mind. Never scan the file system, never place anything in the filesystem or registry that a user may not be comfortable being accessed by others. Do not send ANY user data out to the network without notifying and gaining approval from the user.

  • Users have the right to customize their view and environment. To change display settings, language preferences, ... Users have the right to run in 600x800 resolution and still navigate the page.

  • Users have the right to use computers even if the users are differently-abled (various degrees of sight-impairment and colorblindness, hearing, one-handedness) (Section 508).

  • Non-native English speaking users have the right to still use our software (I18N).

  • Users have a right to the most simple and intuitive interface possible. Everyone should have the ability to be a power user in the application. Shortcut keys should be available and intuitive for common tasks. A user should be able to get to an area of the program in the least number of clicks and keystrokes possible; remove unnecessary transitional navigation pages.

  • Users have a right to know what version they're running. Product name and exact version number need to be displayed in file names and in the install, before the installation process begins. It is unacceptable to display the version sometime after the install process has begun, or even worse, only after it has completed.

  • Users have a right to graceful failures. Crashing the application or losing user data is unacceptable at any time under any condition short of OS intervention or powerfailure. Displaying ugly, unduly alarming, or unintuitive error messages are also unacceptable. The error messages need to avoid being unduly complicated, but they also must be honest about the cause of the problem. Sugar-coating a serious problem or treating an error condition as a mere warning does not help anyone.

  • Users have the right to notification of service unavailability. An install should never restart any service without first asking the user.

  • Intuitive interface. The onscreen text should explain exactly what is expected from the user. Users should never have to guess or go to some other documentation in order to configure or use. If additional information is needed, it should be redily available (links on the UI or in an obvious Help file).

  • Identity Modifications. Users have the right to change names and passwords and everything should still work. Users have the right to make changes to other personal information (address, weight, spouse, etc.) and still maintain their identity and everything works.

  • Instructions and Product Use Information. Documentation must be easy to find (all modern software products have a readme file at the root which contains vital information and links to all other needed info). It must contain instructions on the installation, configuration, administration, and use of the product. All documentation must be accurate and complete.



Great advise and a relevant take on software QA testing.

I have to say that I agree with the following information. This is taken directly from the source and has not been modified.


* Expose all issues. As a tester, you must report all software problems that you encounter. The ones in your own product take first priority, but defects found in other products along the way should not go unreported. A Tester has the moral obligation to make all problems visible to the appropriate people. It doesn't matter if the bug is in someone else's product. The user will see the issue in your product and they will blame you if they don't know what to do. At the very least, you should document issues like this in the Readme or Troubleshooting docs and provide warnings or workarounds.

* Every minute wasted is a bug lost. Good Testers are constantly active constantly looking at the product and constantly looking for ways to save time. There is never enough time to test the product completely and so every minute wasted is another bug that you're letting slip by. Cannot afford to take the stance of being "Perfectly Content to do absolutely nothing until someone tells me twice." Never stop searching.

* Every minute of someone else's time that is wasted is 2 lost bugs. The bug that you could have been finding and the bug that the other person could have been finding. DO NOT WASTE OTHER PEOPLES TIME. If you have a question, Google it, read the doc, stop and think about your question. There are not very many questions in this Universe whose answers exist only in the mind of one person. Dropping in on a developer or another tester who is busy working should be your last resort.

* Regressing defects. Testing that a defect is fixed, that the issue no longer happens, is only the beginning of regressing a defect. The most valuable part is also the hardest part, it comes in testing around the fixed area to verify that nothing else was broken. Knowing what is "around the fixed area", guessing what could have been affected by a fix (or not affected when it should have been), attaining a knowledge of the architecture of the product.

* Defects must be fixable. There is no point in entering a report for a defect that cannot be fixed. An issue cannot be fixed if it cannot be duplicated and there are not sufficient trace information to determine the cause. There cannot be a fix if the subject of a defect is not an identifiable, quantifiable issue and if a case cannot be made that the issue will cause damage or inconvenience to a user. Writing observations without qualifying them as Defects is an unacceptable waste of other peoples time. Part of writing fixable defects is to investigate the issue so that you can provide enough information to determine (1) Where the problem is happening (at a minimum, who's component it is happening in, i.e. who should be responsible for fixing) and (2) How to reproduce the problem consistently. When the resulting damage or inconvenience of a defect is not obvious, you may need to make a case for why it really is a defect and why it must be fixed.

* Developer helpers. Our job has nothing to do with helping the developers to do things that they are able to do but would rather not do. We are not machine jockeys. We are not customer support. Our #1 priority is the quality of the product that we have been assigned. Anything else is a distraction and should be avoided. Our job is to examine all aspects of a product to evaluate the products quality and it's fitness to meet the expectations of end users. Playing the part of developer-helper, or unit-test-automater should be reserved for Developer Interns. It wastes of the time of a QA Engineer and ultimately stunts the quality of the product. Occasionally we will help other groups when they're under the gun, because we're geared for it. However, we can not afford to let those groups believe that helping them is our only calling in life. The most useless waste of a Quality Assurance persons time is engaging in a task that a developer could do themselves. Sometimes for the overall good we must allow ourselves to be distracted from testing, but don't let distractions run your day. We are not Developer Helpers or lackys.

* Study voraciously. Google is your best friend. Always search for an answer to a question before asking it. Always research the technology of the product that you will be testing. In many ways the tester has a responsibility to know, even more intimately than the developer, the architecture of the product, it's environment, and the technologies that it is built upon and that it interacts with.

* Functional testing is only the first step.
In order to be truly useful in this job, a tester must get beyond functionality testing. Functionality testing is preliminary to any other testing. If the product doesn't do what it's supposed to do, then any other issues are not terribly relevant. Developers could and should be doing functionality testing themselves in the form of Unit tests and other pre-check-in checks. If this is not being done, then that issue in the software development process of the team must be tackled before testing can archive full productivity. Where a tester adds value to the process is when he is able to go beyond those things that should be readily apparent to developers and casual users.

* Credibility is everything. There is no room for lies in this profession. Conjecture about something you don't really understand is the same as lying. Agreeing with something that someone else says that you don't know to be true, is the same as lying. Since our primary objective is to show the true state of the product, if what we say is not trusted by others then, even when we have done the work and the information is right, we have failed the primary objective. "Honra y dinero se ganan despacio y se pierden ligero" ~ "Reputation and money are earned slowly and lost quickly".

* Be a Devil for Details. Writing a bug report that just says "IT DON'T WORK", is NOT good enough. You must investigate the problem enough to provide the "Why it doesn't work", or the "When it doesn't work".

* If you're not part of the solution... Good testers don't just point out problems, they also suggest solutions. Examining the problem to the level that you can suggest solutions helps to verify that you understand the problem.

* Stand for quality. The #1 job of QA is to hold software development to a high standard of quality. This entails both the product and the process, in order to enforce both, you need to strive to have a maven understanding of both.