Quality: Gov.uk Guide

Original author: Gov.uk
  • Transfer
What is meant by this word, how to evaluate quality and how to maintain it.

Quality should come first when working on a project if you want people to use your services and value them highly. Each member of your team is responsible for the quality - the work of the people who create the service determines its quality. Each employee who works on your project should contribute to the maximum increase in quality and the solution of emerging problems.

Quality definition

Different people in a team will understand quality differently. In general, quality is the level of user service, from the start of a transaction to its completion, which includes:

  • Providing access for (the widest possible range of) users to the optimal set of devices.
  • Sufficient ease of use of a device
  • The ability to provide technical and informational support to users as quickly as possible
  • Security and ease of storage and use of data
  • Efficiency and security of core software and IT infrastructure.
  • Full performance of the program code.
  • High speed of the service when interacting with a large number of users at the same time (load testing is necessary).
  • The presence of all conditions for quickly increasing the capabilities of the service if it is necessary to process more traffic.
  • The ability of the team to quickly add or edit the functionality of the service in accordance with changes in requirements or settings.

A few words about “technical debt”

“Technical Debt” is a popular term in software development and has many definitions. In general, “technical debt” usually refers to compromise decisions made to complete the development of a software product when it is not possible to do it properly. This means that some refinement is required, despite the fact that the creation of the program as a whole is completed.

It is impossible to develop a program without accumulating "technical debt", so the people of your team should share with each other the experience of properly processing it. A large amount of “technical debt” will slow down further work on the project. You need to know its volume in order to organize your work in such a way as to reduce it and gradually reduce it in the future.

All are responsible for quality.

Quality of service plays a role not only when testing a software product. Also, not a small group of employees is responsible for quality. The quality of any system is ensured by the people who create it.
Your employees should be able to notice any emerging quality problems of your system. Each of them should contribute to improving quality and solving problems.

You will not be able to understand how successful your software product is and whether it meets your requirements without testing - both under normal and non-standard working conditions. It's worth reading Dylan Robert's book Learning From First Responders»To find out how the software is tested and the team is tested under high loads (in this case, during the final stage of the 2012 presidential election).

All team members are responsible for the quality of any digital services, however the ultimate responsibility lies with the service manager. It is important that he interact directly with the rest of the team. Otherwise, there is a risk that your employees will not understand what measures they need to take to ensure quality. Your employees need to consider quality issues when composing user stories and use the time and resources to:

  • testing the program being created;
  • simplifying the program and regularly checking its availability to users;
  • analysis of error scenarios and development of a plan of necessary actions.

Attracting specialists and using special tools is very useful for ensuring the effectiveness of testing and is appropriate when testing protection against unauthorized access - using employees who are not part of the development team to perform this task allows you to check the effectiveness of solutions and identify weaknesses of the system, providing a useful look at the problems from the outside.

And the hiring of specialists to ensure quality assurance - they will be able to correctly coordinate all activities related to quality, organize a system of trainings and provide the resources necessary to create high-quality services, by:

  • assuming specific responsibilities and interacting with the team, and thus improving the quality of everything they do, rather than simply evaluating the progress of the project at milestones.
  • assuming responsibilities only for a short time and giving your employees the opportunity to manage quality themselves as part of the standard process of developing and improving the service.

We discussed this material with a number of startups of the IIDF Accelerator :

Questions: How do you work with technical debt? Do you use this concept in your project? If so, how do you calculate its volume? Are there any special internal team rules to eliminate it?

Dmitry Sokolov, founder and project manager of Pocket.DJ
CTO thinks through the implementation of tasks to minimize technical debt. He is personally responsible for it and he controls it. Every 20th and 21st working day is dedicated to refactoring. If the danger of technical debt is visible in advance, CTO must notify the team when planning the timeline.

Alexey Fedorishchev, project manager HappyCart.co
I think this is a marketing thing. It’s easier for us to measure in “features” and track their implementation. About responsibility for quality: yes, it is universal (as a startup of 4-7 people should be). And the arbiter in matters of quality is the client voting with his own ruble.

Sergey Svechnikov, Project Manager, StartExam
We do not work with technical debt. The team is small - mostly not full-time. Based on this, we do not yet regulate such rules.

Vladimir Kovalev, founder of the Timeviewer project
We use, but do not call it. Initially, we encountered this and were forced to rewrite and design the platform and structure of our service, for this we took Igor Rabinovich as a team, who has extensive experience in designing systems that have complex logic and can work quickly with a large number of devices.

Now we are faced with more minor "technical debts." We describe all the necessary functions and improvements in Assembla and break everything down by release. What we can implement on the existing platform, we do something, solve it with “crutches” if it needs to be done faster. But there are a number of those “debts” that remain and await the new release with rewriting logic.

Alexander Kaloshin, founder and project manager of Lastbackend
We have a high-tech product, and we could not do it “in haste”. There are 2 main reasons for this: risk at launch - with an influx of audiences, projects with technical debt have huge risks with possible falls and lack of stability; and the fact that projects with technical debt must in any case be put in order and (most likely) rewritten from scratch. Due to this, it was decided to immediately do the “right thing”. And we eliminated this problem before it appeared.

Usually, everything is done differently - just “crutches” are written that allow the project to hold on, but when recruiting a critical mass of these crutches, refactoring is still done, which is quite expensive in the end.

Our publications based on Gov.uk materials:

Also popular now: