What is Usability Testing

What is Usability Testing - Part 1

Usability testing is a technique for ensuring that the intended users of a system can carry out the intended tasks efficiently, effectively and satisfactorily. In other words, Usability testing should be an iterative practice, completed several times during the design and development life-cycle. The end result is an improved product and a better understanding of the users that we’re designing it for.

Main steps in the usability testing process are Planning, Gathering Data and Reporting results.

There are two scenarios for usability testing:

1. If you are a software product vendor, testing real users of your product means you are evaluating for design. Based on how you have designed the application, can users complete the tasks they need to do? Testing real users doing real tasks can also point out if the UI guidelines you are following are working within the context of your product, and when consistency helps or hinders the users’ ability to do their work.

2. If you are a software product purchaser, you can do usability testing to evaluate a product for purchase. For example, your company might consider buying a product for their twenty thousand employees. Before the company spends its money, it wants to make sure that the product in question will really help employees do their jobs better. Usability testing can also be useful to see if the proposed application follows published UI style guidelines (internal or external). It’s best to use UI guidelines as an auxiliary, rather than primary, source of information for making purchase decisions.

This Guide is discussing on the first scenario ‘evaluating for design’.

When Usability Testing is appropriate?

Usability testing is carried out pre-release so that any significant issues identified can be addressed. It can be carried out at various stages of the design process as well. In the early stages, however, techniques such as walkthroughs are often more appropriate.

Article is prepared by:

Anushka Wickramaratne

Senior QA Engineer

What is a Test Case

In simple terms, test cases are how the testers validate that software meets customer requirements. It’s a tool which helps testers to test a product.

Test case is a set of conditions organized in a manner which determines a requirement is met in the product by testers. Then testers can decide whether the test is passed or failed based on the output of the test case. If the output is passed the conclusion is that the tested requirement is functioning correctly. If test case failed then that requirement needs a code change to fix the issue. When a test case is failed, testers called it as bug/issue* of the system.

The main inputs for test cases are requirements of the system. This can in format of a requirement document which represents using deferent techniques such as use cases. Then it’s testers’ responsibility to design test cases to cover all requirements. There are tests to cover the positive test and the negative test for a requirement as the minimum.

There are several information required for a complete test case and those are,

Test case ID – to identify a test case, it should have a unique number.

Test case description – This includes the description of the feature or the requirement that’s going to test by this test case.

Steps – steps should be included to guide the tester to execute the desired test case

Input data – If the test case requires the specific data, those can be included here. When designing the test case, it’s acceptable to include the test data among the steps.

Reference – this will link the test case to the requirement which has documented in requirement document.

Expected result – this the expected output of the test case and how the feature/requirement should function in the product.

Testing status– this will contain information whether the test case is passed or failed after execution of the test.

Author – This will contain information who has designed the test cases.

Date – this will hold the information when the test cases are designed.

Change history- this will give an idea what has been changing in the test cases after creation of it.

Author, Date and change history can be single entry for a set of test cases.

*Bug/Issue will be discussed in detail in another post.

Vocabulary...

Followings are some of the words that will be useful for the next topic.

Risk is the potential loss to an organization, as for example, the risk resulting from the misuse of its computer. This may involve unauthorized disclosure, unauthorized modification, and/or loss of information resources, as well as the authorized but incorrect use of a computer. Risk can be measured by performing risk analysis.

Risk Analysis is an analysis of an organization’s information resources, its existing controls, and its remaining organization and computer system vulnerabilities. It combines the loss potential for each resource or combination of resources with an estimated rate of occurrence to establish a potential level of damage in dollars or other assets.

A Threat is something capable of exploiting vulnerability in the security of a computer system or application. Threats include both hazards and events that can trigger flaws.

Vulnerability is a design, implementation, or operations flaw that may be exploited by a threat; the flaw causes the computer system or application to operate in a fashion different from its published specifications and to result in destruction or misuse of equipment or data.

Control is anything that tends to cause the reduction of risk. Control can accomplish this by reducing harmful effects or by reducing the frequency of occurrence.

Reference: CSTE CBOk v 6.2

Clear doubts about QC vs QA

Quality Assurance Versus Quality Control

What you guess? it does mean same? any guess?

The following statements help differentiate quality control from quality assurance:

• Quality control relates to a specific product or service.

• Quality control verifies whether specific attribute(s) are in, or are not in, a specific product or service.

• Quality control identifies defects for the primary purpose of correcting defects.

• Quality control is the responsibility of the team/worker.

• Quality control is concerned with a specific product.

• Quality assurance helps establish processes.

• Quality assurance sets up measurement programs to evaluate processes.

• Quality assurance identifies weaknesses in processes and improves them.

• Quality assurance is a management responsibility, frequently performed by a staff function.

• Quality assurance is concerned with all of the products that will ever be produced by a process.

• Quality assurance is sometimes called quality control over quality control because it evaluates whether quality control is working.

• Quality assurance personnel should never perform quality control unless it is to validate quality control.

Reference: CSTE CBOK v6.2

My idea of this.............

My idea of this blog is to publish the knowledge of QA that I gathered thorough my leanings and experience to anyone who is interested. Further I’m planning to add articles of new concepts in Quality Assurance/Quality Control.

Vocabulary in Software Testing

What is Quality

A product is a quality product if it is defect free. To the producer, a product is a quality product if it meets or conforms to the statement of requirements that defines the product. This statement is usually shortened to: quality means meets requirements. From a customer’s perspective, quality means “fit for use.”


What is Quality Assurance (QA)

The set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved to produce products that meet specifications and are fit for use.


What is Quality Control (QC)

The process by which product quality is compared with applicable standards, and the action taken when nonconformance is detected. Its focus is defect detection and removal. This is a line function; that is, the performance of these tasks is the responsibility of the people working within the process.


Reference: CSTE CBOK v6.2