One of the most important elements of software (whether desktop or web-based applications) is quality assurance. When we (at DSS) sell a product to a customer, they obviously expect a high degree of quality and usability. Not just for their employees, but also for their citizens. Our products will be used by the public citizens of that state and in a sense our products provide a foundation by which citizens will judge the overall quality and integrity of the state and the services it provides. This is why the quality assurance of our web-based sofware is so important to our customers: they don't want to betray citizen trust (and to avoid looking like idiots).

The sole focus of quality assurance should NOT be from the programmer or developer perspective (as it was early in my programming career). Q&A is so much more than just making sure the programmer thinks the system works correctly. It is ensuring that additions or modifications to software:

1. Can be easily used by those who do not fully understand the software
2. Performs the expected operations as planned
3. Is efficient
4. Is simple
5. Is security enabled
6. Is future-oriented

I'll briefly explain each of the items:

1) Can be easily used by those who do not fully understand the software

Because programmers and users are so disparate in their usability logic, a pre-defined "link" must be created for programmers to the user. Some teams create this link by hiring a usability expert or interaction designer. This person is usually solely responsible for creating interfaces for consumers; thus, removing the need for a programmer to include interaction techniques in their development which could save significant time. Interaction designers can also train programmers to instill good interaction design techniques.

"If it was is easy for the engineer to build, it won't be easy for the user. If it is easy for the user, it was difficult for the engineer to build." - unknown

This quote perfectly portrays one of the major gaps between usability and software development. Programmers develop logically (that is, in a procedural way) whereas users scan quickly (which tends to be more emotional). These inherent differences always cause confusion for the user and difficulty for the programmer. Thus, when programmers perform the following non-exhaustive list of checks, users will have a much easier time adapting to the new application:

1. Design interfaces first, then build the backend.
   Building functional mockups of systems (or modules of systems) for user testing prior to full development will allow easier and faster modifications to the interface based on user testing results. Waiting until the system is fully coded to perform user testing is much more difficult to modify.
2. Perform user testing with multiple user groups.
   Some users are inherently more skilled at using programs than others. I usually try to get the less-skilled users earlier in user testing, to work out the obvious usability obstacles.

2) Performs the expected operations as planned

This is a no-brainer. If the application does not perform as specified in an evolving requirements document, what's the use? The application will not do what is expected and should not be built.

3) Is efficient

This is not meant efficiency in programming process (query optimization, efficient array processing, etc.) this is meant to explain efficienies in user interfaces and interface processes. For example, if a user needs to create a question to ask in a survey, have them finish the entire process in one screen. Clearly, adding the question text and adding possible responses (for a multi-choice question) should be done on the same screen. The old screen-refresh-at-submission designs are a thing of past (I admit that I have a lot of work to do). Technologies that assist with this are AJAX and Flex.

4) Is simple

A major application system is simply a lot of smaller components working together. Keeping those smaller components simple will always provide for a stable system.

5) Is security enabled

Don't plan security into the picture after user testing. Security is an ongoing problem and should be an ongoing concern. Programmers should be routinely and frequently trained in the latest security threats and hacks and those procedures should be implemented DURING DEVELOPMENT; not after it has happened. It is more difficult and more risky to implement security features after development than to implement them during it.

6) Is future-oriented

That's on odd one, eh? What I mean by "future-oriented" is that programs and applications (whether web-based or not) should evolve. There should be a continual re-evaluation of the application to asess enhancements, modifications and new features THAT MATTER. There is no need developing anything that really won't matter to users.

In summary, this is simply a short list of a much longer one that may assist with approaching software development properly.