QA-инженер: неизвестный герой качественного ПО
Недавно услышала мнение, что тестировщику достаточно уметь быстро нажимать на кнопки. Хм! В этой статье я попробую развеять миф об инженере-тестировщике, как об обезьянке с шаловливыми конечностями.
Что значит быть тестировщиком?
Самая важная черта инженера — чувство ответственности, а у инженера по тестированию это чувство должно быть обостренно вдвойне.
О навыках, без которых, на мой взгляд, инженеру по тестированию будет нелегко:
- Умение правильно организовать работу. Для этого требуется некоторый план тестирования и минимальный расчет рисков для верной оценки затрат времени и сил. Нужно уметь планировать так, чтобы максимально с пользой потратить выделенные на тестирование часы.
- Умение сосредоточится в режиме многозадачности. Поскольку инженер по тестированию ресурс разделяемый и может участвовать не только в одном проекте, то достаточно сложно держать в голове все нюансы по всем задачам всех проектов.
- Умение донести свою мысль. При описании замечания в багтрекере — это самое важное. Нужно не просто указать ошибку, а доступно объяснить, как ее воспроизвести и написать порядок пошаговых действий для воспроизведения.
Помимо этих трех есть множество и других важных навыков, но все они сольются в песок без дисциплины самого QA инженера.
С чего начинается тестирование проекта?
Инженер по тестированию ПО должен понимать предназначение и хорошо знать основную функциональность проекта. Помогает в этом вводная беседа с менеджером проекта и спецификация, если таковая имеет место быть.
Далее просматриваются и проверяются готовые задачи. Здесь важно отделять мух от котлет. Поскольку тестировщик подключается к проекту, который еще в процессе разработки, то сложно удержаться от создания лжебагов из-за сырого функционала.
Заканчивается тестирование полным регрессом всех модулей проекта. Здесь повторно прогоняется то, что уже правилось и не единожды проверялось. Это и функциональность всех модулей, и адаптация верстки, и стресс-тестирование.
Если последний этап тестирования прошел без замечаний, то разработку проекта можно считать успешно завершенной.
Какое оно, некнижное тестирование проекта?
Читая книги по тестированию, можно подумать, что процесс этот неспешный, детально распланированный и просчитанный по мелочам. В книгах изображены красивые графики, митинги улыбчивой команды, представлены таблицы и диаграммы.
Други мои! Реальное тестирование проекта далеко от книжного, описанного моими коллегами. Если вы работаете в компании, где полтора тестировщика и проектов на вас более чем достаточно, то добро пожаловать в ряды сурового тестинга.
Немного правды о тестировании
Если у вас более двух проектов, то вам не до раскрашивания графиков и не до составления красивых диаграмм с таблицами. Вы будете работать, запоминая и удерживая в голове или на бумаге всё по своим проектам. Безусловно, таблицы и планы не пустой, а нужный и удобный материал. Но из-за сжатых сроков полностью отдаешься проекту, и на оформление результатов уже не хватает времени. Результаты обговариваются на митингах, фиксируются в багтрекере и в письменных отчетах менеджеру.
Режим многозадачности включен всегда.
Тестировщики тоже плачут...
Главная беда тестировщика — это «эффект пестицида». Другими словами «замыливание глаза», тут велика вероятность пропуска ошибки. Бороться с этим можно подключением стороннего тестировщика к проекту или созданием фокус-группы. Но если предложенные варианты нереальны, то только один совет — сделать перерыв и со свежим взглядом продолжить работу.
Вторая беда тестировщика — это организация рабочего времени. Когда нужно просмотреть множество устройств, а за спиной сверлят взглядом менеджеры других проектов, то возникает легкая паника. Расставить приоритеты — это забота менеджеров, забота тестировщика максимально уложится в отведенные ему сроки и вовремя сигнализировать о проблемах.
И вот тут выплывает третья беда тестировщика — хроническая нехватка времени. Здесь только жесткое планирование и больше ничего. Ну, а если уж совсем загнали в угол сроками, то нужно просить помощи у команды. Помним, что за качество отвечает вся команда, а не только инженер по тестированию! Смотрим один из тезисов в рецензии по гибкому тестированию.
И самая неприятная проблема в тестировании — неполное оформление задачи. Кто работает в сфере тестирования, тот наверняка сталкивался с различием между реализацией и постановкой задачи. А по выяснению оказывается, что просто забыли уведомить и зафиксировать изменения. Здесь нужно каждый раз напоминать , чтобы не ленились малейшие изменения указывать письменно. Дать понять, что грамотное оформление задачи экономит нервы и время всех членов команды..
Что же мы делаем для облегчения нелегкой участи востребованного тестера:
- Мы ввели чек-лист для тестировщика. Его заполняет менеджер проекта, указывая всю необходимую информацию. Это позволило лишний раз не обращаться с вопросами, что чувствительно экономит время.
- Все задачи по проекту проходят через багтреккер. Это не ново, и каждый уважающий себя инженер умеет им пользоваться.Очень удобно, если грамотно его вести.
- Мы разработали единый шаблон оформления багов. Это позволит не упускать детали в описании ошибки.
- Для некоторых проектов пишется краткий отчет, где проставлены результаты тестирования. Отлично для самопроверки и для будущей работы с проектом.
- Мы написали немало чит-листов по проверке основного функционала, как для web, так и для мобильных приложений. Это систематизирует тестирование и неплохо экономит время.
- Мы работаем над оптимизацией плана тестирования. Довольно важно, если ты собрался в отпуск/заболеть/уволится и проект нужно передать другому инженеру.
- Мы подготавливаем тестовые материалы, что удобно при тестировании загрузок.
- Мы проанализировали немало инструментария для оптимизации и автоматизации процесса тестирования. И продолжаем поиски инструмента, который бы подходил нашей работе в полной мере.
Много сделано, и многое еще предстоит сделать! Дайте только время, у нас масса идей!
Кому и зачем читать?
Эта статья будет полезна как специалистам, которые хотят податься в отрасль тестирования, так и людям, которые недооценивают работу инженера по тестированию ПО. QA инженеры, надеюсь, поддержат все наши начинания и дадут дельный совет по развитию.
Всем спасибо! Жду замечаний и предложений. Второго жду больше :)
Автор статьи инженер-тестировщик INOSTUDIO Анна Сысоева.
Оригинал статьи читайте на страницах блога компании и не забывайте подписываться!