Качество вместо контроля качества

[astec]

Отличная статья. Дайте пожалуйста знать если вдруг переведёте на английский.

[ard]

Английская версия — на dev.to.

[Morjus]

С нетерпением жду следующей статьи о подходах.

[Sergey-Titkov]

1.Выполнение заранее составленных требований — не самоцель. Важнее сделать «классный» продукт в результате.

Если на входе мусор, на выходе биг дата. Разберитесь с требованиями. Перестаньте из них делать мусор и экономить на этом.

2.Пользовательский опыт важен.

См. пункт 1.

3.Уровень качества задаётся при разработке. Тратя усилия на компенсацию разработки тестированием, мы лишаем себя возможности направить эти усилия на развитие разработки и, как следствие, качества.

Уровень качества задается только руководством компани. Ни разработчик ни тем более тестировщик не способны ничего с этим сделать.

4.Тестирование — бонус, улучшающий систему, а не критическая необходимость.

Это верификация и валидация на соответствия требованиям. См. пункт 1.

[ggo]

1.Выполнение заранее составленных требований — не самоцель. Важнее сделать «классный» продукт в результате.

У этого утверждения, развернутое пояснение в статье.
Если фразу вырвать из контекста, то да, фраза вызывает вопросы. Но важен то контекст.

Уровень качества задается только руководством компани. Ни разработчик ни тем более тестировщик не способны ничего с этим сделать.

Качество не зависит от непосредственного исполнителя?
Ну вот совсем не зависит? Как руководство захочет, так и будет? Главное только захотеть?

[Sergey-Titkov]

Качество не зависит от непосредственного исполнителя?
Ну вот совсем не зависит? Как руководство захочет, так и будет? Главное только захотеть?

Вот представь себе, да! И только руководство за это несет ответственность. Я понимаю это неприятный и очень болезненный факт, но когда то надо прощаться с иллюзиями.
И в руководстве бейзкампа это хорошо понимают! Перенимайте лучшие практики!

Приведу пример, в тексте:

Если каждая задача возвращается после тестирования или при починке одного бага всплывает три новых, то с качеством что-то не так.

Это не с качеством, что то не так. Это было принято положить болт на атрибут качества сопровождаемость. Это вы так бюджет распределили. И вполне возможно, что для вашего этого контекста норм. Но опять же это решение руководства, а не разработчика и тестировщика, они не решают куда вкладывать бюджет проекта, а куда нет.

[ard]

В чём же, по-вашему, роль исполнителя? Что он делает, на что влияет?

[Sergey-Titkov]

Профессионал делает работу с тем уровнем ожидаемого качества, которое от него ожидают :)

[ard]

С этим сложно поспорить :)

Но это и есть "уровень качества задаётся при разработке", к которому вы обращались в первом комментарии.

[Sergey-Titkov]

И это возвращает нас ровно к одному. За качество отвечает только руководство компании.

[Racheengel]

Сам занят в области автоматизации контроля качества. И да, всё так :)

[insomnia77]

Добрый день. Спасибо за статью.

Не согласен вот с этим пунктом

Тестирование — бонус, улучшающий систему, а не критическая необходимость.

С помощью тестирования проверяется, что продукт реализован как задумано и это критично. Например, разработана система денежных переводов и в ней должна быть фича, что уведомления о транзакциях приходят на почту, и если, например, криво настроена CRM, то без тестирования никто даже не узнает, что фича не работает.

[ard]

Безусловно. Ваш пример — как раз про то, что важно протестировать. И что может потеряться среди неважного, если механически тестировать всё.

[T32202]

Материал супер! Спасибо.
Пока сталкиваемся чаще с противоположностью описанного подхода :)

[solenie]

Спасибо за статью. Мы всегда говорим нашим разработчикам, что за качество отвечает вся команда, а не только тестировщики.
В этом контексте очень понравилась фраза:

Качество определяется тем, как сделан продукт, а не тем, как он протестирован.

Теперь буду её тоже использовать как аргумент, когда мы рассказываем новым разработчикам про наши стандарты качества.

[AndreySinelnikov]

> Почему качество жестко связывают с тестированием? Непонятно.

Классическая схема такая: тестирование — часть контроля качества, а контроль качества — часть обеспечения качества.