Поиск
Архивы
Админ
Архив рубрики "QA"
Тестирование устаревшей версии программы
Проблема: «Это исправлено!». «Это НЕ исправлено!». «Это исправлено! Вот скриншот, показывающий, что это работает!». «Плевать я хотел на ваши скриншоты. У меня НЕ работает!». Эта пикировка между разработчиком и тестировщиком быстро перерастает в оправданное убийство и возникает гораздо чаще, чем должна бы. Конфликт часто является результатом того, что разработчик... ДАЛЕЕ...
Повторное открытие старых сообщений для новых ошибок
Проблема: сообщение об ошибке помечено как FIXED , и все считают, что с этим покончено, но в ходе дальнейшего тестирования тестировщик видит ошибочное поведение, которое очень похоже на то, которое было вызвано ошибкой, которую сочли FIXED . Рассуждая, что поведение является настолько похожим, что это должно иметь ту же самую причину, тестировщик делает вывод, что... ДАЛЕЕ...
Отсутствие описания ошибочного и ожидаемого поведения
Отсутствие описания ошибочного поведения Проблема: описание в сообщении об ошибке заканчивается на простом утверждении о том, в каком состоянии находится приложение, без указания того, какой аспект этого состояния собственно является ошибкой. Например, сообщение об ошибке заканчивается так: «Появляется диалог Свойства», но тестировщик не добавляет, что... ДАЛЕЕ...
Сокращение инструкции по воспроизведению ошибки
Проблема: некоторые тестировщики полагают, что они могут сэкономить себе некоторое количество времени, описывая обстоятельства, при которых проявляется дефект, в самых кратких возможных терминах. Часто сообщение об ошибке превращается в сокращённую запись только основных действий, необходимых для воспроизведения ошибки, опуская все несущественные. Но,... ДАЛЕЕ...
Тестировщики — из какого теста они слеплены
Есть реальные преимущества наличия группы людей, отделённых от разработчиков, чья работа состоит исключительно в том, чтобы придираться к вашей работе. Они сохраняют эмоциональную и мыслительную дистанцию от продукта, которую разработчик не может сымитировать даже при всём желании. Тестирование — задача, требующая терпения, внимания к деталям и весьма... ДАЛЕЕ...
Как эффективно сообщать об ошибках
Введение Любой, кто написал программу для публичного использования, получил, по крайней мере, одно плохое сообщение об ошибке. Сообщения, которые не говорили ни о чем ("Это не работает"); сообщения, которые не имели смысла; сообщения, которые не давали достаточной информации; сообщения, которые давали неправильную информацию. Сообщения о проблемах, которые... ДАЛЕЕ...
Приемо-сдаточные испытания
Для того, чтобы сделать процесс сдачи проекта (этапа) более четким и однозначным, должны быть введены четкие приёмочные критерии, при выполнении которых заказчик обязан «принять» этап. В качестве таких критериев, в основном, используется набор тестов, успешное прохождение которых будет означать приемку этапа заказчиком. Изначально, на старте проекта, с... ДАЛЕЕ...
процесс сборки билдов и релиза
С целью более скорого выпуска деливери, содержащего только запланированный функционал, разработка должна вестись с помощью ветвления кода (branching). В один момент времени может быть до 2х веток кода: Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе). Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе). 0й... ДАЛЕЕ...
контроль версии
Каждая версия (сборка) должна идентифицироваться чётким образом. Легче всего применить следующий формат версии: XX.YY.revision , где Revision – номер внутренней сборки (Build number). Соответствует номеру последней ревизии в SVN, вошедшей в данную версию. YY – номер поставки заказчику (Delivery number), обнуляется при увеличении XX. XX – номер релиза (Release number). 1. Build для тестирования Как... ДАЛЕЕ...
Управление изменениями проекта.
В любом проекте происходят изменения инициированные заказчиком или командой. Для успешного завершения проекта этими изменениями придется управлять руководителю проекта. Иначе проект может оказаться вечным. Что входит в управление изменениями проекта: Анализ и сбор всех требований Заказчика. Фиксирование всех требований (общий бизнес-процесс, GUI, функционал)... ДАЛЕЕ...
