Когда на работе я присоединялся к новой команде, мне потребовалось некоторое время, чтобы подумать о том, какой вклад я хочу внести в команду. Очевидно, что некоторые пункты будут зависеть от контекста команды, в которой я работаю, но я решил поделиться с вами своими принципами качества. Сейчас именно они определяют мой подход к качеству и тестированию.
Качество – командный вид спорта. Я не тестирую все в одиночку. Возможно, я даже не буду делать большую часть сам. Моя цель в том, чтобы команда создавала высококачественное ПО, которое делает жизнь клиентов лучше, и я считаю, что это возможно лишь когда все члены команды знают, что такое качество. Значит, я буду работать с командой, чтобы убедиться, что мы не срезаем углы при тестировании и заражаемся вирусом качества (не волнуйтесь, он гораздо лучше, чем covid).
Тестирование должно быть катализатором, а не узким местом. «Ожидание окончания тестирования» должно быть редким явлением или должно отсутствовать как явление. Если тестирование стало таким узким местом, я буду работать с командой, чтобы выявить и устранить причины, по которым оно таковым стало. Время, потраченное на тестирование, должно быть инвестицией в будущее, а не формой зла, которая мешает нам делать то, что мы хотим.
Тестирование как перестраховка – это анти-паттерн. Тестирование – не то, что в первую очередь происходит после написания кода. Тестирование происходит во время проектирования, разработки и на продакшене. Другими словами, на каждом этапе разработки ПО. Ограничить тестирование всего одним этапом жизненного цикла ПО – крайне неэффективная и контрпродуктивная идея. Если команда в первую очередь полагается на тестирование постфактум, то я буду делать все возможное, чтобы распознать и устранить эту перестраховку.
Люди важнее всего. Мы пишем ПО, чтобы сделать жизнь людей лучше. Если получается иначе, значит мы пишем некачественное ПО. Я хочу знать, как улучшается жизнь наших клиентов, то есть получить понимание их потребностей и модели их поведения. Мне нравится использовать телеметрию и логирование для понимания качества нашего кода, но нужно помнить, что клиенты — это всесторонние и сложные личности, а не просто набор данных. Помимо этого, ПО создается людьми, поэтому часть подхода к качеству, ориентированного на людей – это размышление о вещах, которые могут повлиять на команду в частности. ПО, которое портит команде жизнь – некачественное ПО, вне зависимости от того, какое влияние оно оказывает на клиентов.
Тестирование масштабируемости важно. В разработке ПО все связано с масштабированием. Тестирование также должно быть масштабируемым. Значит, я должен работать с командой, которая делает инвестиции в масштабируемую автоматизацию тестирования. Регрессионное тестирование нельзя игнорировать, однако по мере роста функционала, оно становится слишком тяжелым, чтобы проводить его вручную.
Вот несколько принципов, которые лежат в основе моего подхода к тестированию. То, как они применяются в моей повседневной работе, конечно, будет сильно варьироваться в зависимости от потребностей команды, но эти цели и принципы лежат в основе тех вещей, над которыми я пытаюсь работать, и их я буду отстаивать.
Сегодня в 20:00 OTUS пройдет открытое занятие «Как сделать так, чтобы работа выбрала тебя?». Мы обсудим темы: резюме, подготовка к интервью, типы компаний, частые ошибки на собеседовании. Регистрация для всех желающих — по ссылке.
