The first important factor affecting the quality is structure. The more ordered is a project, the better is its final quality. It is not about formalizing procedures, decision-making processes or introducing any other kind of production inhibitors. Quality should be presented as a value to which everyone aspires.

Requirements gathered properly at the beginning of a project, specific tasks listed for programmers, time planned for testing and determining verification methods after each of the stages. These basic steps should be involved in the quality assurance process used by implementation companies. Quality should not be the result of random events but repetitive tasks.

Another factor affecting the quality of a project is the level of responsibility and commitment of a team. Software is created by people, not by procedures, and its final shape depends on them.


Sometimes the simplest solutions are the best.

One of the few documents, which in various forms accompany the project from the very beginning, is a list containing simple queries/steps understandable for each team member. Checklists are used e.g. in aviation, filling them is part of the take-off procedure.

Checklists may cover different aspects of a created product:

1. Aspects related to code writing:

  • Are comments created?
  • Is the code in the repository of a version control system?

2. Aspects related to tests:

  • Were performance tests conducted?
  • Were functional tests conducted?

3. Aspects related to usability:

  • Were tests with users conducted?
  • Was the project finally tested by an interaction designer?

Checklists shouldn’t scare their readers away. They should be very concise and accurately define further steps. Questions should be phrased in a way enabling a binary answer – 0 or 1, yes or no. Responses such as “maybe”, “in a sense,” “rather yes” should not be acceptable.

Checklists are constantly updated and developed by employees, whose involvement improves identification with written rules and applying them in practice. They may take the form of documents created online, e.g. in Google Docs. It is important that they are accessible to a whole team.

Why do we use checklists so eagerly?

They’re quick!

Writing an implementation checklist for a mid-size system takes relatively little time (compared to e.g. test scenarios and use cases).

They’re easy!

As it was said before, checklists are written in a way that each team member can understand and edit them without any problems.

They make it possible to assess the project’s degree of completion!

Answering all questions from a checklist helps to create an image of a project’s condition. It becomes evident which elements are already finished and which require improvement.

They’re reusable!

Even systems written in different technologies have some elements in common. For instance, in online stores it’s the process of adding a product to the cart.

They “remember” about seemingly trifling things!

In every project there are things/functions that are left for the end. With large deployments we tend to forget about them, and the effects can have a very bad impact on the overall perception of the software.

How can a checklist look like?

Website design – General


Test scenarios

Functional test scenarios are an essential tool to verify whether software is working properly and according to a design. They describe what should be the system response to certain actions performed by a user. Scenarios describe functional paths that users can go through using an application.

As a result, tests based on scenarios can be performed by team members who are not programmers. This gives additional possibilities to check whether the implementing team has interpreted functional requirements correctly. This is especially useful when initial documentation is deficient or a project is inaccurate.

Test scenarios resemble written scenarios of cases of using an application, thus they can be formed at the analytical stage (before deployment), complementing documentation. They might as well be created at the end of deployment, on the basis of an already functioning version of a system.

Why do we use test scenarios in Divante?

Because use cases are not enough.

Use cases are an outline of the course of operation in a given function. They often describe only one main path. Test scenarios extend these cases to all or almost all possible paths ending successfully or with a (deliberate) error.

Because they’re written in natural language.

Subsequent steps are formulated in such a way that even a non-technical person, unfamiliar with the project, can reproduce them without problems.

Because they’re easy to read.

Test scenarios have a pre-requisite structure. By reading such “manual” we know exactly what we need to start the test (the initial assumptions, required data, tools), what should get/see after the test (e.g. a message about validation  or an invalid address, a new e-mail in the mailbox) and what needs to be done. Written down step by step.

Because they are educational.

Our client, a software recipient, learns the usage of a website by going through test scenarios. Such “leading by the hand” is often more effective than reading a manual or technical documentation.

How can a scenario look like?

Scenarios resemble use cases in their form. If the latter were created on the analytical stage, use them as the basis for creating test scenarios. You can create them in a traditional way in a text editor or a spreadsheet.

TCBXX – Example

Quality 2

However, such documents are difficult to edit and maintain – adapt to changes in the system.

A better solution is to use a simple tool – TestLink. It allows for simultaneous operation of the whole team on one set of scenarios.

Each scenario consists of the following elements:

  • Test Objective – Describes what function will be tested in this scenario. Most often it’s two-three sentences.
  • Initial Values — this area describes how to start a test scenario and what is required to complete the test. In the example above these are errors connected with customer status (not logged in, unregistered) and the customer’s location on the page.
  • Scenario (test steps) — It is the most important element of the test scenario description. The steps are divided into user actions and system responses. The scenario resembles a screenplay which covers all the user’s “lines” and system response. The description in the form of a dialogue transparently presents tester’s interactions with the system. Test failure can be quickly found in case of inadequate system response or the inability of performing further action by a user
  • Result— this area is left blank to be filled during testing by a responsible person.

Want to know more? Write to us.