Home

Автор: Патрик Прилл (Patrick Prill).

Оригинал статьи: https://testpappy.wordpress.com/2016/06/01/reinventing-testers-and-testing-to-prepare-for-the-future/

Перевод: Ольга Алифанова.

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

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

В середине мая 2016 года Джеймс и Джон Бах проводили воркшоп на тему "Преобразование тестировщиков". Я на нем не присутствовал, поэтому не буду вдаваться в детали. Он не произвел никаких потрясений в сообществе – мое внимание привлек один-единственный слайд, вырванный из контекста и опубликованный в Твиттере.

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

"Тестировщики не должны расходиться во мнениях – не должно быть никаких расхождений в вопросе, баг это или не баг!", "Ни один разумный человек не захочет пойти в тестировщики!", "Задача тестировщика – обеспечивать качество!", "Тестирование чересчур непредсказуемо, введите критерии готовности и подходите к разработке, основываясь на приемочных тестах, чтобы знать, когда ваша работа завершена!", и "Вы должны документировать все ваши тест-кейсы, соотносить их с требованиями, и отслеживать метрики, связанные с ними!".

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

Мой взгляд на нынешнее положение тестировщиков и тестирования как фазы разработки

В целом мне ясно, откуда растут ноги у нынешних проблем тестирования.

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

Когда тестировщики включаются в работу последними, в любом срыве сроков виноваты будут именно они.

Двадцать лет назад подходы к разработке изменились, сдвигаясь в сторону XP, Scrum, Kanban, Agile, Lean и других методологий, нацеленных на более быструю передачу кода в релиз или в руки заказчика. Быстрая обратная связь стимулирует изначально делать то, что нужно, не тратя деньги на ненужную деятельность.

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

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

Сейчас подходы к разработке ушли так далеко, что тестировщики больше не могут успевать за ними.

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

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

Как справляются с тестированием в Agile

Проекты, продукты и компании, работающие по Agile-методологии, стараются начинать тестирование как можно раньше и привлекать к нему разработчиков. Большое количество проверок автоматизируется, чтобы ускорить регрессионное тестирование. Они стараются сокращать длительность спринтов, и к тестированию подключаются все, кто не занят исправлением багов. Такие подходы, как BDD, TDD, ATDD поощряют сотрудничество между бизнес-аналитиками и разработчиками, и помогают разработке создавать более удачные программные решения.

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

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

В АВ-подкасте Алан Пейдж и Брент Дженсен регулярно рассказывают про процессы разработки в Майкрософт, и судя по всему, у Майкрософт все отлично.

Когда кто-то заявляет, что 90% тестировщиков пора искать новую работу (Джеймс Бах цитировал что-то подобное в подкасте, на который я наткнулся в прошлом году), я отвечаю, что, возможно, не 90, а 70, но все так. Все больше компаний меняет свой подход к разработке, и нам нужно куда меньше тестировщиков. И, конечно, останутся лучшие 30%, а не просто любые 30% и уж точно не самые дешевые 30%.

Как будет развиваться роль тестировщика?

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

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

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

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

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

Нуждается ли роль тестировщика в переменах?

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

Если все это не занимает весь рабочий день, или если мне кажется, что я могу принести дополнительную пользу в какой-то другой роли, то это здорово, и если у вас есть такая возможность, пользуйтесь ей. Но это никак не влияет на вашу роль как тестировщика.

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

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

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

Когда Брент Дженсен заявляет, что дата-аналитики и телеметрия атакуют тестирование (см. 39 эпизод подкаста "АВ-тестирование"), я надеюсь, что тестировщики среагируют соответственно, пополнят свой арсенал и станут частью этих подходов. Именно это, с моей точки зрения, и является иллюстрацией фразы "преуспеть как тестировщик". Отслеживайте и собирайте обратную связь от пользователей, используйте научные подходы, чтобы предсказать дальнейшие события. Это же просто замечательно! Где можно этому научиться? Как тестировщик, и я хочу освоить такие инструменты!

Ответственность за общее снижение качества

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

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

Тестировщики должны бороться с этим и поднимать качество таких проектов на должный уровень.

Что нужно сделать компаниям

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

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

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

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

И если у вас возникает вопрос, что вам делать, если вы вложитесь в людей, а они уволятся – лучше спросите себя, что вы будете делать, если вы не начнете в них вкладываться и они останутся работать!

Что нужно сделать тестировщикам

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

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

Хотите остаться в тех 10-30% тестировщиков, которые сохранят свою работу? Начинайте прямо сейчас.

И, напоследок – гордитесь тем, что вы тестировщик!

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