Александр Александров
Интервью, с Александром Александровым — экспертом компании Перфоманс Лаб, членом коллегии RSTQB – Российской ветви международной организация по сертификации тестировщиков программного обеспечения.
«Сильные сотрудники – большое преимущество для компании».
-- Вы занимаетесь тестированием почти 50 лет, Вас называют «дедушкой русского тестирования». В чем вы видите современную роль QA? Чем является для Вас тестирование сейчас?
— Действительно, я занимаюсь тестированием с 1974 года – я тогда работал в Вычислительном Центре МГУ им. М.В. Ломоносова и занимался стандартизацией языков программирования. Сейчас для меня тестирование – это интересная любимая работа, которой я продолжаю заниматься с удовольствием, особенно когда получается то, что запланировано и при этом удается придумать что-то новое, взглянуть на то, что всем известно, по-своему.
Кроме того, в силу уже многих прожитых лет мне хочется оставаться в профессии на сегодняшнем уровне, а не
превращаться в старика, сидящего на лавочке и рассуждающего, что в его время тестирование было лучше. Пока быть на уровне получается. И конечно, отслеживаю современные тренды – и автоматизацию, и гибкие методологии, и тестирование мобильных приложений.
-- Как изменилось тестирование за последний год?
До сих пор многие по-прежнему считают, что:
- Тестировщики отвечают за качество, хотя цель тестирования – дать объективную оценку качества разрабатываемого и поставляемого продукта
- Тестировать надо против требований, хотя есть неявные требования, а в требованиях бывают ошибки
- Серьезность дефекта можно устанавливать «по договоренности», а не на основании согласованной всеми классификации
- Метрики тестирования, статическое тестирование, модульное тестирование – без всего этого можно обойтись
- Если каждую функцию можно протестировать отдельно, они прекрасно будут работать вместе
- Документацию тестировать не надо, главное – протестировать систему
- Никаких рисков в тестировании нет и быть не может
- Любой может работать тестировщиком — знать и уметь для этого ничего не надо
- Тестовые сценарии – это излишество, в крайнем случае, используются чек-листы
- Если все тестовые сценарии перестали обнаруживать дефекты, тестирование закончено
- Тестовые сценарии должны быть понятны только их авторам
- Автоматизация всех ручных тестовых сценариев – это круто!
- А автоматизация вообще без тестовых сценариев – это супер-пупер-круто!
- Если автоматизировать регрессионное тестирование, можно найти гораздо больше дефектов
-- Как Вы относитесь к автоматизации тестирования?
— Я рассматриваю методы и инструменты автоматизации как очень мощные средства, использование которых требует очень высокой квалификации, знаний, опыта. В противном случае вместо выгоды можно нанести вред.
Есть ситуации, где автоматизация вряд ли заменит опытного специалиста. Прежде всего, это тестдизайн — самая творческая и самая трудная часть процесса тестирования. Затем поиск дефектов «вокруг» найденного – ведь дефекты как грибы – в одиночку не появляются. Назовите хоть одну систему автоматизированного тестирования, которая умеет это делать? Можно еще много ситуаций привести, когда ручное тестирование выгодней автоматизированного. Конечно, обязательно надо иметь в виду возврат инвестиций, экономическую составляющую процесса тестирования.
-- А к гибким (Agile) методологиям?
– Я инженер, и я не фанат гибких методологий. Тестирование – оно и в Африке тестирование. В частности, требования в формате пользовательских историй – это хорошо, удобно, облегчает проектирование тестов на основе критериев приемки. Но это не есть специфика гибких методологий – никто не мешает фиксировать требования в таком виде, например, в водопадной модели.
А вот тот факт, что при выполнении спринта допустимо реализовать не весь объем работ не все, если команда не успевает, вряд ли нравится заказчику.
Безусловно, в гибких методологиях есть много полезного, но никто не запрещает это использовать в более широкой области.
-- Известно, что пандемия Covid-19 повлияла и на отечественный рынок тестирования. В связи с этим у многих компаний обострились экономические проблемы. Выше Вы упомянули экономическую составляющую процесса тестирования. Что это такое и как это связано с экономикой вообще?
— Это связано с процессами тестирования и в первую очередь с процессов планирования и оценки трудозатрат. Как известно, исчерпывающее тестирование невозможно. В этом принципиальное отличие того, чем занимаемся мы, тестировщики, от того, что делают разработчики — все разработать можно, все протестировать нельзя.
Разработчики могут ответить на вопрос «Сколько нужно времени, чтобы всё запрограммировать?» – например, два с половиной месяца. А почему? А потому, что там 18 функций, и в среднем на одну понадобится 3 дня. А сколько времени нужно тестировщику, чтобы найти все дефекты? А сколько времени нужно тестировщику, чтобы написать все тестовые сценарии? А сколько
времени нужно тестировщику, чтобы проверить всю функциональность? Ведь исчерпывающее тестирование невозможно. Значит, мы должны говорить о том, когда мы прекращаем тестирование и почему мы его прекращаем. И эти критерии должны быть как технологическими, так и экономическими.
Мы должны оценить трудозатраты на тестирование, но не трудозатраты вообще, а те, которые нам нужны для достижения вполне определённого эффекта. Необходимо уметь планировать момент, когда следует остановить тестирование, и достоверно ожидать, что при этом получается с системой.
Инвестиции в трудозатраты должны возвращаться (ROI) качеством объекта тестирования. Мы знаем, на что мы должны потратить время и деньги — мы должны привлечь в проект людей определённой квалификации, платить за инструменты автоматизации и так далее. Мы должны инвестировать в тестирование, в том числе и в трудозатраты. Но любой инвестор спросит, что он получит взамен. А что мы можем предоставить взамен? Только качество.
-- Отдельный вопрос о тех специалистах, которые привлекаются сегодня к тестированию. Известно, что среди них и техподдержка, и разработчики, и аналитики, и даже бизнеспользователи. Получаются, что тестировать могут все. Легко ли стать тестировщиком?
— Конечно, легко. Вопрос в том, каким тестировщиком.
Я много раз говорил и писал про «моду» и «пену», аналоги Курниковой, Волочковой и Баскова в тестировании, про то, что легче говорить о профессии, чем работать в ней. В качестве авторитетов могу сослаться на Рекса Блэка – специалиста мирового уровня.
Чтобы стать хорошим тестировшиком, надо много знать и много уметь делать самому. Чтобы стать хорошим тест-менеджером или начальником подразделения тестирования, надо успешно пройти весь карьерный путь – поработать тестировщиком, тест-дизайнером, тест-лидом, получить требуемые знания и навыки и уметь применять их в сложных ситуациях, а не просто рассказывать, как должно быть.
К сожалению, можно встретить огромное количество публикаций об успешном построении процессов тестирования с нуля, руководстве проектами тестирования, группами тестирования, при этом инженерная квалификация авторов, мягко говоря, на уровне плинтуса.
Стать недотестировщиком и выдавать себя за тестировщика в кругу таких же недотестировшиков – просто.
Стать специалистом в любой области (не только тестировании) – сложно и долго.
-- Что важнее для компании – человеческие ресурсы или процессы?
— Конечно, сильные сотрудники – большое преимущество для компании. Но надо понимать, что сотрудники уходят в отпуска, болеют, рожают детей и даже покидают компанию навсегда. Нельзя превращать компанию в учебное заведение – наняли, вырастили, обучили, распрощались и все сначала. Поэтому мне кажется, что процессы, создаваемые этими сильными сотрудниками, но затем отчужденные и существующие независимо от них, обеспечивают компании значительную устойчивость на рынке.
Я уже не говорю о том, что правильно выстроенные процессы позволяют обойтись менее квалифицированными и, как правило, менее дорогостоящими ресурсами. Это значит, что компания сможет вернуть вложенные в совершенствование процессов инвестиции и в дальнейшем успешно зарабатывать выполнением проектов. От этого лучше будет всем – и компании, и сотрудникам, и заказчикам.
-- На Ваш взгляд, слабость каких процессных компонентов типична в этом году?
— Я бы назвал две — unit (модульное) тестирование и статическое тестирование (рецензирование) требований и спецификаций. Они, безусловно, разные. Однако их, к сожалению, объединяет общая тенденция. Это позднее обнаружение (и, как следствие, исправление) дефектов.
Дефекты, которые могли бы быть обнаружены во время unit-тестирования, должны обнаруживаться во время системного тестирования. Представьте, что в сложной программе надо обнаружить утечку память в единственном модуле. Во время unit-тестирования такая задача решается гораздо проще и быстрее, чем во время системного тестирования.
Про дефекты в требованиях, обнаруживающиеся во время системного тестирования, я уже и не говорю – сколько копий на эту темы было сломано, а воз и ныне там.
Мне кажется, стоит уделять больше внимания прежде всего процессам тестирования.
