Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

Сильные сотрудники – большое преимущество для компании.

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

Интервью с Александром Александровым тренды тестирования
Александр Александров

Эксперт компании Перфоманс Лаб

– Вы занимаетесь тестированием почти 50 лет, Вас называют «дедушкой русского тестирования». В чем вы видите современную роль QA? Чем является для Вас тестирование сейчас?

– Действительно, я занимаюсь тестированием с 1974 года – я тогда работал в Вычислительном Центре МГУ им. М.В. Ломоносова и занимался стандартизацией языков программирования. Сейчас для меня тестирование – это интересная любимая работа, которой я продолжаю заниматься с удовольствием, особенно когда получается то, что запланировано и при этом удается придумать что-то новое, взглянуть на то, что всем известно, по-своему. Кроме того, в силу уже многих прожитых лет мне хочется оставаться в профессии на сегодняшнем уровне, а не превращаться в старика, сидящего на лавочке и рассуждающего, что в его время тестирование было лучше. Пока быть на уровне получается. И конечно, отслеживаю современные тренды – и автоматизацию, и гибкие методологии, и тестирование мобильных приложений.

– Как изменилось тестирование за последний год?

– В 1997 году, Брайан Марик написал статью “Классические ошибки тестирования”. В этой статье перечислены наиболее распространенные ошибки тестирования. Сейчас, спустя 23 года, я попробовал провести анализ состояния тех же самых ошибок и посмотреть, что же изменилось. Мне показалось, что, к сожалению, особо ничего 🙁

До сих пор многие по-прежнему считают, что:

  • Тестировщики отвечают за качество, хотя цель тестирования – дать объективную оценку качества разрабатываемого и поставляемого продукта
  • Тестировать надо против требований, хотя есть неявные требования, а в требованиях бывают ошибки
  • Серьезность дефекта можно устанавливать «по договоренности», а не на основании согласованной всеми классификации
  • Метрики тестирования, статическое тестирование, модульное тестирование – без всего этого можно обойтись
  • Если каждую функцию можно протестировать отдельно, они прекрасно будут работать вместе
  • Документацию тестировать не надо, главное – протестировать систему
  • Никаких рисков в тестировании нет и быть не может
  • Любой может работать тестировщиком – знать и уметь для этого ничего не надо
  • Тестовые сценарии – это излишество, в крайнем случае, используются чек-листы
  • Если все тестовые сценарии перестали обнаруживать дефекты, тестирование закончено
  • Тестовые сценарии должны быть понятны только их авторам
  • Автоматизация всех ручных тестовых сценариев – это круто!
  • А автоматизация вообще без тестовых сценариев – это супер-пупер-круто!
  • Если автоматизировать регрессионное тестирование, можно найти гораздо больше дефектов

– Как Вы относитесь к автоматизации тестирования?

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

Есть ситуации, где автоматизация вряд ли заменит опытного специалиста. Прежде всего, это тестдизайн – самая творческая и самая трудная часть процесса тестирования. Затем поиск дефектов «вокруг» найденного – ведь дефекты как грибы – в одиночку не появляются. Назовите хоть одну систему автоматизированного тестирования, которая умеет это делать? Можно еще много ситуаций привести, когда ручное тестирование выгодней автоматизированного. Конечно, обязательно надо иметь в виду возврат инвестиций, экономическую составляющую процесса тестирования.

– А к гибким (Agile) методологиям?

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

– Известно, что пандемия Covid-19 повлияла и на отечественный рынок тестирования. В связи с этим у многих компаний обострились экономические проблемы. Выше Вы упомянули экономическую составляющую процесса тестирования. Что это такое и как это связано с экономикой вообще?

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

Разработчики могут ответить на вопрос «Сколько нужно времени, чтобы всё запрограммировать?» – например, два с половиной месяца. А почему? А потому, что там 18 функций, и в среднем на одну понадобится 3 дня. А сколько времени нужно тестировщику, чтобы найти все дефекты? А сколько времени нужно тестировщику, чтобы написать все тестовые сценарии? А сколько
времени нужно тестировщику, чтобы проверить всю функциональность? Ведь исчерпывающее тестирование невозможно. Значит, мы должны говорить о том, когда мы прекращаем тестирование и почему мы его прекращаем. И эти критерии должны быть как технологическими, так и экономическими.

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

Инвестиции в трудозатраты должны возвращаться (ROI) качеством объекта тестирования. Мы знаем, на что мы должны потратить время и деньги – мы должны привлечь в проект людей определённой квалификации, платить за инструменты автоматизации и так далее. Мы должны инвестировать в тестирование, в том числе и в трудозатраты. Но любой инвестор спросит, что он получит взамен. А что мы можем предоставить взамен? Только качество.

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

– Конечно, легко. Вопрос в том, каким тестировщиком.

Я много раз говорил и писал про «моду» и «пену», аналоги Курниковой, Волочковой и Баскова в тестировании, про то, что легче говорить о профессии, чем работать в ней. В качестве авторитетов могу сослаться на Рекса Блэка – специалиста мирового уровня.

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

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

Стать недотестировщиком и выдавать себя за тестировщика в кругу таких же недотестировшиков – просто.

Стать специалистом в любой области (не только тестировании) – сложно и долго.

– Что важнее для компании – человеческие ресурсы или процессы?

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

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

– На Ваш взгляд, слабость каких процессных компонентов типична в этом году?

– Я бы назвал две – unit (модульное) тестирование и статическое тестирование (рецензирование) требований и спецификаций. Они, безусловно, разные. Однако их, к сожалению, объединяет общая тенденция. Это позднее обнаружение (и, как следствие, исправление) дефектов.

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

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

Мне кажется, стоит уделять больше внимания прежде всего процессам тестирования.

Поделиться ссылкой:

Подписаться
Уведомить о
guest
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Поделиться ссылкой: