Обучение тестированию

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

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

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

Для чего нужны метрики?

1. Оценка прогресса. Если перед нами стоит какая-то задача, которую невозможно выполнить здесь и сейчас, нам нужен инструмент оценки, чтобы понять, ведут ли наши действия к ожидаемому результату?

Допустим, вам повезло, и выдумыванием целей заниматься не нужно. Руководитель проекта ставит задачу: надо проводить тестирование сборки не более, чем за 3 дня, чтобы мы могли своевременно выдавать новые версии заказчику. Вы считаете текущее положение дел - сборка тестируется 6 дней. Что делать? Оптимизация тестовых наборов, автотесты, расширение штата, аутсорс Разобрав все возможные решения в команде, вы выбираете путь тотальной автоматизации, и усиленно работаете в этом направлении. Через полгода приходит раздосадованный РМ, машет руками и кричит Что за фигня?!. Вы смотрите, сколько в среднем уходило последние релизы на тестирование - 8 дней. Как так??

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

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

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

В таком случае мы ищем косвенные процессные метрики, которые будут вести нас к повышению оценок. Читаем отзывы и выясняем, за что снижены оценки. Находим три лидера по упоминаниям среди жалоб: падения на нестандартных окружениях, медленная скорость работы, нехватка запрошенных фич. Отлично, с этим уже значительно понятнее, как работать, чем с абстрактной оценкой нравится/не нравится! Мы можем выбрать метрики, которые помогут нам оценить свою работу (покрытие тестами на разных окружениях, проведение тестов производительности), так и общепроектные метрики: скорость работы и готовность запрошенных фич. Таким образом мы поможем и самим себе, чётко отслеживая рост требуемого тестового покрытия, и другим участникам команды, сразу показав, чего не хватает для релиза. До выпуска полгода, а поднять число тестовых окружений на 6% я уже могу сегодня!

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

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

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

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

Допустим, вы приходите к руководству со стандартным списком жалоб: ресурсов не хватает, времени слишком мало, требований нет, код отстой. Скажите ему это, и он будет отмахиваться от вас всеми доступными способами.

Хотите получить результат вместо отмашек? Придите с метриками. Покажите, что экономия ресурсов тестирования в 2000$ обходится проекту в 9000$ на штрафах по договору. Проиллюстрируйте, как экономия недели в начале релиза на написание требований ведёт к задержке релиза в три недели из-за разного понимания ожиданий. Такая беседа всегда будет конструктивнее и результативнее пустой болтовни, не подтверждённой измеримыми показателями!

Метрики: как выбрать и внедрить

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

1. Согласуйте ожидания руководства, зафиксируйте, а потом уже думайте: какими показателями можно оценить именно эту цель?

2. Вы хотите что-то улучшить в своей работе. Что именно? Определившись, какой результат вы хотите достигнуть, подумайте о его измерении:

   2.1. Как оценивать прогресс в достижении этого показателя?

   2.2. Как измерять достижения на уровне процесса, пока ключевой показатель, возможно, не меняется?

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

   3.1. Как оценивать эту проблему, в чём её можно измерить?

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

   3.3. Как можно обнаружить корень этой проблемы, или узкое горлышко?

4. Вам надо обосновать что-то своему руководству, и вы исчерпали аргументы:

   4.1. как проиллюстрировать наличие проблемы?

   4.2. как показать пользу от предлагаемого вами решения?

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

• срывы сроков (для обработки жалобы от РМа)

• причины срыва сроков (чтобы найти решения проблеме)

• низкое качество тестирования (для решения жалоб от техподдержки)

• низкое качество кода (чтобы конструктивно пожаловаться руководителю разработки)

• отчётность для РМа по качеству продукта (по которой он сможет принимать взвешенные решения)

• и т.д.

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

Примеры метрик в тестировании с описанием вариантов их использования

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

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

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

Всем качественных продуктов, растущих показателей и зрелых процессов!

10 лет назад далеко не все ВУЗы готовили разработчиков для рынка. Я училась как раз там, где было все хорошо с базой, но плохо с современными технологиями, и по окончании не смогла найти себя в ИТ. Почти 10 лет меня мучил вопрос - а не вернуться ли? Не выйдет ли из меня хорошего тестировщика?

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

ИТ-шник вне ИТ

Сразу оговорюсь, мой рассказ - вовсе не история о том, как начать тестировать, не имея базы. Чуть больше 10 лет назад я закончила факультет прикладной математики и информатики Воронежского государственного университета по специальности математик-программист, так что база была. Но честно говоря, даже сразу по окончании ВУЗа я понимала, что полученные знания сильно отстали от реальных потребностей отрасли. Плюс тестирование уже тогда привлекало меня гораздо больше, в отличие от разработки.

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

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

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

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

Дообучение на тестировщика

Все изменилось, когда я действительно ушла в декрет. У меня появилось время, чтобы изучать новое - я обложилась книгами Савина, Куликова и других, начала проходить бесплатные курсы, смотреть отдельные лекции на YouTube. Пробовала даже читать исследовательские туры Уиттакера в оригинале (у книги нет русского перевода) и Как тестируют в Google. Мне понравилось.

К началу 2020 года, когда ребенок уже подрос, я начала искать работу в тестировании.

Кто знает, как бы все сложилось, если бы не коронавирус. Планируя выйти на работу, я рассчитывала, что с маленьким ребенком будут сидеть мои родители. Но из-за COVID-19 не рискнула перевозить их из деревни в город. Так что выйти на полный день даже на удаленку я уже не могла.

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

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

Первые собеседования в новом статусе

Честно скажу, до последнего меня преследовал синдром самозванца. Несмотря на базу в ИТ из ВУЗа, мне все казалось, что я знаю недостаточно, чтобы претендовать даже на позицию джуна. Ну и возраст уже не тот, чтобы кардинально менять работу. Когда джун приходит после ВУЗа, все на это нормально смотрят. А когда тетя за 30 после декрета? Не поздновато-ли?

Но тут помогло сообщество. Я пообщалась в чатах с теми, кто успешно проходит собеседования, и поняла, что по многим вопросам знаю даже больше. И среди новичков в тестировании полно людей старше меня. Зачем к себе придираться? Найти свое призвание никогда не поздно! Если другие устраиваются на работу, то почему я не могу?

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

Период пандемии дал мне время на то, чтобы лучше присмотреться к собеседованиям. Еще до COVID-19 я успела пройти несколько собеседований, но не получила оффера. Проанализировав свои неудачи, я поняла несколько моментов.

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

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

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

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

Автор: Наталья Шилова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.