Блог A1QA

О тестировании и качестве ПО

Когда тестирование ПО превращается в сизифов труд: интервью с Адамом Найтом

На вопросы A1QA отвечает Адам Найт – профессиональный тестировщик, который любит свою работу и с удовольствием делится опытом в своем блоге. Адам часто выступает на специализированных мероприятиях: Agile Testing Days, UKTMF, STC Meetups и EUROStar.

Добрый день, Адам. Расскажите нам, пожалуйста, о себе.

adam-knight-interview-a1qaПоследние несколько месяцев я работаю в качестве консультанта по agile, разрабатывая должность руководителя продукта (product owner) в компании River. Компания занимается поставкой решений по вовлеченности сотрудников и их взаимодействию с заказчиками и партнерами. До этого я долгое время занимался базами данных RainStor. В мои непосредственные обязанности входило проведение тестирования, оказание технической поддержки и разработка технической документации. Кроме этого, я выполнял часть ежедневных обязанностей руководителя продукта.

У вас богатый опыт в тестировании. Как, на ваш взгляд, изменилось тестирование за время вашей карьеры?

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

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

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

Некоторые эксперты полагают, что в будущем все ручное тестирование будет автоматизировано. А каково ваше мнение?

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

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

Что касается меня, то я считаю, что автоматизация должна быть направлена не только на проведение проверок. Она должна предоставлять сведения о работе тестируемой функциональности, чтобы выяснить суть проблемы и устранить ее.

А возможно ли достичь 100% автоматизации?

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

Любому специалисту по тестированию понятно, что достичь 100% автоматизации невозможно. Человеку извне это объяснить сложнее.

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

Многие компании сегодня внедряют принципы agile и DevOps. Как будет выглядеть тестирование будущего?

Хотелось бы отметить, что разделение ролей в IT становится менее строгим. Применение методик agile и DevOps подразумевает, что каждый участник процесса наделен широким набором навыков и знаний. Постепенно мы отделяемся от разделения обязанностей, как это происходит на заводах и фабриках, где за каждым специалистом закреплен свой участок работы.

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

Какие основные преимущества agile-тестирования?

Я бы сформулировал вопрос немного иначе: «В чем преимущества agile-методологий для тестирования?»

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

Одним из главных плюсов применения agile является то, что тестировщики участвуют в обсуждении продукта: до начала очередной итерации проходит так называемая «Встреча трех» (“Three-Amigos”), где при участии руководителя продукта, разработчика и тестировщика решаются вопросы касательно новой функциональности.

Каким вы представляете идеальный процесс тестирования в будущем?

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

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

Свой блог я неспроста назвал «Сизифов труд». К сожалению, нередко тестирование ПО сводится к выполнению череды однотипных и порой бесполезных действий, напоминая тем самым труд Сизифа, который был обречен вкатывать на высокую гору громадный камень. На вершине горы камень вырывался из рук и скатывался вниз. И все начиналось сначала.

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

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

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

Кроме того, важно проявлять инициативу и не переставать учиться. Большую часть практических навыков я приобрел, исследуя новые интересные проекты в свободное от работы время. Так, я научился писать на языке Ruby, по вечерам разрабатывая инструмент для генерации SQL-кода. А для создания многопоточной тестовой программы мне пришлось самостоятельно выучить Java.

Если вы понимаете, что вам не хватает каких-то знаний, посвятите этому какое-то время и устраните пробел. А затем покажите вашему руководителю, что вы выучили и объясните, насколько это важно. Так вы не только приобретете новые навыки, но и ускорите развитие вашей карьеры.

Спасибо, Адам, за то, что поделились с нами вашими идеями.

Узнать больше об Адаме вы можете в его блоге a-sisyphean-task.com.

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