Benefits of usability testing

Why is there such a lot of focus on doing proper usability testing ? Whenever there is any discussion of doing a product and plans are drawn, doing usability testing is deemed as a critical part of the overall plan. What are the benefits of doing usability testing and what can you learn about your product from this process ? Presented below is a list of queries / outcomes / benefits, many of which may seem relevant and others not so relevant:

Are the test participants able to complete the task scenarios successfully? Do the test participants understand the various test scenarios ? If they are not able to understand or frequently ask for directions or seem confused, it implies that there are problems that need to be addressed.

Do participants perform well enough to meet the usability objectives? Supposing the participants are able to move ahead in the flow, the next question is about their performance in the study. Their level of completion, the amount of assistance they required, whether they moved in the workflow the same way that the designers intended, all these are queries that need to be assessed.

How satisfied are participants with the site or application? It is very important to gauge the level of satisfaction of the users with the site / application. Preparing a series of questions during and after the study will allow determination of the satisfaction levels of the users with the overall site / application, as well as individual elements.

What changes are needed to make sure that the site / application will enable more users to perform more successfully? A usability study is an excellent time to find out which is the more user-friendly route for users. In fact, it is very much possible that during the course of a usability study, designs could be reworked in an iterative way to find the one that seems to be the most user-friendly.

Verification of user analysis data: Designs in a lot of cases have been made on the basis of previous user analysis data. Typically, such analysis leads to a lot of data about the workflows that users seem to prefer; however, it is also known that in many cases, users state something based on questions - but these can get modified when they actually see this in operation (also known as 'users finally get to know what they want when they see it'). Hence, usability studies are a good way of finally verifying the user analysis data.

Validate design guidelines: The usability testing also helps to confirm the various design guidelines that have been established for the project. These guidelines serve to set the basis of the user workflows. An example of some of these are:
* Make links predictable: Links should have the same type of UI and should work in the same way
* Make screens as simple as possible -- first screen should have only the most frequently used functions and secondary screens should have optional interactions
* Use graphics minimally -- only when necessary, and make graphics meaningful, to indicate where a link goes or what page it deals with; and
* Make the page easy to scan -- most people scan the page, picking out individual words or sentences and do not read word-by-word
Now these are general guidelines and may not be applicable for all cases.

Testing allows designers to settle disagreements and differences: Different designers in a team could have multiple opinions and getting usability tests determines which is the one most likely to work. This happens without hurting egos if decisions are made on the basis of user study.

Usability tests can help you understand how real users will use your product, and how the interface could be improved accordingly: Teams developing the product / site can have blinkered visions; getting target segment users brings you close to reality.

Results of testing give the designer ammunition to use in responding to outside attempts to change design based on whims or personal bias: Higher management or experts can have their own opinions and may want a workflow to happen in a certain way, and getting usability results helps defeat such attempts if they are based on personal whims.

Testing saves time and money. Rubin notes that "doing usability testing through the development project allows you to make user-centered changes as you go, before you have so much time and money invested in the project that it makes it difficult to make changes.

Testing is good public relations: It sends a message that the team/company is interested in what the user thinks and needs and can be used very easily for good coverage and to show that the company has done a best effort.

Testing allows the designer to cast a broad net: It helps ensure that the design is good for all users, not just those users who think like you do. Getting a cross section that is diverse is much easier if you are doing a bigger usability study.

In summary, the process can work like this - With the iterative approach, a site prototype can be created, viewed, and evaluated by a small subset of users who identify problems and suggest changes. Once immediate problems are corrected and suggestions are implemented, the site is released to a larger audience, who become part of the design and quality control team by using and evaluating the resources and sharing their feedback with the developers. Usability testing methods, by their very nature, keep the user in the forefront. User testing helped us, the designers, distance ourselves from the product. Rather than focusing on what we thought/liked/needed, we could focus on what the user thinks/likes/needs. What users say they need and want is often substantially disconnected from what they actually need and want when faced with using a product to perform a task. It is for these reasons that the only way to effectively determine what is best for users is to observe users performing tasks with the product of interest.

Extreme Programming Resources

Extreme Programming is a topic that has a fair amount of resources available where you can read up about it, learn from experiences of people, and also get access to resources for working with XP. Here is a listing for some resources that will help when trying to learn about Extreme Programming.

1. TechRepublic

2. Extremeprogramming.org

3. Version One Resource Page

4. CodeBetter.com

5. XP Yahoo group

6. XP123.com

7. IndustrialLogic.com

8. Extreme Programming Roadmap

9. IBM

10. ComputerWorld.com

11. XProgramming.com

Characteristics Of Embedded Systems

Embedded computing systems generally exhibit rich functionality—complex functionality is usually the reason for introducing CPUs into the design. However, they also exhibit many non-functional requirements that make the task especially challenging:

• Real-time deadlines that will cause system failure if not met;
• Multi-rate operation
• In many cases, low power consumption
• Low manufacturing cost, which often means limited code size.
• Must be efficient
• Energy efficient
• Code-size efficient (especially for systems on a chip)
• Run-time efficient
• Weight efficient
• Cost efficient
• Dedicated towards a certain application
Knowledge about behavior at design time can be used to minimize resources and to maximize robustness
• Dedicated user interface (no mouse, keyboard and screen)
• Hybrid systems (analog + digital parts).

What is an embedded system ?

An embedded system is some combination of computer hardware and software, either fixed in capability or programmable, that is specifically designed for a particular kind of application device. Industrial machines, automobiles, medical equipment, cameras, household appliances, airplanes, vending machines, and toys as well as the more obvious cellular phone and PDA are among the myriad possible hosts of an embedded system. Embedded systems that are programmable are provided with a programming interface.

Another definition: Any electronic system that uses a CPU chip, but that is not a general-purpose workstation, desktop or laptop computer. Such systems generally use microprocessors, or they may use custom-designed chips or both. In embedded systems, the software typically resides in firmware, such as a flash memory or ROM chip, in contrast to a general-purpose computer that loads its programs into RAM each time. Sometimes, single board and rack mounted general-purpose computers are called "embedded computers" if used to control a single printer, drill press or other such device.

A third definition: Hardware and software which forms a component of some larger system and which is expected to function without human intervention. A typical embedded system consists of a single-board {microcomputer} with software in {ROM}, which starts running some special purpose {application program} as soon as it is turned on and will not stop until it is turned off (if ever). An embedded system may include some kind of {operating system} but often it will be simple enough to be written as a single program. It will not usually have any of the normal {peripheral}s such as a keyboard, monitor, serial connections, mass storage, etc. or any kind of user interface software unless these are required by the overall system of which it is a part.

What is the Rational Unified Process (RUP) ?

To simplify and make the strategy of iterative software development, the rational software corporation came up with an iterative software development process framework, now popularly known as the rational unified process or RUP. The rational software corporation has been a division of IBM since 2003. RUP has been developed as a process framework that is adaptable rather than being a rigid perspective process. One of the advantages of this process is that development organizations have the freedom to tailor it for their needs. The required elements of the process can be selected by the software projects teams as they think is appropriate. 

The product comes with many sample artifacts and a number of detailed descriptions for a number of activities that are supported by the RUP. It has been included as a part of the IBM’s RMC (rational method composer) allowing the easy customization of the software development process. The RUP lays down six best practices which evolved by the combination of the experience of various companies. These six best practices are:

Ø  Iterative development driven by risk. Risk is the primary iteration driver.

Ø  Management of requirements

Ø  Employment of component based architecture

Ø  Visually modeling the software.

Ø  Verifying the quality of the product continuously.

Ø  Controlling the changes

All these practices are employed by rational corporation for the development of their products. They are even used by its members for helping the customers in making improvements to the predictability and the quality of the development efforts. The RUP can be tailored for guiding the software development. It comes with all the tools that are used for automating the application of the RUP. It also offers services for accelerating the process’ and its tools’ adoption. All these three things form a strategic tripod for the implementation of RUP. The foundation of the process is based up on certain building blocks and elements which describe the thing that has to be produced and how it is to be produced and what are the requirements. Following are the three main building blocks:

Ø  Roles: This defines the skills required and who should take what responsibilities and has which competencies.

Ø  Work products: This represents the result of an activity. The result includes all the models and the documents produced during the process.

Ø  Tasks: The work assigned to the roles is described by this element. The work should be such that it should provide a meaningful result.

Many iterations might be carried out. In each iteration the tasks are divided in to a total of 9 categories:

Ø  Six disciplines of engineering:

-          Business modeling

-          Analysis and design

-          Requirements

-          Test

-          Implementation

-          deployment

Ø  Rest are supporting disciplines:

-          environment

-          configuration and change management

-          project management

There is also a tool that you can use for configuring, authoring and viewing the processes. Processes can even be published. Certification for RUP i.e., the IBM certified solution designer – rational unified process 7.0 was released in the year of 2007. The earlier version was the IBM rational certified specialist – rational unified process. The new version of the exam focuses on both the RUP content and the process structure elements. For passing this certification examination, the test you have to take is the test 839: rational unified process v7.0 in which you are given 52 questions to be done in 75 minutes.

Factors in making a project successful - some quick factors

Unpredictable, late, over budget projects are not something very uncommon. In some cases the project even fails before it delivers even one program. In this article we discuss about some success factors that are crucial for a successful project. Even though we have gone through 4 programming languages generations, 3 development paradigms, we are still not capable of transforming our ideas in to successful software. The number of software project failures has risen rapidly since recent years. No magic goes in to successful management of software development. But there are some factors that make it better:  Complexity management: There are several characteristics of software that make the management of the development process very complicated and thus difficult. First, the systems that are based up on software are quite complex. Secondly computing itself is a complex thing. The problem of mastering it is the basic problem. The software developers have to work out such complex problems and so no doubt they are very intelligent people and complex individuals in themselves. This complicates their management also. On top of that if the developers are trying to target user requirements, all the management issues mix up. One study has shown an improvement in the completion rate of the software if the complexity is lower. Companies are now adopting the projects that are small and thus easy to manage rather than taking up large projects, or breaking up larger ones into smaller pieces.  Starting on the right side: It is difficult to develop successful software when the development efforts are not proper just like you cannot grow strong plants in soil that is weak. Below we list some failure symptoms out which some are predetermined before the development starts: - A lack of understanding of the users’ needs. - Poorly defined scope of the project. - Changes in the technology chosen for development. - Changes in the business needs. - Setting unrealistic deadlines. - Resistant users - Lack of sponsorship. - Lack of appropriate skills - Ignorance towards best practices. For avoiding this we should have objectives that can be really achieved and the expectations that can really come true. Your team should consist of people with proper skills required for the job. Adequate resources must be given to the team to meet their requirements.  Momentum maintenance: Now that you have a strong team, a good working environment, good resources etc. you can gain the momentum. Next you need to keep increasing this momentum. Having a high momentum is quite easy but taking it further from here is very difficult. It keeps changing with the course of development. Your focus should be keeping the attrition low, monitoring quality early and managing the product more.  Progress tracking: The nature of the software is intangible i.e., it cannot be physically touched or measured. If you don’t know what mistakes you are making while doing the project, it is quite possible that you’ll keep repeating them.  Smart decision making: Difference between the project failures and successful projects comes from making smart decisions. It is often not difficult to analyze whether a decision is good or bad before you implement it. Bad decisions are often made while selecting what technologies are to be used. It may happen that you might not be able to finish your project and the platform your project supports goes away. Before picking up a technology, its analysis must be done and you should if there is a market for it.  Post – mortem analysis: Successful companies analyze the project to learn from their mistakes. If this not done, the same mistakes will be repeated again and again.

Some definitions of regression testing and what it means ..

What is regression testing?

Regression is a type of software testing that is used for discovering new errors and bugs in the software system. In terminology of regression testing these bugs are called regressions. Regression testing is carried out for the already existing areas of the system whether functional or non – functional. This testing is carried out after any change has been made in the configurations or patches. The basic purpose of regression testing is ensuring that any change or modification made to the software does not affect its functionality or introduce some other new errors. It also checks whether a change in one part of the system had any effect on the other parts of the system. Some common methods of carrying out regressing testing are:

- Re – executing the tests that have already been executed.
- Checking if any change has occurred in the working of the software.
- Checking if the errors corrected earlier have appeared.

Regression testing as such is very time consuming since you have to test everything again and again, but can be performed effectively by selecting a certain number of tests. The number of tests selected is sufficient enough to cover the whole unit in which the change is made. According to a research, it has been found that making a change in one part of the software often introduces errors in other parts. In some of the cases the same errors reoccur because the fix that was made earlier to prevent them gets lost. This happens probably because of errors humans make while revising the code i.e., because of the poor revision practices. Often the fix that we apply for a problem is fragile that it is easily breakable and can get lost. Or sometimes this fix for one part of the software can cause an error in another part.
In some other cases it might happen that during redesigning, the same mistakes might be made that were made during the designing of the original software. Therefore mostly regression testing is considered to be a good practice. It helps in locating and fixing the bug, recording the tests which led to the discovery of the bugs, repeated execution of the tests at regular intervals after some modification has been done in the program. You might be thinking that this can be done even by following the manual testing procedure by means of some programming techniques. But this is better carried out with automated testing as it takes less effort and time when compared to the manual testing.
An automated testing suite consists of various software tools that allow for the automatic execution of the test cases and generate reports. The programmers might set up such automated testing systems for automatically doing regression testing at regular intervals of time. This way the regression tests can be run either after every compilation, once a week or even every night. There are various tools available for automated regression testing such as follows:
- TinderBox
- BuildBot
- Hudson
- Jenkins
- Bamboo
- TeamCity

Regression testing is closely associated with extreme programming as the former is an inseparable part of the latter. Here at each phase of the software development cycle, the entire software package is put through repeatable, extensive automated testing. The software quality assurance team is responsible for performing the regression testing after the development is over. But fixing the bugs at this stage comes very expensive. This potential problem is fixed at an earlier stage by means of unit testing. The test cases written by the programmers are for the verification of the intended outcomes i.e., they are either unit tests or functional tests.