Лига тестировщиков

Оригинал тут https://habrahabr.ru/company/luxoft/blog/310998/

История вопроса

В этой статье я хочу обсудить внедрение методологии DevOps с точки зрения тестирования и тестировщика. «Движение DevOps» (лучшего названия пока нет) развивается стремительно. Скорость внедрения новшеств в этой методологии, как и многие другие перемены, которые происходят в этой отрасли, очень высокая. При этом до сих пор нет четко сформулированного названия самого движения.

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

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

Для непосвященного читателя: что такое методология DevOps?

Простыми словами: DevOps — это понятие, обозначающее группу разработки и группу эксплуатации систем, которые более тесно сотрудничают между собой. В так называемом конвейере развертывания (от исходного программного кода до эксплуатации в производственной среде) разработчики автоматизируют какие-либо действия группы эксплуатации. Группа эксплуатации имеет возможность отслеживать действия разработчиков и оказывать на них некоторое влияние. При этом цель заключается в ускорении развертывания и внедрения программного обеспечения. Объединение группы эксплуатации (Ops) и разработчиков (Dev) (фактически в виде команды, использующей методы Agile) позволяет реализовать подход, который можно назвать «эксплуатация, основанная на методах Agile» (Agile Operations).

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

Итак, DevOps — это просто инструменты?

С одной стороны, цель методологии DevOps заключается в ликвидации узких мест в конвейере развертывания за счет использования автоматизации. Но автоматизацией многостадийных процессов все равно необходимо управлять. Многие автоматизированные процессы на самом деле не являются автономными — они не могут выполняться без вмешательства человека (для выполнения технического обслуживания и обработки нестандартных ситуаций). Полностью автоматизированный процесс DevOps не имеет смысла без учета влияния человеческого фактора. Несмотря на то что средства автоматизации выполняют много черновой работы, именно люди, управляющие процессом, обеспечивают его успешное (или неуспешное) выполнение.

Итак, DevOps — это просто разработчики (Dev) и группа эксплуатации (Ops), тесно сотрудничающие с использованием средств автоматизации?

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

Голова кругом! И что же все-таки означает DevOps? Это прогрессирующая новейшая дисциплина. Данный вопрос детально рассмотрен в статье «What Is DevOps?», которая появилась за несколько недель до написания данной статьи. Как вы уже поняли, определение понятия DevOps еще не сформулировано окончательно. Возможно, никогда и не будет.

Что это значит для тестировщиков? Это значит, что до сих пор не существует «единственно верного пути» и что ваша роль в режиме DevOps, который постоянно развивается (а каждый режим постоянно развивается), еще окончательно не установлена. Существуют два момента, которые вы можете реализовывать:

1) обращать внимание на болевые точки и прилагать усилия к тому, чтобы уменьшить степень их негативного влияния;

2) выявлять возможности, которые позволяют оптимизировать процесс DevOps.

Если и существует единственная мантра, которая наилучшим образом описывает движение к методологии DevOps, то она звучит так: «Если это неприятно, делайте это чаще». Это может показаться похожим на клише, однако я буду пользоваться этим выражением в качестве контекста для внедрения и совершенствования практических навыков по тестированию с использованием методологии DevOps.

Если это неприятно, делайте это чаще

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

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

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

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

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

Тесты, автоматизация и доверие

Ведется много споров вокруг значения, например, проверок и тестирования, и вокруг того, насколько мы можем полагаться на тестировщиков, на проверки и на автоматизированные средства (The New Model and Testing v Checking).

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

1) проверки, которые могут быть автоматизированы разработчиками в составе покомпонентных проверок и процессов непрерывной интеграции;

2) проверки, которые можно автоматизировать (обычно силами системных тестировщиков) для выполнения транзакций на уровне API, линий связи или всей системы;

3) тесты, включающие проверки совместимости и позволяющие продемонстрировать совместимость с браузерами, операционными системами и платформами;

4) тесты, которые может выполнить только человек.

В данной статье могу лишь сделать предположение, как осуществить такое разделение — каждая среда имеет свои особенности. Наиболее подходящий вопрос для данной статьи – как тестировщику «освободить себя» от поздних ручных проверок? Ранее я писал об исключении поздних ручных проверок. Это требует предусмотрительности и доверия.

Необходимо сконцентрировать внимание на следующих моментах:

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

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

3. Какие неавтоматизируемые тесты можно выполнять на компонентах, которые еще не интегрированы в предвыпускную версию? Можно ли выполнять ручное тестирование в сеансах парной работы с разработчиками? Существуют ли альтернативы такому тестированию? Может ли помочь работа с архивными документами, прототипирование с использованием подхода BDD? Можно ли выполнять проверки пользовательского интерфейса на макетах или каркасных конструкциях?

4. Какие проверки необходимо выполнять только вручную в отличие от проверок, которые требуется оставить для регрессионного тестирования (они являются кандидатами для автоматизированного тестирования)?

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

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

Практика, мониторинг и совершенствование

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

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

Когда проблемы встречаются в производственной среде, то задача заключается в том, чтобы использовать аналитическую информацию, полученную при выполнении мониторинга для того, чтобы не только отследить причину и устранить ее, но и для уточнения процесса тестирования (автоматизированного или ручного) и снижения вероятности возникновения подобных проблем в будущем. Роль тестирования и аналитической информации в функционировании всего конвейера определяется и обсуждается в статье «Thinking Big: Introducing Test Analytics».

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

Заключение

Недавно меня спросили: «В каком случае не следует пытаться применять методологию DevOps в организации?». Это хороший вопрос. Думаю в его основе лежит опасение, должна ли методология DevOps стать нормой и должны ли тестировщики обратить на это внимание. Мой ответ прост.

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

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

День тестировщика — профессиональный день тестировщиков, отмечаемый 9 сентября.

9 сентября 1947 года[1][2] учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле, и Грейс Хоппер произнесла слово «bug» (англ. «жук»), ставшее позднее термином, обозначающим компьютерную ошибку. Извлечённое насекомое было вклеено в технический дневник с сопроводительной надписью: «First actual case of bug being found» (англ. «первый случай в практике, когда был обнаружен жучок»). Этот забавный факт положил начало использованию слова «баг» в значении «ошибка». В итоге процесс выявления и устранения причин сбоя в работе компьютера получил название debugging (дебаггинг, «отладка», дословно: избавление от жуков). А само название профессии возникло от английского слова test, то есть испытание.

Вот как бывает))

Пара вводных слов

Всем доброго времени суток, меня зовут Туманов Дима. Сейчас я работаю в компании Rambler&Co и отвечаю за тестирование на проектах Афиши. В рамках данной статьи я развею несколько мифов об IT и тестировании в частности. Кроме того, приведу примеры из жизни как “не зная ничего” стать Junior QA Engineer в крупной компании.

Начало пути

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

Вопрос №1 — “Какую область для работы выбрать”

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

Вопрос №2 — “Какую профессию выбрать”

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

Вопрос №3 — “Какую компанию выбрать”

По сути все компании можно классифицировать несколькими способами. Во-первых по отношению заказчик-разработчик. Есть принципиальная разница между компаниями аутсорсерами и продуктовыми компаниями. Для первых самым важным является продажа продукта. Да, есть имя компании, отзывы клиентов, но так или иначе заработок идёт от прямых продаж. Для вторых важным является иметь качественный и популярный продукт. На таком продукте можно разместить дорогую рекламу и заработать много денег. Поэтому с точки зрения тестирования сильная команда будет сформирована именно в продуктовой компании. Во-вторых компании стоит разделять на русские и импортные. На текущий момент тестирование остаётся слабо развитым направлением в России. Это даёт свои плюсы и оставляет возможность занять своё место под солнцем без сильных проблем. Но, с другой стороны, сужает выбор достойных мест для работы. Благо в крупных интернет компаниях рунета уже “пройден этап варварства и созданы первые государства”. Для меня было важно работать именно в русской компании. Это что-то вроде “странного” патриотизма, если хотите. Исходя из всего этого мой выбор пал на крупные продуктовые интернет компании России. Таких кстати совсем немного и вы легко можете найти их рейтинг в Forbes (2014, 2015, 2016).

Вопрос №4 — “Как решить проблему отсутствия опыта”

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

Вопрос №5 — “Какие знания нужно получить и как это сделать”

Погружение в теорию тестирования. В первую очередь нужно научиться говорить на языке IT и тестирования в частности. Для этого необходимо разобраться с тем, что такое обеспечение качества и с основными понятиями из тестирования ПО. Данные материалы можно раскопать почти в любой книге по тестированию, но я ярый противник “технических” талмудов и считаю их медленным источником информации. Намного проще и быстрее это сделать из отдельных статей:

Что такое обеспечение качества

Что такое тестирование

Какие виды тестирования бывают

Какие уровни тестирования бывают

Какие тестовые артефакты есть и зачем их используют

Что такое тест дизайн

Как должен выглядеть процесс тестирования в вакууме

Что такое автоматизация тестирования и её основные виды

Какие метрики тестирования бывают и зачем они используются

Изучение Bug Tracking систем. Ключевым навыком инженера по тестированию является поиск, локализация и качественное заведение дефекта. Баг не существует в вакууме, он чётко связан с разделом программы, воспроизводится на списке конфигураций (операционная система и её версия, браузер и его версия), имеет свой приоритет. Более того работу над исправлением дефекта проводят несколько разных специалистов. Для того чтобы сделать процесс управления починки дефекта управляемым используют специальные системы. Здесь есть иллюзия выбора. Есть широко распространённый Redmine. Но если вы нацелены на работу в компании, указанного выше класса, то вам стоит изучать Jira. Для этого рекомендую сделать следующее:

Поставить себе пробную версию продукта и пройти эти ролики

Поставить себе и изучить базовые гаджеты: 1, 2, 3

Изучение Test Management систем. Любой софт — это по сути набор возможностей, то есть так или иначе конечное множество. При этом логика работы каждой из них не является идеальной моделью, а значит количество багов в системе всегда бесконечно. Вопрос в том что мы считаем багом, а что нет. Тут на помощь нам приходят требования от заказчика, описывающие то каким должен быть наш продукт. В качестве требований не обязательно должно быть техническое задание на тысячу страниц. Это также может быть прототип или постоянное живое обсуждение, если ваш продукт это просто новая доработка. Для перевода требований в набор проверок существуют методы из теории тестирования, которые вы уже должны были изучить выше. Но тесты, как и дефекты не существуют в вакууме и над одним функционалом может одновременно работать несколько специалистов по тестированию. По аналогии для управления процессом написания и применения тестов используют специальные системы. Лихие 90-е ушли и работа в “эксельках”, “блокнотиках” и “тестлинках” уже не является нормальным явлением. Недавно я проводил аудит по поиску подходящей системы. В основном они либо ничего не делают, либо стоят как космолёт. Золотой серединой является TestRail. Для его изучения нужно сделать следующее:

Поставить себе пробную версию и пройти эти ролики

Поднятие технического бэкграунда. Мы занимаемся web и mobile приложениями, поэтому рассуждение пойдёт в этом ключе. Настоящий тестировщик обязан понимать “начинку” того, что он проверяет. Это экономит время команды, так как специалист по тестированию сам может определить истинную причину дефекта и описать её правильно. Да и тестировать то, о чём ты ничего не знаешь как минимум странно. Плюс глубокое понимание улучшает ваши коммуникации с другими техническими специалистами. Для старта хватит этих общих знаний:

Как устроен интернет

Что такое backend и frontend

Что такое http запрос

Как работать с консолью браузера

Изучение программирования. Извечный вопрос нужно ли уметь программировать тестировщику имеет очень простой ответ. Нужно. Связано это с тем самым техническим бэкграундом во-первых и с развитием аналитичности вашего мышления во-вторых. На начальном этапе достаточно иметь базовые представления о программировании, в будущем для качественного роста вам потребуется изучить один из популярных языков. Например, Python или Java. На старте стоит изучить следующее:

Самые базовые знания по программированию

Основные языки программирования

Основные термины в программировании

Преодоление преграды отсутствия опыта. В IT-отрасли сейчас сильная нехватка кадров, в частности тестировщиков, поэтому часто берут перспективных кандидатов без опыта. Действительно, проще научить с нуля, чем переучивать. Для того, чтобы стать более востребованным по сравнению с другими стоит пройти специализированные курсы по тестированию. На них можно получить структурированные знания и самое главное опыт реального тестирования. Я рекомендую пройти курс “Школа успешных тестировщиков, v 2.0)” с этого портала

Поиск работы. Дальше остаётся только составить резюме, учитывая обновлённые знания и навыки, и научиться грамотно использовать hh

Перспективы развития

Работа занимает треть нашей жизни. Если отбросить сон, то это вообще половина нашего времени. Единственно правильным считаю работать там и делать то, что действительно нравится. Помимо морального удовлетворения есть и материальные блага. Уровень зарплат по официальным источникам даже на старте превышает среднюю температуру по больнице. Наличие ДМС, скидки на фитнес или наличие зала внутри компании, бесплатные билеты на различные мероприятия и прочие бонусы конечно же присутствуют. К тому же работа оценивается по количеству сделанной работы, а никак не по проведённому на ней времени. В IT всегда гибкий график и “опоздание на 15 минут” никак не будет наказываться. Более того, на это даже никто не обратит внимание, потому что это действительно нормально. Роль тестировщика — это не окончание вашего движения, это лишь точка входа. После пары лет хорошей практики в тестировании вы сможете выбрать любой путь развития в компании.

Почему я уверен в вашем успехе

Как когда-то сказал Стив Джобс: “Нельзя соединить точки жизненного пути, смотря вперёд. Их можно соединить, только оглядываясь в прошлое”. Именно этот принцип и даёт мне уверенность в том, что стать тестировщиком и начать получать удовлетворение от работы может абсолютно каждый. Есть и другие примеры за последние несколько лет, которые только подтверждают доступность данной профессии. У меня был некий Challenge Accepted. В какой-то момент ко мне почти одновременно обратилось два человека, которых я очень хорошо знал. Один из них на тот момент работал в правоохранительных органах, другой был профессиональный военным. Схожесть ситуации была на лицо. Они большие молодцы и с большой настойчивостью проходили примерно описанный выше план. Такое самообучение и поиск самой работы у них заняло порядка трёх-четырёх месяцев. Сейчас они работают тестировщиками, имеют перспективы для развития, гибкий график и думаю много чего в их жизнях ещё изменилось.

Post Scriptum

Ещё раз подчеркну. Войти в данную профессию не сложно. Это сможет каждый. Дальнейшее развитие в IT зависит уже только от вас.

скопипащено отсюдо: https://habrahabr.ru/company/rambler-co/blog/303254/