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

Ваш идеальный тестировщик / Habr

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

Здесь поможет очерк из психологии.

Личность человека — это сложная многослойная структура. Её самый глубокий уровень состоит из личностных качеств. Это стабильные внутренние особенности человека, как, например, искренность. Извлечь их достаточно сложно, немногие проявляют их на каждом шагу. Они открываются только спустя несколько лет работы бок о бок.

Следующий слой — ценности и убеждения. Это те характеристики, которые отвечают на вопрос “почему?” и “зачем?”. Это чувство прекрасного или желание общаться с хорошими людьми. Это важно знать, но вам об этом не расскажут. За час собеседования это не удастся раскрыть, ведь надо ещё поговорить о компании и о позиции.

Следующий слой — поступки. То, как человек обычно поступает, как он решает свою проблему. Вероятно, если он действовал подобным образом раньше, то и на работе будет себя вести также. Мы часто путаем поступки со свойствами личности. У человека может быть масса причин тянуть с закрытием задачи, но мы видим только его поступок.

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

Следующий слой: знания и навыки. Это то, чему человек научился, что он умеет. Если мы ищем junior QA, то знаний и навыков у него нет. Но это и не страшно, ведь их можно нарастить.

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

Какие качества ищем?

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

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

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

Как выбрать?

Всё зависит от целей и методов компании. В молодом коллективе обычно доминирует принцип «как угодно, лишь бы было сделано». Здесь нужен подвижный и командный тестировщик, который нацелен на результат.

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

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

Внимательный / Бдительный

Такой тестировщик всегда начеку и всё записывает. У него всегда под рукой набор для конспекта: блокнот с ручкой, ноутбук с текстовым редактором или смартфон с заметками. Чтобы сразу записать мимолётное озарение или неожиданное замечание.

С момента как такой QA узнаёт про задачу он сразу фиксирует для себя всё что собирает по крупицам — из требований, от разработчиков, из своего опыта или опыта коллег. Он может даже сразу накидать примерный чек-лист для проверок, ведь главное уловить суть, а расписать детали можно и позже.

Создать чеклист — это быстро

Почему?

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

Критичный / Логичный

Как говорил доктор Хаус — “Все люди лгут”. Разработчик завершил работу над мелкой ошибкой, тестировщик сразу проверил. Если есть время, то проверил дважды. Тестировщик ни за что не поверит, что можно что-то исправить с первого раза и до конца. Ошибаются все. А чем опытнее разработчик, тем загадочнее его ошибки.
Критически мыслящий QA выявляет не явные ошибки, а логичные с точки зрения технического задания. Его тест-кейсы не повторяют требования, а проверяют их.

«Нелогичное» и «невозможное» — разные вещи

Почему?

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

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

Любознательный / Дотошный

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

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

А бывает, что техническое задание состоит из пары слов, и код не добавляет ясности. Тогда самое верное решение — отправить задачу к заказчику на дополнение.

Подробные шаги тест-кейса внушают спокойствие

Почему?

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

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

Коммуникабельный / Сговорчивый

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

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

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

Чем раньше рассказать о проблеме, тем дешевле её исправить

Почему?

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

Ответственный / Исполнительный

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

Готовь сани летом, а тест-кейс с кодом

Почему?

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

В заключение

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

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

Немного о простом. Тест-дизайн. Часть 1 / Habr

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

И да, сегодня мы поговорим именно об обычных ручных (функциональных) тестировщиках, без уклона в автоматизацию, нагрузку и другие технические виды тестирования!

Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.

Почему?

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

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

Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете??? (ответы можете оставить в комментариях) Ну да ладно, продолжим:)

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

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

Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите довольное лицо Заказчика (ну или продукт овнера) качество задачи после внедрения.

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

И в этом цикле статей поговорим об этом.

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

Выглядит это так:

• Зачем нам нужны техники тест-дизайна?
• Чтобы правильно определить проверки для тестирования.
• А используете ли Вы их в работе?
• В явном виде нет, мы сами определяем то, что нужно проверить.

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

Ответ прост.

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

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

Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это использовать эти правила всегда и везде 🙂 уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!

В моей организации, как и общепринятых стандартах и практиках, задачами тест-дизайна являются:

• Анализ требований и рисков тестирования
• Определение проверок для тестирования
• Формализация проверок в виде тестовых сценариев
• Приоритезация проверок
• Определение подходов к тестированию

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

Итак, начнем.

А начнем мы с самого простого, а именно о 2-х основных техниках тест-дизайна, про которые все слышали, и я уверен, применяли, но скорее всего на интуитивном уровне в своей работе.
Это классы эквивалентности и граничные значения.

Что же такой классы эквивалентности?

Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.

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

Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.

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

Рассмотрим пример:

Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводится в форму:

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Мы определяем 2 основных класса – это позитивные и негативные сценарии.

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

Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +

В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.

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

Итого мы имеем.

• Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть любыми из данного диапазона класса)
• Негативные проверки: 0, 3, -1, А и т.д.

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

Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.

• Первый уровень – проверка элементов системы (например, полей, чекбоксов, кнопок и т.д.)
• Второй уровень – проверка логики работы системы при комбинации данных в элементах системы
• Третий уровень – проверка бизнес- процесса системы и логики работы программы.

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

Неотъемлемой часть проверки любого элемента является другая техника – граничные значения.

Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.

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

Вроде все просто!

Вернемся к нашему примеру ранее.

Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводиться в форму:

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Что же здесь будет границей?

Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так 🙂

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

Поэтому, помимо граничного значения мы используем для тестирования дополнительно 2 значения, значение перед границей и значение после границы.

В итоге мы имеем:

Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.

Также, у нас есть негативный класс, это от 0 до 18. Поэтому тут мы тоже должны использовать для тестирования граничные значения: -1, 0, 1, 17,18

Далее исключаем повторяющиеся значения, и получаем значения для проверки элемента ввода данных.

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.

Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).

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

Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).

Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.

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

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

Что ж, слишком легко??? Сейчас начнем разбирать более сложные техники, готовьтесь.

Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.

Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.

Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.

Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.

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

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

Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.

Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.

Получается, что вероятность возникновения дефекта при комбинации 3-х и более параметров настолько мала, что ее можно отбросить.

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

Давайте рассмотрим на примере функциональности дистанционного оформления карты в банке.

Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:

• ФИО
• Дата рождения
• Мобильный телефон
• Серия номер паспорта
• Электронная почта,
• а также 2 чек-бокса.

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

Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.

Итак,

Поле ФИО может принимать значения (классы):

• ФИО на русском
• Невалидное значение
• Пустое значение

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

Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

• Валидное значение
• Невалидное значение
• Пустое значение

Т.к. электронная почта необязательно, то данное поле имеет 2 значения:

• Валидное значение
• Невалидное значение

Чек-боксы обычно имеют всего 2 состояния – Y или N.

Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)

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

Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:

После перебора одной пары, мы создаем другую пару и начинаем перебирать значения (например номер мобильного телефона)
Подключаем следующий элемент и так далее до полного заполнения всей таблицы, которая будет выглядеть так:

Таким образом мы получаем 9 тестов с конкретными классами эквивалентности, которые мы можем вводить для проверки работы вариативности данных для формы. Классы мы можем заполнять конкретными значениями, которым мы получаем с вами используя 1 уровень техник тест-дизайна.

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

Надеюсь было полезно!

кто должен этим заниматься, кому это нужно и как меняется эта область / JUG Ru Group corporate blog / Habr

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

Игорь Хрол — специалист по автоматизации тестирования, около 10 лет работает в этой области в различных ролях: как инженер, архитектор, менеджер, тренер, консультант. Имеет большой опыт использования большинства популярных инструментов  (Selenium, HP QTP, TestComplete, JMeter). Программирует в основном на Ruby и Scala, но и на других языках также приходилось писать (Python, Java, C#, JavaScript, VBScript).
Сейчас работает в Toptal.

— Добрый день, Игорь. Многие читатели уже знакомы с вами и видели выступление в прошлом году на конференции Гейзенбаг. Если не секрет расскажите, пожалуйста, чем сейчас вы занимаетесь сейчас? Над чем идет работа?

Игорь Хрол: Доброго дня! С прошлого Гейзенбага род моих занятий принципиально не изменился — я все еще работаю в отделе аналитики компании Toptal. Правда, с того момента изменилась должность, я был QA Automation Engineer, а сейчас Team Lead. Теперь могу влиять на качество итогового результата по всем фронтам: и с точки зрения тестирования, и со стороны разработки, ну и организационные улучшения тоже не обходятся без меня.

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

От модных трендов Toptal не отстает, конечно. Внедряем технологии машинного обучения и прочего модного data science. Похоже, доклад про это будет хорошей темой для следующего Гейзенбага.

— Cовременный автотестер — это мастер на все руки или узкий специалист?

Игорь Хрол: Мне хотелось бы верить, что мастер на все руки. Если бы это было не так, то вряд ли бы я занимался этим 10 лет — стало бы скучно. Я не верю в узкую специализацию в IT вообще. В моей картине мира хороший инженер должен знать смежные области. Разработчик должен уметь тестировать и писать автотесты. Тестировщик — писать код и понимать вопросы управления. Я видел много глупостей и потерянного времени именно из-за того, что люди пилили свою узкую задачу и в силу разных причин не решали ее совместно с другими специалистами.

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

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

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

Игорь Хрол: По моим наблюдениям, специалисты в автоматизации тестирования — это в большинстве своем бывшие тестировщики, а не разработчики. Есть среди них разработчики, но не бывшие, а текущие. Это люди, которые в процессе разработки пишут большое количество автотестов и так или иначе сталкиваются с проблемами этой области. Что интересно, чаще именно они, а не автоматизаторы, выросшие из тестировщиков, двигают экспертизу в этой сфере вперед.

По поводу изучения языков за два месяца. За этот срок можно стать junior-специалистом, если есть склонность и стремление. Гуру не станешь, но работу найти можно будет. А дальше — годы реального опыта, пока не придет просветление.

— Существует мнение, что модульное  тестирование — это ответственность разработчиков кода. Согласны ли вы с ним? Когда есть огромный проект, где часто присутствует взаимосвязь, например, классов программы, требуется ли участие команд по автоматизации тестирования в таких проектах и таких тестированиях, или все зависит от конкретной ситуации?

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

Что касается огромных проектов и команд по автоматизации тестирования: я вел автоматизацию проектов по сервисному принципу, когда отдельной команде приходит запрос на автоматизацию в виде тест-кейсов, и они дружно пишут автотесты. Это были действительно большие проекты на несколько десятков автоматизаторов. Честно скажу, мне не очень понравился результат. Автотесты — это неотъемлемая часть продукта. И когда ими занимаются отдельные люди, не вовлеченные плотно ни в процесс разработки, ни в процесс тестирования, эти тесты становятся отдельной вещью в себе, нужной только самим автоматизаторам. Я называю это «писать тесты в тумбочку». С точки зрения формальных показателей выглядит все прилично — работа кипит, покрытие растет, а по факту эти автотесты используются очень мало.

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

— Хотелось бы задать вам вопрос, связанный с использованием Selenium WebDriver. Вы говорили, что активно следите за данным направлением начиная с версии 0.8. Как вы относитесь к тому, что стандарт W3C WebDriver получил статус W3C Candidate Recommendation? Как вы думаете, это приведет к активной доработке Selenium-а?

Игорь Хрол: Сам WebDriver уже давно сильно не меняется, по крайней мере внешне. В том числе благодаря этому он и стал стандартом. Что меняется — это качество реализации и поддержки на разных браузерах. Разработчики браузеров лучше знают, как сделать правильно, и могут менять, в том числе, сам браузер. И W3C «заставляет» их заниматься поддержкой WebDriver’a самим браузером.

Сейчас активно развиваются надстройки над Selenium’ом, вроде Selenide’a. Ситуация напоминает JavaScript и jQuery. Чистый Selenium/WebDriver хорошо знать, но пользоваться удобнее более высокоуровневыми библиотеками, в которых решены типовые задачи, специфические для взаимодействия с пользовательским интерфейсом.

— С момента участия в прошлогодней конференции Гейзенбаг изменился ли у вас подход к тестированию или набор программ, который вы используете?

Игорь Хрол: Полгода — это не такой большой срок для того, чтобы кардинально менять подход. Хотя, конечно же, мы пересматриваем наше тестирование, и оно эволюционирует. За последнее время мы начали активней использовать model based testing для тестирования наших бизнес-процессов. Если в двух словах, то мы случайным образом ходим по нашим workflow, глядя на возникающие проблемы и противоречия.

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

— Огромное спасибо. С нетерпением ждем вас на конференции.

Игорь Хрол: Спасибо!

Илари Хенрик Эгертер — специалист по программной инженерии и тестированию ПО, более 10 лет работает в этой сфере, начиная с области программного обеспечения и заканчивая электронной коммерцией на eBay. В 2013 году стал соучредителем Международного общества тестирования программного обеспечения (ISST), которое выступает за возвращение здравого смысла к тестированию, и сейчас является президентом организации. В 2015 году был избран в совет Ассоциации по тестированию программного обеспечения (AST), где выступает в качестве вице-президента по маркетингу.
В настоящее время управляющий директор House of Test GmbH.

— Илари, добрый день.  Расскажите, пожалуйста, о себе и своей работе.

Илари Хенрик Эгертер: В тестирование я пришел скорее случайно. Четырнадцать лет назад я изучал лингвистику и социологию в университете в Цюрихе, и там была работа в компании по медицинскому оборудованию, связанная с установкой ПК. Они также нуждались в тестировании, и именно поэтому я основательно подсел на данный вид деятельности. Мне очень понравилось сочетание социальных элементов и техники в этой работе. Через пару лет, уже став линейным менеджером всей команды, я также решил изучить разработку программного обеспечения. Затем я сменил работу и перешел в eBay, где возглавил группу тестирования для сайтов eBay в Европе.

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

— В прошлом году вы выступали с докладом «No Such Thing as Manual Testing and Other Confusions». Ваша аудитория состояла из людей из различных областей: тестировщиков, менеджеров, разработчиков. Как вы думаете, почему люди разных направлений так активно интересуются вопросами тестирования? Связано ли это с тем, что компании постепенно становятся зависимы от автоматизации тестирования?

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

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

Илари Хенрик Эгертер:  Я думаю, что большинство людей мало подходят для той работы, которой они занимаются, и поэтому результат не всегда хорош. Экспертиза по определению редка.

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

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

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

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

Илари Хенрик Эгертер:  Я никогда не говорил, что вам не нужны технические навыки для автоматизации. Автоматизация в тестировании — это проект по разработке программного обеспечения, и поэтому он, конечно, нуждается в инженерных знаниях. Причина, по которой я уделяю много внимания коммуникации, критическому мышлению и эпистемологии, состоит в том, что они часто игнорируются, хотя являются важными элементами, которые должны быть — назовем это — полным набором тестировщика.

— Скоро вы будете выступать с докладом «Think Bigger – How to Truly Become World-Class in Testing». Что вы хотите добиться от аудитории, показывая примеры и шаги для достижения целей в автоматизации тестирования? Какую отдачу вы хотите получить? Важно ли вам знать, что ваша информация помогает уложить данные в головах у собравшихся и направить их мысли в нужное русло?

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

— Большое спасибо за ваши ответы. Будем с нетерпением ждать ваше выступление.

Илари Хенрик Эгертер: До встречи на Гейзенбаг в Санкт-Петербурге.

Больше информации и знаний  по автоматизации тестирования, инструментарию, окружению для тестирования и другим направлениям в этом нелегком ремесле вы можете узнать на предстоящей конференции Гейзенбаг 2017 Piter 4 июня. Мероприятие соберет автоматизаторов, разработчиков, управленцев, да и просто фанатов тестирования. Ждем вас!

Возможно, вас заинтересуют материалы по автоматизации тестирования.
Видеозаписи с Гейзенбаг 2016 Moscow, а также интервью с Никитой Макаровым на тему Тестирование: простая дорожка в IT или серьезная затея?

Основные положения тестирования / Habr

Области применения, цели и задачи тестирования ПО разнообразны, поэтому тестирование оценивается и объясняется по-разному. Иногда и самим тестировщикам бывает сложно объяснить, что такое тестирование ПО ‘as is’. Возникает путаница.

Для распутывания этой путаницы Алексей Баранцев (практик, тренер и консалтер в тестировании ПО; выходец из Института системного программирования Российской академии наук) предваряет свои тренинги по тестированию вводным видео про основные положения тестирования.

Мне кажется, что в этом докладе лектор смог наиболее адекватно и взвешенно объяснить «что такое тестирование» с точки зрения ученого и программиста. Странно, что этот текст еще не появлялся на хабре.

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

Основные положения тестирования

Уважаемые коллеги,

сначала попробуем понять, чем тестирование НЕ является.

Тестирование не разработка,

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

Тем не менее, тестирование — это не деятельность по разработке программного обеспечения.

Тестирование не анализ,

и не деятельность по сбору и анализу требований.

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

Тестирование не управление,

несмотря на то, что во многих организациях есть такая роль, как «тест-менеджер». Конечно же, тестировщиками надо управлять. Но само по себе тестирование управлением не является.

Тестирование не техписательство,

однако тестировщикам приходится документировать свои тесты и свою работу.

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

Деятельность значима только тогда, когда она востребована, то есть тестировщики должны что-то производить «на экспорт». Что они делают «на экспорт»?

Дефекты, описания дефектов, или отчеты о тестировании? Частично это правда.

Но это не вся правда.

Главная деятельность тестировщиков

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

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

Но эта вещь очень значимая, и, наверное, единственная наиболее значимая составляющая деятельности тестировщиков.

Существует наука — «теория систем». В ней определяется такое понятие как «обратная связь».

«Обратная связь» это некоторые данные, которые с выхода попадают обратно на вход, или какая-то часть данных, которые с выхода попадают обратно на вход. Эта обратная связь может быть положительной и отрицательной.

И та, и другая разновидности обратной связи равноценно важны.

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

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

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

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

Синонимы термина «тестирование»

С точки зрения того, что тестирование — это предоставление отрицательной обратной связи, всемирно известная аббревиатура QA (англ. Quality Assurance — Обеспечение качества) синонимом термина «тестирование» уж совершенно точно НЕ является.

Нельзя считать обеспечением качества простое предоставление отрицательной обратной связи, ведь Обеспечение — это некоторые позитивные меры. Подразумевается, что в этом случае мы именно обеспечиваем качество, своевременно предпринимаем какие-то меры для того, чтобы качество разработки ПО повысилось.

А вот «контроль качества» — Quality Control, можно считать в широком смысле синонимом для термина «тестирование», потому что контроль качества это и есть предоставление обратной связи в самых разных ее разновидностях, на самых разных этапах программного проекта.

Иногда тестирование подразумевается как некоторая отдельная форма контроля качества.

Путаница приходит из истории развития тестирования. В разное время под термином «тестирование» подразумевались различные действия, которые можно разделить на 2 больших класса: внешние и внутренние.

Внешние определения

Определения, которые в разное время дали Майерс, Бейзер, Канер, описывают тестирование как раз с точки зрения его ВНЕШНЕЙ значимости. То есть, с их точки зрения, тестирование — это деятельность, которая предназначена ДЛЯ чего-то, а не состоит из чего-то. Все три этих определения можно обобщить как предоставление отрицательной обратной связи.

Внутренние определения

Это определения, которые приведены в стандарт терминологии, используемой в программной инженерии, например, в стандарт де-факто, который называется SWEBOK.

Такие определения конструктивно объясняют, ЧТО представляет из себя деятельность по тестированию, но не дают ни малейшего представления о том, ДЛЯ ЧЕГО нужно тестирование, для чего потом будут использоваться все полученные результаты проверки соответствия между реальным поведением программы и ее ожидаемым поведением.

Итак,

тестирование — это

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

Отсюда и далее будем считать это рабочим определением «тестирования».

Общая схема тестирования примерно следующая:

1. Тестировщик на входе получает программу и/или требования.
2. Он с ними что-то делает, наблюдает за работой программы в определенных, искуственно созданных им ситуациях.
3. На выходе он получает информацию о соответствиях и несоответствиях.
4. Далее эта информация используется для того, чтобы улучшить уже существующую программу. Либо для того, чтобы изменить требования к еще только разрабатываемой программе.

Что такое тест

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

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

Разработчик тестов занимается тем, что он из огромного потенциально бесконечного набора тестов выбирает некоторый ограниченный набор.

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

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

2.И, во-вторых, он наблюдает за поведением программы и сравнивает то, что он видит с тем, что ожидается.

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

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

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• пользовательский,
• графический,
• текстовый,
• консольный,
• и речевой.

Используя все эти интерфейсы, тестировщик:

• каким-то образом создает искусственные ситуации,
• и проверяет в этих ситуациях как программа себя ведет.

Вот это и есть тестирование.

Другие классификации видов тестирования

Чаще всего используется разбиение на три уровня, это

1. модульное тестирование,
2. интеграционное тестирование,
3. системное тестирование.

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

Под системным тестированием подразумевается тестирование на уровне пользовательского интерфейса.

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

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

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

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

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

Комбинируем:

То есть, можно говорить о модульном тестировании функциональности.

Можно говорить о системном тестировании функциональности.

Можно говорить о модульном тестировании, например, эффективности.

Можно говорить о системном тестировании эффективности.

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

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

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

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

Классификацию по целям удобно выполнять с использованием «магического квадрата», который был изначально придуман Брайаном Мариком и потом улучшен Эри Тенненом.

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

По вертикали — чем выше располагается вид тестирования, тем больше внимания уделяется некоторым внешним проявлениям поведения программы, чем ниже он находится, тем больше мы внимания уделяем ее внутреннему технологическому устройству программы.

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

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

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

Так вот, исходя из классификации по целям, модульное тестирование у нас оказывается в левом нижнем квадранте, а все остальные квадранты — это системное тестирование.

Спасибо за внимание.

Дополнительно

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

Как в действительности выглядит работа тестировщика игр (Часть 1) / Habr

Старый видеролик с рекламой колледжа Уэствуд стал чем-то вроде шутки в мире видеоигр. Два парня, с комфортом устроившись на диване, убивают в хлам контроллеры, увлеченно играя на Sony PlayStation. Входит девушка и говорит: «Эй, ребята, вы уже закончили тестировать эту игру? У меня тут еще одна».

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

Именно так на протяжение долгого времени люди представляли себе жизнь тех, кто занимается тестированием компьютерных игр – не как работу по 5-9 часов в день, а как мечту всех подростков. Кто бы не хотел сидеть на комфортном диване и целый день играть в игры с небольшими перерывами на «подтягивание» графики в третьем уровне?

Реальность немного отличается от этой картины. Так называемая проверка качества компьютерных игр (QA), то есть их тестирование (здесь и далее автор смешивает в кучу составляющие процесса – тестирование (базовый уровень), контроль качества и обеспечение качества – прим. переводчика), часто воспринимается как «играешь в игры, и тебе еще за это платят», но на самом деле это можно было бы лучше описать как процесс «ломания» игр. Это низкооплачиваемая, редко приносящая удовлетворение и часто разочаровывающая работа, которая влияет – так или иначе – на качество современных игр, но не так, как вы бы могли того ожидать.

Профессиональный тестировщик не просто сидит перед телевизором и, попивая какой-нибудь энергетик наподобие Red Bull, проходит пятый уровень последнего шутера. Он (или она) проводит по 14 часов кряду, атакуя стены в этих уровнях для того, чтобы проверить их целостность. Хорошее тестирование видеоигр больше похоже на решение головоломки, чем на набивание нового рекорда в Donkey Kong, что бы нам ни показывали в рекламных роликах. «Для того чтобы хорошо выполнять работу в QA-мире, необходимы специфический подход и особое отношение к жизни», – сказал мне опытный тестировщик компьютерных игр. «Это выходит за рамки страсти к видеоиграм и уж точно не совпадает с представлениями о том, что ты играешь в видеоигры и получаешь за это зарплату».

Обычно тестировщиков недооценивают, вспоминая о них лишь тогда, когда что-то идет не так. QA-профессионалы утверждают, что работа эта скучная, напряженная и часто рассматривается как возможность пробраться в другие области разработки игр, нежели более традиционный карьерный путь. Часто тестировщики работают по временным контрактам или для аутсорсинговых компаний, которые препятствуют их прямому общению с разработчиками игр. И когда в игре особенно много багов или она вообще выходит в свет в сыром, практически неиграбельном виде – как многие из последних релизов – то обычно все винят в этом тестировщиков. Они же, кроме всего прочего, и те, кто должен гарантировать защиту, будучи последней стеной между ошибками программистов и деньгами покупателей. Всю суть передает название процесса: обеспечение качества (Quality Assurance). Иными словами, тестировщики должны обеспечить качество продукта.

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

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

Сколько существуют игры, столько в них живут и баги. Некоторые относительно безобидны и даже стали легендарными, как загадочный MissingNo в Покемонах. Другие же вошли в историю видеоигр: бесконечные уровни Minus World в игрушке Super Mario Bros., в который можно попасть, пройдя сквозь стену. Но неутомимые участники игрового сообщества не сидят на месте: новые баги постоянно находятся и поносятся, а также веселят игроков – глюков в Legend of Zelda: Ocarina of Time, например, хватило на 17-минутное забавное видео!

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

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

Давайте для примера возьмем Grand Theft Auto V. В огромном открытом мире, созданном разработчиками из Rockstar Games, тестировщикам приходилось разделять и властвовать. «Во время тестов разные люди занимались определенными миссиями или задачами, мини-играми и т.д.», – говорит человек, который помогал тестировать игру. «Обычно работа шла от общего к частному. Сначала ты проходишь основные миссии по порядку, потом идут кражи, затем дополнительные миссии и проверка различных персонажей, затем ты продвигаешься к тестированию стриптиз-клуба и проституток».

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

«Я думаю, что такая работа над проектами делает их гораздо лучше благодаря тому, что мы находим такие моменты, когда происходит что-то действительно дурацкое», – сказал тестировщик. «Мы нашли множество багов: говорящие свиньи, то и дело по-человечески встающие на задние ноги и уходящие прочь, простые прохожие, которые неожиданно стремительно взлетают ввысь. Тревор, сняв штаны, так и не удосуживался их одеть обратно – всю оставшуюся игру он бегал с болтающимися где-то внизу брюками. Собака Франклина погибала, едва прикоснувшись к воде… пес просто падал в пруд и камнем шел на дно, стоило ему только намочить лапы».

Найти баги – это только первый шаг. Второй, и куда более сложный – это попытаться воспроизвести глюки, чтобы инженеры компании могли их исправить. Тестировщик не может просто написать что-то вроде «с Тревора спадают штаны» и отправить это команде программистов. Что могут инженеры сделать с подобной информацией? Для того, чтобы найти, выделить и исправить баг, программистом нужно знать, как именно это произошло, что может быть нелегкой головоломкой, если учесть огромное количество различных факторов в видеоиграх. Хорошие тестировщики быстро учатся запоминать каждое свое действие – значительное и мелкое – так что они могут хотя бы попробовать воспроизвести любой встреченный ими баг. «Мне нравиться, что работа тестировщика похожа на оплачиваемое решение головоломок», – говорит Роб Ходжсон (Rob Hodgson), опытный тестировщик с 8-летним опытом. «Для некоторых людей попытки воспроизвести шаг за шагом какую-нибудь странную ошибку, которая была найдена ранее, могут быть захватывающими».

Обычные рабочие дни тестировщика могут значительно изменяться в зависимости от проекта, роли и позиции в компании. Так, человек, получивший работу через аутсорсинговую компанию, может провести 10 часов, врезаясь в каждую стену в последней версии Call of Duty, чтобы выяснить, где конструкцию можно пробить (эдакий «ударный тест»). Штатный сотрудник, который занимается тестами, может работать с программистом, пытаясь разобраться, отчего в их мобильной игре уменьшается частота кадров на версии для Android. Непостоянная и, как правило, монотонная по своей природе работа в сфере QA может нести в себе некоторые неожиданные испытания. Например, тестировщики, работавшие над музыкальной игрой Rock Band, говорили, что звуки, выдаваемые «пластмассовыми» барабанами, до такой степени приводили их в бешенство, что им пришлось установить правило: никаких инструментов по вторникам и четвергам.

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

Когда игра на консоль практически завершена, она должна пройти сертификацию – процесс, при котором издатель (EA, к примеру) попросит у производителя консолей (Sony, Microsoft или Nintendo) проверить игру на наличие серьезных багов. Во время этого процесса сертификации вторая волна QA-персонала (ребят называют «тестировщики на соответствие») проходятся по ней еще раз, проверяя, все ли соответствует ожиданиям. У каждого производителя консолей есть свой список, в котором описаны все требования – от сообщений об ошибках до достижений, и если игра не соответствует какому-либо элементу, то издателю придется ее исправить и попробовать пройти сертификацию к снова – к черту все дедлайны! «Microsoft требует от всех игр, чтобы они имели возможность перехода в меню Xbox 360 из любого места в игре», – сказал один тестер, который работал для крупного издателя игр, проверяя их на соответствие требованиям. «По правилам Sony, в играх не должно быть возможности пропустить экраны с заставками студии/издателя в начале игры при первом просмотре. Nintendo не хочет нецензурной лексики в своих играх, поэтому все тексты имеют фильтры, которые мы проверяем и пытаемся поломать».

«Я не играл в BioShock Infinite по меньшей мере два года после релиза», – недавно сказал мне один бывший тестировщик. Он работал для компании 2K и много времени потратил на тестирование этой игры, он остался разочарован тем, во что в итоге превратился продукт, который, как он заметил, недостоин оригинальной версии.

«Единственное, что снова заставило меня играть в игру – это наблюдение за скоростным прохождением BioShock. Мы провели множество ночей за быстрым прохождением игры. Интересно увидеть, что игроки делают, чтобы урезать уровни».

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

«Я взбесился, потому что они используют баг, чтобы выбраться из уровня и автоматически продвинуться вперед. Я ДОЛЖЕН БЫЛ НАЙТИ ЭТОТ ГЛЮК!» – написал мне тестировщик по мылу.

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

Это выражается также и в низких зарплатах. Такая работа не имеет высоких требований – обычно для того, чтобы получить позицию тестировщика начального уровня, не нужно обладать опытом или дипломом. В то же время многие хотят заполучить эту работу, оттого и зарплаты средние. В 2014 году были опубликованы результаты исследования по зарплатам среднестатистического начинающего тестировщика. Оказалось, что годовой оклад такого работника составил около 55 тыс. долларов (судя по всему, это зарплата до вычета налогов – прим. переводчика), но это зарплата штатных сотрудников, в то время как большинство тестировщиков – контрактники, работающие либо напрямую с разработчиком, либо на компании, которые принимают заказы на тесты от множества издателей. Многие из этих контрактников говорили мне, что их зарплаты варьируются от 10 до 15 долларов за час – это в среднем 21-30 тыс. долларов в год.

Также тестировщики говорят, что на рабочем месте они ощущают неуважение к себе. Многим из них (особенно контрактникам) запрещено напрямую общаться с разработчиками, и все общение осуществляется исключительно посредством письменных рапортов о выявленных багах. «Это было чем-то вроде неписанного правила – нам нельзя было напрямую контактировать с разработчиками», – сказал мне один тестировщик. – Вся коммуникация обычно осуществлялась через QA-лидов. Все общение с разработчиками сводилось к комментариям в базе данных об ошибках, что нельзя назвать идеальной формой взаимодействия, при которой легко неверно интерпретировать комментарий/вопрос разработчика об ошибке как колкость или раздраженное замечание».

Так не в каждой студии: «Когда вы предоставляете тестировщикам льготы, возможность служебного роста, уважение и отсутствие боязни увольнения, то это притягивает нужных людей», – говорит Ариэль Смит (Ariel Smith), которая занимается тестированием MMO-игр в студии Cryptic. Она рассказала мне, что любит свою работу, но неуважение к тестировщикам действительно стало модным. Несколько тестеров сказали мне, что им приходится пользоваться боковыми входами, чтобы войти в офисы, где они работают, и что им запрещено общаться с другими сотрудниками. Другие говорят, что разработчики часто издеваются над ними в той или иной степени. Например, известна одна ситуация, когда инженер по качеству исправлял очередной баг, что не мешало ему постоянно отправлять тестировщику сообщение наподобие «Невозможно воспроизвести». В типичной студии тестеров считают самым нижним слоем иерархии. Отчасти это из-за природы работы – тестировщик показывает другим, где те напортачили. Это всегда задевает чье-то самолюбие.

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

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

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

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

«Мне нравилось заниматься тестированием, и я бы повторил это снова, если бы потребовалось», – говорит Обед Навас (Obed Navas), бывший тестер, который работал над такими тайтлами, как BioShock и Call of Duty. «Несмотря на то, что тестировщик – это не самое гламурное звание, и с такой работой ты рискуешь потерять всякий интерес к видеоиграм в нерабочее время, в конце концов возможность увидеть свое имя в титрах дорогого стоит. Также круто иметь какие-то связанные с проектами вещи, которые нигде нельзя достать, и на вопросы знакомых о том, где я их взял, с гордостью отвечать «Я работал над этой игрой».

Вторая часть здесь.

P.S. Сами работаете тестировщиком? Согласны с мнением автора оригинальной статьи? Расскажите нам, пожалуйста, о своей работе, ее плюсах и минусах – так, как видите это вы.

Тестировщики — роль второго плана? / Habr

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

• На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
• Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
• Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
• За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

Давайте экономить на зарплате

Здесь всё понятно. Чтобы проект приносил больше прибыли, его надо лучше продавать и сокращать производственные затраты.
ОК, давайте наймём недорогого специалиста по тестированию (чаще всего, студента или свежего выпускника), который будет тыкать на кнопки и регистрировать ошибки в систему. Когда объёмы работы вырастут, и он перестанет справляться — наймём второго, и постепенно выстроим целый отдел тестирования. На первый взгляд всё кажется вполне хорошо, если бы не некоторые мелочи:

• Неквалифицированные тестировщики заводят баги без детального анализа. Такие ошибки сложно локализовывать и исправлять. Допустим, на каждую из 50 заводимых в неделю ошибок разработчики в среднем тратят лишние 15 минут на анализ. Сущие незаметные мелочи! Всего-то, 600 человекочасов разработчиков в год — или 3,5 человекомесяца!
• Со временем, когда у вас разрастается объём поддерживаемого кода, вам требуется регулярное регрессионное тестирование, дабы проверить, что ничего не сломалось. Ваши студенты-тестировщики целенаправленно и методично выполняют одни и те же тесты от релиза к релизу, изредка находя ошибки (привет, эффект пестицида!) Когда кому-то в голову (чаще всего, РМ’у) придёт идея об автоматизации, эти ребята напишут вам несколько сотен скриптов копипастом — и потом, вместо ручного тестирования, будут каждый релиз обновлять автотесты. В какой-то момент, чтобы всё это счастье поддерживать, вам потребуется больше тестировщиков: что-то между много и очень много. А много это всегда дорого.
• В конце концов, несмотря на рост численности тестировщиков, вы будете сталкиваться с ошибками на продуктивной среде. Ругаться с пользователями, терять доверие, тратить своё время. В общем, вы продолжите тратить избыточные ресурсы.

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

Тестировщиков не надо пускать к продукту слишком рано

«Вот сейчас мы напишем достойную тестирования версию, и им останется только проверить, что всё хорошо, и завести найденные мелочи!»
Здесь, почему-то, опять начинаются проблемы:

• Поздно подключаясь к процессу, тестировщики не успевают вникнуть в среду. Не хватает понимания бизнес-сценариев, среды работы пользователей, и причин принятия многих проектных, архитектурных и дизайнерскиих, решений. Примерно на этом этапе начинаются «тёрки» из-за разного видения, как и что должно быть реализовано, т.к. тестировщикам либо не хватает знаний, либо у них другое видение, но они не участвовали в разработке проектных решений. Поздравляю, много изменилось: у вас опять невысококачественное тестирование, взаимное недовольство, нехватка времени на серьёзные изменения в продукте.
• Проведя долгое время на вашем проекте (что многие адекватные тестировщики просто не будут делать в таких условиях), тестеры начинают понимать среду значительно лучше. Шансы успеха растут, если они участвуют в разработке требований и общении с клиентами. Но вы продолжаете подключать тестирование на последних этапах, потому что так принято? Скорее всего, вас ждёт одно из двух: при нехватке времени на тестирование будут пропускаться ошибки. При возможности подвинуть сроки вам просто придётся вносить слишком много серьёзных изменений. Конечно, это всего лишь багфикс, это нормально… Пока не задуматься о простом: а как его можно было избежать, тем более на последних стадиях релиза?

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

Тестировщики не могут влиять на качество продукта

При наличии должных сил и желаний, тестировщики могут его оценить. При достатке коммуникативных навыков — обосновать важность тех или иных изменений. Но повлиять на результат?
Медицине пока не известны случаи, чтобы аппарат УЗИ что-либо вылечил, а тестирование — это лишь диагностика. И на этом этапе, если в вашей команде тестирования ещё есть достаточно грамотные и незабитые сотрудники, начинаются новые «тёрки»:

• Для более грамотной автоматизации, в продукте нужны легко поддерживаемые локаторы — пфффф! «Опять тратить лишнее время на тестирование!», — скажет РМ, и отложит задачу до тех никогда-не-наступающих-времён-когда-команде-будет-нечего-делать.
• Чтобы точнее оценивать тестовое покрытие и его слабые зоны, нам нужны детализированные декомпозированные требования — пфффф! «Хватит разводить бюрократию, у нас аджайл!»
• Нам нужно лучше понимать пользователей и привлекать целевую аудиторию на этапе проработки бизнес-сценариев, оценивать юзабилити — пффффф! «Это отложит релиз на 2 недели, лучше потом переделаем по отзывам пользователей!»

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

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

Выводы

Срезюмирую:

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

Всё ещё редко, но в ex-СССР начинают встречаться толковые процессы обеспечения качества. А вы готовы менять что-то в лучшую сторону?

Чем отличаются настоящие тестировщики от поддельных? / Habr

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

Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

Первой праведной мыслью было: тестирование обидели!

На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?

Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.

1. Настоящие тестировщики с проектом заодно.

Настоящие тестировщики не враги программистам. Настоящие тестировщики не ставят своей целью «сломать продукт», после чего ехидно потирать ладоши. Настоящие тестировщики вообще не радуются наличию проблем, багов, дефектов и ошибок!

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

А для этого нужно:
* учитывать цели проекта
* адаптироваться под внешние условия (приоритеты, сроки, цели, верхнеуровневые задачи)
* уметь выяснять: ЧТО нужно сделать СЕЙЧАС, чтобы помочь проекту достигнуть цели?

Если тестирование неэффективно, ошибки находятся поздно, а заводятся низкокачественно, то их будет больше и больше: плохая локализация дефектов отнимает время у разработчиков, а их заведение в неприоритетном порядке ведёт к трудностям в исправлении.

Поэтому, вместо задачи «как бы мне найти кучу багов и заDDOSить разработчиков», настоящие тестировщики думают: «Что сейчас нужно проекту, в каком формате и с какими приоритетами?».

2. Настоящие тестировщики умеют проектировать тесты.

Никакого манкикликинга и быдлотестинга!
Настоящие тестировщики умеют проектировать тесты. Для этого они как минимум зазубрили библию проектирования тестов от Lee Copeland’a, а как максимум — освоили контроль рисков качества.
В зависимости от условий, тестирование может проводиться эксплоративно или по тест-кейсам, но тесты делаются не от балды «понажимаю-ка я кнопочки», а только по результатам анализа: что нужно тестировать, в каком приоритете и каким образом это можно сделать наиболее эффективно?
Для этого любое тестирование начинается с исследования продукта, влияющих на его работу факторов, и их последующего разбиения на классы эквивалентности.

Сначала — думать, потом — тестировать!

3. Настоящие тестировщики понимают архитектуру тестируемого ПО.

Чтобы быть настоящим тестировщиком, вовсе не обязательно быть продвинутым разработчиком. Но для понимания того, как эффективно тестировать ваше приложение, вы просто обязаны знать его архитектуру!
Black-box testing не позволяет детально происследовать продукт, и тестирование только «со стороны пользователя» приводит к тому, что неучтёнными оказываются многие влияющие на работу ПО факторы.
Black-box testing — это тестирование в чёрном ящике без окон и с закрытыми глазами. Вы идёте наощупь, натыкаетесь на какие-то шероховатости в продукте, и заводите на это ошибки «где-то в левом углу что-то не так».
Откройте глаза и включите свет! Посмотрите, что вы тестируете!

Узнав, как работает ПО, вы сможете:
* эффективнее проектировать тесты
* обеспечивать более высокое покрытие, зная влияющие на работу ПО факторы
* точнее и грамотнее локализовывать ошибки — а значит, экономить время разработчиков и проекта в целом!

4. Настоящие тестировщики — мастера коммуникаций.

Кому, как не тестировщикам, приходится нести плохую весть? Самое худшее, что можно сделать, обнаружив дефект — сказать разработчику «Ну ты и накосячил!».
Нам надо не просто найти и зарегистрировать дефект. Нам надо сделать всё для того, чтобы его было легко и приятно исправить.
Каждый исправленный в софте недочёт — это классно, и любой разработчик это понимает.
Только если предварительно ему не сказали, что он «косячит», «бажит» и «глючит»!

О том, как коммуницировать с разработчиками на предмет дефектов — запись выступления Алексея Баранцева на встрече Московского Клуба Тестировщиков.

5. Настоящие тестировщики прекрасно разбираются в прикладной области.

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

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

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

6. Настоящие тестировщики не бывают экспертами.

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

С неумолимой скоростью появляются новые техники и подходы. Продвинутые тестировщики всех направлений создают её, создают прямо сейчас!

А как можно быть экспертом в области, которая пока что не сформировалась? Которая слишком гибка, чтобы в ней можно было что-то назвать «правильным»?

«Я эксперт!» = «Я больше не буду развиваться». А это НЕ про настоящих тестировщиков.

7. Настоящие тестировщики выбирают цели, а не средства.

Как часто автоматизируются тесты с отрицательным ROI просто потому, что автоматизация — это «круто», а ручное тестирование — это «скучно»? Как часто тесты документируются, превращаясь в ворох бесполезных и неповоротливых бумажек, просто потому, что это «солидно»?

В тестировании (как, наверное, и в других областях?) многие решения принимаются исходя из «круто», «интересно» и «а давайте попробуем?».

Но ведь понятие «крутости» не абсолютно! В каждом проекте, в каждой команде свои условия работы, и эффективное тестирование всегда определяется контекстом!

Когда настоящие тестировщики принимают решение что-либо внедрить, они говорят: «Нашему проекту это будет полезно, потому что …». И эти слова отличают настоящего тестировщика от поддельного больше, чем что бы то ни было ещё.

8,9,10. Настоящие тестировщики любят свою работу, любят свои продукты и непрерывно развиваются.

Для соответствия десяти задекларированным пунктам, вкратце освещу ещё три:
* Настоящие тестировщики ЛЮБЯТ свою работу, всегда находят в ней творчество, и у них не может быть рутины! Потому что каждая новая задача выполняется лучше, качественнее, эффективнее — а значит, интереснее и интереснее!
* Настоящие тестировщики любят свои продукты. Невозможно тестировать софт и быть деструктивистом. Задача настоящего тестировщика — сокращать количество дефектов, принимать превентивные меры, проводить тестирование на ранних стадиях, так чтобы серьёзные дефекты и не появлялись вовсе. А эти цели несовместимы с деструктивизимом, для их достижения продукт надо не ломать, а любить.
* Настоящие тестировщики непрерывно развиваются. И развивают молодую неокрепшую отрасль!

Выводы

Настоящие Тестировщики сделают выводы сами 🙂

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