Home

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Меня передергивает каждый раз, когда я слышу как "менеджер" или "директор" говорят о качестве. Почему? Остановите меня, если это вам знакомо… Вы присутствуете на одном из этих длинных, скучных совещаний, и "увлеченный" менеджер берет слово, чтобы рассказать "историю о качестве", и вы знаете, что вы услышите, но все же слушаете в надежде, что узнаете что-то новое. Однако наступает момент, когда ваши мечты разбиваются, и звучит знакомый припев "мы улучшили наше качество на солидный процент… Мы увеличили покрытие и количество тестов в этой, той и той областях", и вы рвете на себе волосы и бьетесь головой об стол, рыдая "Нет, нет, нет… количество тестов и проценты не имеют никакого отношения к качеству, когда вы уже это запомните… Вы что, в лесу живете?!" И это продолжается без конца, спустя несколько месяцев кто-нибудь еще повторит ту же самую мантру. Встает хороший вопрос – что, черт побери, не так с качеством и тем, как его воспринимают люди?

Рискну сказать, что с качеством все в порядке – в конце концов, это то, к чему мы все стремимся, не так ли? Качество жизни, качественная машина, качественные отношения, мы должны что-то в этом понимать, но почему мы так путаемся, говоря о качестве ПО? Я уверен, что у качества есть грязные секретики, которые узнаешь, только имея с ним дело.

Грязный секретик 1: Качество не имеет отношения к цифрам.

Вряд ли существует конференция по тестированию или разработке ПО, где не присутствует определенная разновидность клоунов, кричащих со сцены, как важно улучшать качество, снижая количество ручных тестов и повышая покрытия, улучшая соотношение чего-то там или общее количество багов, ускользнувших на прод. Все вы их знаете.

Проблема, которую я вижу в выражениях вроде "улучшения качества" путем повышения покрытия выше 80% или снижая количество багов, в том, что они не имеют никакого отношения к концепции качества. Качество сложно измерить, и вы отдали бы все на свете, чтобы получить обратную связь про качество от ваших пользователей. Поэтому все эти разговоры об улучшении нашего качества после добавления Х тестов в набор – это принятие желаемого за действительное. То, что вы действуете в соответствии с этим, или делаете вид, что качество зависит от количества тестов, или количества упавших тестов, или процента покрытия, не имеет к качеству отношения.

Что мы, в конце концов, знаем о числах:

• Достаточно лишь одного бага, чтобы поставить под удар вашу репутацию как разработчиков и нанести финансовый ущерб вам или вашим клиентам.
• Достаточно лишь одного возмущенного, расстроенного клиента, чтобы поднять шум и разнести вашу репутацию в куски.
• Достаточно лишь одного упущенного теста, который достаточно важен, чтобы повлечь за собой два события, описанных выше.

Не существует золотого стандарта или числа для тестирования – если бы оно существовало, то все бы просто взяли его за стандарт раз и навсегда.

Не поймите меня неправильно, эти числа небесполезны – они дают информацию, и она нужна нам для принятия важных решений о ПО.

• Увеличение количества багов, ускользнувших от тестов, дает вам понять, что вы пропускаете баги, и что ваше тестирование неэффективно.
• Увеличение количества багов регресса означает, что у вас слишком много связанной функциональности, которая ломается каждый раз, когда в код добавляется новая строка.
• Даже процентное соотношение тестов и покрытия в какой-то степени полезно. Проблема с автотестами в том, что как измерить, насколько они полезны? У вас тысяча тестов, ну и что, как вы узнаете, что они действительно что-то проверяют? Можно, конечно, измерить процент отлова багов, но это ни о чем вам не говорит, потому что интерполяции на исторические данные недостаточно, чтобы делать прогнозы о будущем… разве что вы предсказуемо глупо себя ведете.

Иными словами, числа – это прекрасно, но они – не качество, они не повышают качество – они дают ВАМ инструменты и видимость, чтобы вы действовали, начинали разговор, поднимали вопросы, которые в будущем могут улучшить качество.

Качество не измеряется в тестах, так же, как и любовь не измеряется количеством признаний в любви своему партнеру.

Никак не могу взять в толк, почему людям так трудно это понять.

Грязный секретик 2: Качество неимоверно субъективно

Самая большая, на мой взгляд, проблема с восприятием качества сторонними лицами – это их вера в то, что существует жестко закодированная формула качества – функция количества тестов, покрытия и багов. На самом деле качество очень субъективно. Джерри Вайнберг сказал, что качество – это ценность для кого-то; того, кто имеет значение, добавил Джеймс Бах. Итак, говоря о качестве, мы неизбежно должны обсуждать ценности. Нечасто услышишь об этом на конференциях, не так ли?

Предположим, вы фанат автомобилей. Вы убеждены, что лучшие машины делает Mercedes, но как-то раз вы встречаете человека, уверенного, что это BMW, ну или любая другая марка. Почему? Все данные в открытом доступе, вы можете обсудить конкретные модели, мощность, дополнительные опции, коробки передач, что угодно – но все же вам нравится одна марка, а ему другая. В чем причина? Ценности – это просто ценности одной компании, явно или скрыто встроенные в их продукт и делающие его привлекательнее для вас. То же самое касается мобильных телефонов, ПО, тест-фреймворков, зубных щеток и носков – так работает мир людей.

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

Не сработает, если вы неискренни, или если вы пытаетесь обмануть мир, заявляя, что ваша магическая формула решит все проблемы.

Грязный секретик 3: Вы не обеспечиваете качество

Когда я попал в IT, тестировщики (или QA), казалось, верят, что они эдакие волшебные пчелки, поедающие ПО и гадящие качеством. Почти десять лет спустя мы все еще верим в это. Некоторые из нас даже оскорбляются, если назвать их тестировщиками. Даже я попался в эту ловушку, будучи новичком – слово "тестировщик" было для меня унизительным и неуважительным.

Со временем и при помощи моих наставников я выяснил, что качество нельзя насильно "втестировать" в продукт. В реальности тестирование и качество никак явно не коррелируют.

Да, конечно, мы знаем, что успешные компании тестируют свое ПО, но в мире тысячи компаний с успешными продуктами и ужасными процессами – настолько ужасными, что вы чешете в затылке, недоумевая, как им удается не потерять свой бизнес. И не будем забывать, что даже технические гиганты начинали в гараже с пятью разработчиками на коленке – у них не было "директора по качеству", "агентов изменений", "ангелов" или как еще хипстерам, занимающимся тестированием, нравится себя называть.

Тестирование не обеспечивает качество так же, как тест на Covid не гарантирует, что вам станет лучше – он просто дает вам информацию о вашем текущем состоянии. Иными словами, тестирование – это диагностика, дающая важную информацию, которая может повлиять на ваши решения о качестве.

Тестирование – это непростая, нетривиальная и зачастую неудобная задача по нахождению проблем и передаче этой информации людям, которые принимают важные решения. Качество, с другой стороны – это усилия далеко за пределами возможностей одного человека: это ответственность всей команды, тут значим вклад каждого участника.

Итак, я хочу очень четко это сформулировать – не существует действия или его отсутствия, приводящего к "обеспечению качества", если бы оно существовало – почему же мы все этим не заняты? Тестирование занимает время и силы, если бы существовал простой способ им заниматься – его бы уже сбрутфорсили.

Грязный секретик 4: Вы не предотвращаете появление багов

Помимо разговоров о метриках и том, как они улучшают качество, есть также группа людей из мира Agile, уверенных, что они улучшают качество путем "предотвращения" появления багов, и, следовательно, снижения "накладных расходов на ненужное тестирование". Это очень забавно.

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

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

Как же быть с качеством, учитывая наши ограничения?

Я большой поклонник цитаты Джордана Питерсона – сначала займитесь своим собственным садиком, а затем пытайтесь изменить мир. Поэтому я убежден, что когда мы говорим о качестве, то его важный аспект и единственная его часть, которую мы можем обеспечить с некоторой уверенностью – это качество нашей собственной работы.

Как этого добиться?

• Убедитесь, что вы первым приходите и последним уходите, когда нужно что-то сделать.
• Выложитесь в тестировании на все сто, не ограничивайтесь допустимым минимумом. Это включает оспаривание всего, что вы видите, нарушение правил, многообразие мышления, вызов самому себе.
• Потренируйтесь в политике нулевой толерантности к лени и посредственности.
• Не автоматизируйте с целью снизить, изменить или заменить тестирование – делайте это, чтобы расширить его, сфокусировать, обогатить.
• Развивайте ваше исследовательское и критическое мышление, подходите ко всему как к вызову, который даст вам чему-то научиться, а не как к скучной однообразной задаче.

Если вы все это делаете, то вы уже стараетесь лучше, чем 75% отрасли, поэтому путь отсюда – только вперед.

Что делать, чтобы стать еще лучше?

• Научитесь программировать – это сделает вас компетентнее в мире ПО, и поможет вам использовать инструменты в помощь себе.
• Беритесь за самые сложные задачи из возможных – всегда есть то, от чего с криками убегают все остальные, потому что это скучно, слишком сложно, непривлекательно, и т. д. Возьмитесь за это – это докажет, что вы достойны доверия, и если вы справитесь – это поможет вашей карьере, и вы многому научитесь. Даже если вы потерпите неудачу, сам факт, что у вас хватило смелости вызваться, многому вас научит.
• Будьте готовы выступить адвокатом качества – предлагайте улучшения, побуждайте коллег лучше работать, будьте их наставником и проводником на пути к более эффективному тестированию. Это можно сделать множеством способов – лекциями, демонстрациями, парными сессиями, код-ревью, и т. д.

Заключение

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

Обсудить в форуме