Главное Свежее Вакансии Образование
Выбор редакции:
637 3 В избр. Сохранено
Авторизуйтесь
Вход с паролем

QA-инженер: неизвестный герой качественного ПО

Каким должен быть QA-специалист, чтобы действительно гарантировать качество продукта? Уметь быстро нажимать на кнопки? Хм! Развеем миф об инженере-тестировщике, как об обезьянке с шаловливыми конечностями.

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

Что значит быть тестировщиком?

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

О навыках, без которых, на мой взгляд, инженеру по тестированию будет нелегко:

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

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

С чего начинается тестирование проекта?

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

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

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

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

Какое оно, некнижное тестирование проекта?

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

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

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

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

b_57220fd06a8ba.jpg

Режим многозадачности включен всегда.

Тестировщики тоже плачут...

Главная беда тестировщика — это «эффект пестицида». Другими словами «замыливание глаза», тут велика вероятность пропуска ошибки. Бороться с этим можно подключением стороннего тестировщика к проекту или созданием фокус-группы. Но если предложенные варианты нереальны, то только один совет — сделать перерыв и со свежим взглядом продолжить работу.

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

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

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

Что же мы делаем для облегчения нелегкой участи востребованного тестера:

  1. Мы ввели чек-лист для тестировщика. Его заполняет менеджер проекта, указывая всю необходимую информацию. Это позволило лишний раз не обращаться с вопросами, что чувствительно экономит время.
  2. Все задачи по проекту проходят через багтреккер. Это не ново, и каждый уважающий себя инженер умеет им пользоваться.Очень удобно, если грамотно его вести.
  3. Мы разработали единый шаблон оформления багов. Это позволит не упускать детали в описании ошибки.
  4. Для некоторых проектов пишется краткий отчет, где проставлены результаты тестирования. Отлично для самопроверки и для будущей работы с проектом.
  5. Мы написали немало чит-листов по проверке основного функционала, как для web, так и для мобильных приложений. Это систематизирует тестирование и неплохо экономит время.
  6. Мы работаем над оптимизацией плана тестирования. Довольно важно, если ты собрался в отпуск/заболеть/уволится и проект нужно передать другому инженеру.
  7. Мы подготавливаем тестовые материалы, что удобно при тестировании загрузок.
  8. Мы проанализировали немало инструментария для оптимизации и автоматизации процесса тестирования. И продолжаем поиски инструмента, который бы подходил нашей работе в полной мере.

Много сделано, и многое еще предстоит сделать! Дайте только время, у нас масса идей!

Кому и зачем читать?

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

Всем спасибо! Жду замечаний и предложений. Второго жду больше :)

Автор статьи инженер-тестировщик INOSTUDIO Анна Сысоева.

Оригинал статьи читайте на страницах блога компании и не забывайте подписываться!

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
vlib.co
Публикация электронных книг для начинающих авторов
Philipp Tkachev
QA-инженер это не тот, кто быстро кликает по кнопкам, а тот, кто пишет сценарии тестов.
При нормальном построении бизнес-процессов QA-инженер отвечает за качество ПО.
А такие банальные вещи, как формирование отчетов возлагаются обычно на ПО, многие системы, например Codeship умеет заводить баг в трекере, если тест был провален.
Как правило, тесты разделяются на интеграционные и модульные. За интеграционные тесты отвечает QA, за модульные - юнит-тесты, программисты.
Для исключения замыливания тесты должны выполняться машиной, а QA инженер должен их разрабатывать и дорабатывать.
Ответить
Анна Сысоева
Codeship... не пробовали.
Поизучаем, попробуем и определим подходит ли он нам на данном этапе нашей автоматизации.
Спасибо, добрый человек!
Выполнение тестов машиной хорошо при регрессе и уже стабильном проекте. В начале же тестирования от ручной проверки не уйти, тем более когда работаешь в параллель с разработкой.
Ответить
vlib.co
Публикация электронных книг для начинающих авторов
Philipp Tkachev
Codeship изначально средство непрерывной интеграции.
Есть такое понятие TDD - test driven development.
Упрощенно - разработка через тестирование, суть которой сводится к тому, что сначала пишутся тесты, а затем уже код программ.
Это подразумевает декларацию интерфейсов на начальном этапе разработки и стабилизацию требований внутри итерации.
Несколько болезненно на первоначальном этапе, но потом все привыкают и это существенно улучшает качество кода.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.