Тестирование устаревшей версии программы

Тестирование устаревшей версии программы

Проблема:

«Это исправлено!».
«Это НЕ исправлено!».
«Это исправлено! Вот скриншот, показывающий, что это работает!».
«Плевать я хотел на ваши скриншоты. У меня НЕ работает!».

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

Решение: установите процесс, регламентирующий координацию версий между разработчиками и тестировщиками. Помечайте каждую новую версию уникальным номером и всегда сообщайте номер версии, которая сейчас разрабатывается, и версии, которая тестируется. Назначьте ответственного за обеспечение наличия номера версии при передаче версии тестировщикам. Когда сообщение об ошибке объявляется FIXED , гарантируйте, что разработчики указывают номер версии, в которой появится исправление.

Повторное открытие старых сообщений для новых ошибок

Повторное открытие старых сообщений для новых ошибок

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

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

Отсутствие описания ошибочного и ожидаемого поведения

Отсутствие описания ошибочного и ожидаемого поведения

Отсутствие описания ошибочного поведения

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

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


Отсутствие описания ожидаемого поведения

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

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

Тестировщики — из какого теста они слеплены

Тестировщики — из какого теста они слеплены

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

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

Приемо-сдаточные испытания

Приемо-сдаточные испытания

Для того, чтобы сделать процесс сдачи проекта (этапа) более четким и однозначным, должны быть введены четкие приёмочные критерии, при выполнении которых заказчик обязан «принять» этап.

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

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

Таким образом, для каждого этапа набор работ будет следующим:

1. Составление перечня приемочных тестов

• QA анализирует требования к новому этапу.

• QA cоставляет список приемочных тестов для данного этапа. Лучше всего выделить эту группу в тест плане по версиям.

Набор тестов может быть прислан и заказчиком.

• QA утверждает список у PM-а.

2. Написание приемочных тестов

В отдельной тест кейс спецификации QA описывает запланированные на предыдущем шаге приемочные тесты.

3. Утверждение набора приемочных тестов

PM утверждает спецификацию приемочных тестов у заказчика.

4. Проведение приемо-сдаточных испытаний на стороне заказчика

При сдаче этапа (проекта) PM или QA на стороне заказчика демонстрирует успешное прохождение каждого утвержденного теста.

Процесс сборки билдов и релиза

Процесс сборки билдов и релиза

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

В один момент времени может быть до 2х веток кода:

  • Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе).
  • Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе).
  • 0й – разработка
  • 1й – тестирование, fix, разработка, сдача этапа (деливери)
  • 2й – тестирование, fix, разработка, сдача этапа (деливери)
  • 3й – тестирование, fix, сдача проекта (релиз).

Кратко процесс можно описать так:

  • 1. Для ближайшего деливери PM планирует объем необходимого функционала {Ф}.
  • 2. Реализуется весь заданный функционал {Ф} (о чем свидетельствует PM).
  • 3. Собирается билд для QA. QA приступает к тестированию функционала для ближайшего деливери {Ф}.
  • 4. PM планирует объем функционала {Ф} для следующего деливери.
  • 5. Разработчики приступают к разработке нового объема функционала {Ф}, параллельно исправляя дефекты, найденные в готовящемся деливери.
  • ! У дефектов приоритет всегда выше, чем у нового функционала!
  • 6. По мере исправления дефектов, имеющихся в готовящемся деливери, QA собирает промежуточные билды для тестирования.
  • 7. QA сигнализирует о том, что весь необходимый для деливери функционал реализован и дефекты отсутствуют. PM собирает деливери.
  • ! Деливери собирается и отправляется только после одобрения QA!
    • Деливери отправляется заказчику вместе с сопроводительной документацией.
  • 8. PM инициирует слияние двух веток.
  • 9. По мере реализации нового функционала для следующего деливери, QA собирает промежуточные билды для тестирования.
  • 10. Процесс повторяется до выпуска финальной версии.

Контроль версии

Контроль версии

Каждая версия (сборка) должна идентифицироваться чётким образом. Легче всего применить следующий формат версии:

XX.YY.revision , где

Revision – номер внутренней сборки (Build number). Соответствует номеру последней ревизии в SVN, вошедшей в данную версию.

YY – номер поставки заказчику (Delivery number), обнуляется при увеличении XX.

XX – номер релиза (Release number).

1. Build для тестирования

Как правило, очередной build собирает QA. Версия равна XX.YY.revision.

2. Объединение веток (merging)

Ветки объединяет руководитель проекта или техлид. Версия равна XX.YY.revision.

3. Сборка Delivery

Деливери собирает также руководитель проекта или техлид.

Версия устанавливается вручную в XX.YY (ревизия отбрасывается, YY увеличивается).

Также, рекомендуется для каждого билда писать примечание к версии (Release notes), что облегчит работу как с заказчиком, так и QA инженерами.

Управление изменениями проекта.

Управление изменениями проекта в ИТ.

Управление изменениями проекта

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

Что входит в управление изменениями проекта:

  • Анализ и сбор всех требований Заказчика.
  • Фиксирование всех требований (общий бизнес-процесс, GUI, функционал) в спецификации.
  • Регистрация всех требований, подлежащих реализации, в багтрекинговой системе. Соответствующая пометка тех требований, которые должны войти в деливери. Ответственный – руководитель проекта.
  • Обязательный групповой анализ каждого запроса на изменение или доработку (руководитель проекта, QA, бизнес аналитик, техлид). Полное уточнение информации, принятие решения (отклонение запроса, запуск в реализацию, оформление дополнительным оплачиваемым этапом и т.п.)
  • Оформление каждого запроса на изменение или доработку в форме Change Order, подлежащего подписи заказчиком (отвечает за оформление – бизнес аналитик, за подписание – руководитель проекта).
  • После утверждения изменений должно проходить обязательное обновление спецификаций, тест-кейсов и т.д.
  • Определение целесообразности начала тестирования следующего деливери.

Критерий начала:

  • Все или большинство требований, относящихся к следующему деливери (фазе), реализованы.

Определяет готовность версии к тестировании по багтрекинговой системе, ответственный QA. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все или большинство требований, попадающих в фильтр, будут реализованы, версию можно передавать на тестирование QA.

  • Определение готовности деливери к отправке. Критерии готовности:
  • все требования, относящиеся к данному деливери (фазе), реализованы;
  • открытые дефекты, относящиеся к данному деливери (фазе), отсутствуют.

Определяет по багтрекинговой системе QA и уведомляет руководителя проекта. Все требования, которые необходимо реализовать в определенном деливери, внесены в багтрекинговую систему с пометкой «Реализовать в x.y.» и, соответственно, попадают в фильтр «Деливери x.y.». Когда все требования и дефекты, попадающие в фильтр, будут закрыты, версию можно отсылать заказчику.

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

План график работ.

План график работ по проекту.

План график работ

План-график работ по проекту подготавливается руководителем проекта. Ознакамливаются с документом команда и заказчик. Документ дает понимание о временных рамках выполнения основных работ.

План-график работ проекта (лучше всего – в MS Project). Должен показывать:

  • Объем и дату каждого деливери.
  • Объем работ на каждом этапе.
  • Основные вехи.

Примеры основных вех:

  • MILESTONE- утверждение спецификаций (в план должно быть заложено время на ревю и утверждение спецификаций заказчиком).
  • MILESTONE- утверждение плана тестирования деливери Х (QA менеджер составляет план тестирования следующего деливери, который должен быть утвержден менеджером проекта).
  • MILESTONE- завершение кодирования по деливери X (разработчики успешно закончили кодирование функционала, предназначенного для сдачи в деливери X).
  • MILESTONE- QA приемка деливери (QA тестирует деливери на территории заказчика, если требуется, и дает «добро»).
  • MILESTONE- готовность деливери Х к отправке (все фичи реализованы, а дефекты успешно исправлены – деливери можно отправлять заказчику).
  • MILESTONE- готовность пользовательской документации (финальная документация, которую необходимо передать заказчику, должна пройти ревю менеджера проекта).
  • MILESTONE- приемка деливери заказчиком (используя набор приемочных тестов, PM получает формальное одобрение продукта заказчиком).
  • MILESTONE- проведен тренинг (заказчика необходимо обучить согласно заранее подготовленному плану).

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

План разработки сайта – SDP

План разработки сайта – SDP

План разработки сайта – SDP

План разработки сайта — Software Development Plan. Этот документ дает понимание участникам проекта (проектной группе и заказчику) о том, каким образом будет вестись работа в рамках проекта, каковы правила и т.д.

Документ дает полное представление:

  • о будущем проекте (цели, приоритеты, необходимые артефакты и те из них, которые подлежат сдаче заказчику);
  • об участниках проекта, роли каждого, а также их взаимодействии;
  • о плане проекта (WBS, графике, планируемых затратах);
  • о подходе к управлению требованиями;
  • о процессе разработки и тестирования;
  • о плане тестирования и плане управления конфигурацией;
  • о процедуре завершения проекта;
  • о подходе к сдаче-приемке проекта или этапа;
  • о плане обучения заказчика.

План разработки сайта описывает:

  • Цель, содержание и функции проекта
  • Объекты, подлежащие сдаче
  • Приоритеты проекта
  • Организация проекта
  • Проектная группа
  • Артефакты проекта
  • Роли и ответственности
  • Взаимодействие участников
  • Управление разработкой
  • План-график проекта
  • Контроль качества
  • Управление требованиями и изменениями
  • Управление конфигурацией
  • Инструменты, инфраструктура
  • Контроль версий
  • Процесс сборок и релиза
  • Работа с дефектами
  • Параметр бага «Fix in»
  • Фильтры
  • Зависимость полей
  • Значения поля «Version»
  • Действия QA после сборки внутреннего билда
  • Действия QA после сборки деливери
  • Действия PM после сборки деливери
  • Предоставление отчетов
  • Почта
  • Проектный цикл
  • Разработка
  • Тестирование
  • Приемо-сдаточные испытания
  • Участие клиента в процессе
  • Ревю и утверждение проектной документации
  • Обсуждение изменений в требованиях, сроках, бюджете
  • Просмотр промежуточных версий ПО
  • Фиксирование замечаний и дефектов
  • Приемо-сдаточные испытания
  • Дополнительные планы
  • План обучения пользователей
  • План решения проблем