http://confetqa.ru/program-chief-2012/
disclaimer
Даже те доклады, которые бесят- лучше, чем ничего. В некоторых людях добро, в других зло, а есть люди, в которых только глисты. Зло явно прикольней глистов, ага.
Поехали, ведь мое мнение так важно для вас.
Definition of done или ставим задачи по S.M.A.R.T., Анна Скумина.
Ничего нового, но все равно редко кто правильно ставит задачи. Я вот по смарту - почти ни разу, обычно 2 из 5. Мне 3 или 4 из пяти.
Манагерам - слушать по утрам вместе с зарядкой, ага.
Читаем багтрекер между строк или тестирование процесса разработки, Сергей Вербенко
Вау, мы умеем строить прикольные графики и считать разные цыфирьки! А что с ними делать после подсчета - не рассказал. Жаль.
Google Docs как инструмент ежедневного тест менеджмента, Ксения Лещенко
Как вариант. Но -всплывет масса проблем, ох всплывет...
JIRA: dashboards и SOAP API, Никита Налютин
см. Сергей Вербенко
Волшебный пендель для развития (система корпоративного обучения), Виктория Птицына
Доклад не слушать, там лишнее. Вся ценность - в заголовке, понимать - буквально.
Внедрение новичка в команду тестировщиков, Жанна Битюкова
Бодро, дельно. Зачет.
Тестерская конфликтология или как вытаскивать «вбитые в голову гвозди», Сергей Атрощенков
Где-то я это уже слышал, и там это рассказывали поприкольней... хм...
Тестировщик и заказчик – заклятые друзья?, Татьяна Зинченко
При чем тут менеджеры и при чем тут тестировщики? Не, конечно, Таня молодец, что зарулила, но все-таки...
Жизнь без тестировщиков: миф или реальность?, Николай Алименков
Всем слушать до просветления, а затем дружно сбрасываться с горы. Сам пересмотрю и коллегам разошлю.
Планирование тестирования как ежедневная активность тест-менеджера, Наталья Руколь
Как и всегда, доклад мне не понравился, а сама Наташа - очень даже.
Требования в Jira: Just do it!., Даша Гармаш
Простая и добрая история о том, как человек взял и запилил версионирование требований в jire. Молодец.
Один человек на нескольких проектах: как не запороть всё, Андрей Мясников
Хорошая версия, интересный вариант. Норм.
Ждем
Показаны сообщения с ярлыком оценка тестирования. Показать все сообщения
Показаны сообщения с ярлыком оценка тестирования. Показать все сообщения
четверг, 15 марта 2012 г.
четверг, 5 февраля 2009 г.
Необходимость тестирования
LeshaL на форуме it4business предлагает варианты убеждения оппонента в необходимости грамотного тестирования.
Это к моим заметкам на полях.
Способ 1, "от противного": спросите оппонента - хочет ли он узнать о критических ошибках после или на кануне релиза; хочет ли он узнать от потльзователей что, то что понаписали не соответствует требованиям; хочет ли он чтобы программисты тратили свое драгоценное время на поиск дефектов, вместо того чтобы их чинить или писать что-то новое .... продолжите сами. Если ответ хоть раз ДА - тогда тестирование вашему оппоненту не нужно.
Способ 2, "сравнительный": сравните работу отдела тестирования с чем-нибудь понятным, например с издательством. Не для кого не секрет, что печатники держат в штате не только корреспондентов или писателей, но и корректоров, редакторов, цензоров. Так вот, тестеры на проекте выполняют работу схожую с работой корректоров, редакторов, цензоров, а также критиков и заодно и соавторов.
Способ 3, "чтобы сам допёр": название тестирование не совсем точно отражает специфику профессии. Объясните собеседнику, что более правильно называть деятельность - контролем качества ПО, неотъемлимой частью которого является тестирование. Попросите привести пару примеров производственной деятельности (да и любой другой), которая может успешно существовать без контроля, надзора и экспертизы.
Способ 4, "толкование роли": объясните собеседнику не функции, не выгоду и не технические аспекты. Объясните роль инженеров по качеству ПО. Для заказчика это "свой среди чужих" - интересы сотрудников отдела тестирования во многом совпадают с интересами заказчика. Так же, тестеры являются первыми реальными пользователями разрабатываемого ПО. Зачастую они единственные, кто лучше всех представляек как работает выпускаемый продукт и как им пользоваться.
©LeshaL, взято отсюда.
Это к моим заметкам на полях.
Способ 1, "от противного": спросите оппонента - хочет ли он узнать о критических ошибках после или на кануне релиза; хочет ли он узнать от потльзователей что, то что понаписали не соответствует требованиям; хочет ли он чтобы программисты тратили свое драгоценное время на поиск дефектов, вместо того чтобы их чинить или писать что-то новое .... продолжите сами. Если ответ хоть раз ДА - тогда тестирование вашему оппоненту не нужно.
Способ 2, "сравнительный": сравните работу отдела тестирования с чем-нибудь понятным, например с издательством. Не для кого не секрет, что печатники держат в штате не только корреспондентов или писателей, но и корректоров, редакторов, цензоров. Так вот, тестеры на проекте выполняют работу схожую с работой корректоров, редакторов, цензоров, а также критиков и заодно и соавторов.
Способ 3, "чтобы сам допёр": название тестирование не совсем точно отражает специфику профессии. Объясните собеседнику, что более правильно называть деятельность - контролем качества ПО, неотъемлимой частью которого является тестирование. Попросите привести пару примеров производственной деятельности (да и любой другой), которая может успешно существовать без контроля, надзора и экспертизы.
Способ 4, "толкование роли": объясните собеседнику не функции, не выгоду и не технические аспекты. Объясните роль инженеров по качеству ПО. Для заказчика это "свой среди чужих" - интересы сотрудников отдела тестирования во многом совпадают с интересами заказчика. Так же, тестеры являются первыми реальными пользователями разрабатываемого ПО. Зачастую они единственные, кто лучше всех представляек как работает выпускаемый продукт и как им пользоваться.
©LeshaL, взято отсюда.
вторник, 3 февраля 2009 г.
Тостер-тестер-тестировщик
Фазы зрелости процесса тестирования и сознания тестера
1. Нет разницы между отлаживанием и тестированием, тестирование всего лишь помогает при дебаге, цели у тестирования нет, сопсна как методик и подхода
2. Цель тестирования показать, что ПО работает (напоминает фразу хоть на соплях и с костылями но запускается), в данном случае тестировщик - это роль которую играет один из членов команды для выполнения демонстрации заказчику.
3. Цель тестирования показать что ПО не работает, отсюда уже исходит мотивация найти как можно больше ошибок, которая по большей части поддерживается руководством (премии,поощрения,план), подход в корне неверный и ведет к деградации.
4. Цель тестирования - уменьшить риски, возникающие при разработке ПО, начиная от неработающего ПО и заканчивая проблемами при развертывании и установке (уже применяются подходы и разнообразные методики).
5. Тестирование это не просто действие, а своего рода дисциплина, продуктом которой является высококачественный (под качеством подразумевается удовлетворенные ожидания заказчика) продукт с минимизированными рисками.
Обнаружено тут: QA - грамотно, ранее тут.
Посмотрел на себя и понял, что нахожусь в стадии три, но с надеждой гляжу в сторону четвертой.
1. Нет разницы между отлаживанием и тестированием, тестирование всего лишь помогает при дебаге, цели у тестирования нет, сопсна как методик и подхода
2. Цель тестирования показать, что ПО работает (напоминает фразу хоть на соплях и с костылями но запускается), в данном случае тестировщик - это роль которую играет один из членов команды для выполнения демонстрации заказчику.
3. Цель тестирования показать что ПО не работает, отсюда уже исходит мотивация найти как можно больше ошибок, которая по большей части поддерживается руководством (премии,поощрения,план), подход в корне неверный и ведет к деградации.
4. Цель тестирования - уменьшить риски, возникающие при разработке ПО, начиная от неработающего ПО и заканчивая проблемами при развертывании и установке (уже применяются подходы и разнообразные методики).
5. Тестирование это не просто действие, а своего рода дисциплина, продуктом которой является высококачественный (под качеством подразумевается удовлетворенные ожидания заказчика) продукт с минимизированными рисками.
Обнаружено тут: QA - грамотно, ранее тут.
Посмотрел на себя и понял, что нахожусь в стадии три, но с надеждой гляжу в сторону четвертой.
вторник, 20 января 2009 г.
Процесс тестирования
Наткнулся на несколько вопросов, которые формулируют ответы:
Установка процесса
Чтобы определить, существует ли у вас процесс тестирования в полном объеме необходимо выполнить небольшой тест. Всего шесть вопросов.
1. Есть ли у вас тестировщики (роль в проекте)?
2. Есть ли у вас сформулированная стратегия тестирования?
3. Используется ли система учета дефектов?
4. Есть ли у вас изолированное тестовое окружение?
5. Применяется ли процедура передачи новой версии программы в тестирование?
6. Есть ли у вас процедура оценки готовности программы?
Если на какой-то из вопросов вы ответили «нет», то должен вас огорчить. У вас нет процесса тестирования. Все расходы на содержание тестировщиков и траты на тестовые активности могут оказаться не эффективными. Каждый «нет» означает, что вы либо не контролируете процесс, либо не контролируете тестовое окружение, либо не контролируете работу тестировщиков, либо все вместе. Но вывод из всего этого один - вы не управляете процессом и, следовательно, уровнем качества вашего продукта.
©Гринкевич Сергей Статья написана по мотивам доклада, сделанного автором на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.
Установка процесса
Чтобы определить, существует ли у вас процесс тестирования в полном объеме необходимо выполнить небольшой тест. Всего шесть вопросов.
1. Есть ли у вас тестировщики (роль в проекте)?
2. Есть ли у вас сформулированная стратегия тестирования?
3. Используется ли система учета дефектов?
4. Есть ли у вас изолированное тестовое окружение?
5. Применяется ли процедура передачи новой версии программы в тестирование?
6. Есть ли у вас процедура оценки готовности программы?
Если на какой-то из вопросов вы ответили «нет», то должен вас огорчить. У вас нет процесса тестирования. Все расходы на содержание тестировщиков и траты на тестовые активности могут оказаться не эффективными. Каждый «нет» означает, что вы либо не контролируете процесс, либо не контролируете тестовое окружение, либо не контролируете работу тестировщиков, либо все вместе. Но вывод из всего этого один - вы не управляете процессом и, следовательно, уровнем качества вашего продукта.
©Гринкевич Сергей Статья написана по мотивам доклада, сделанного автором на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.
вторник, 13 января 2009 г.
Довументирование и оценка качества тестирования
Заметки на полях о тестировании.
Описание тестов
Описание тестов разрабатывается для облегчения анализа и поддержки тестового набора. Описание может быть реализовано в произвольной форме, но при этом должны выполнять следующие задачи:
1. Анализировать степень покрытия продукта тестами на основании описания тестового набора.
2. Для любой функции тестируемого продукта найти тесты, в которых функция используется.
3. Для любого теста определить все функции и их сочетания, которые данный тест использует (затрагивает).
4. Понять структуру и взаимосвязи тестовых файлов.
5. Понять принцип построения системы автоматизации тестирования.
Документирование и жизненный цикл дефекта
Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят в базу дефектов. Для этого лучше всего использовать специализированные базы, поддерживающие хранение и отслеживание дефектов - типа DDTS . При занесении нового дефекта рекомендуется указывать, как минимум, следующую информацию:
1. Наименование подсистемы, в которой обнаружен дефект.
2. Версия продукта (номер build ), на котором дефект был найден.
3. Описание дефекта.
4. Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5. Номер теста, на котором дефект был обнаружен.
6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.
Занесенный в базу дефектов новый дефект находится в состоянии "New" . После того, как команда разработчиков проанализирует дефект, он переводится в состояние "Open" с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние "Resolved". При этом разработчик должен указать следующую информацию:
1. Причину возникновения дефекта.
2. Место исправления, как минимум, с точностью до исправленного файла.
3. Краткое описание того, что было исправлено.
4. Время, затраченное на исправление.
После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние "Verified". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на "Open".
Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние "Postponed" с указанием лиц, ответственных за это решение, и причин его принятия.
Тестовый отчет
Тестовый отчет обновляется после каждого цикла тестирования и должен содержать следующую информацию для каждого цикла:
1. Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2. Количество выполненных тестов – запланированное и реально исполненное.
3. Время, затраченное на тестирование каждой функции, и общее время тестирования.
4. Количество найденных дефектов.
5. Количество повторно открытых дефектов.
6. Отклонения от запланированной последовательности действий, если таковые имели место.
7. Выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла.
Тестовые метрики
Существует устоявшийся набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта. К таким метрикам относятся следующие:
1. Покрытие функциональных требований.
2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования.
3. Покрытие множества сценариев.
4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий.
5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов).
6. Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.
Обзоры тестов и стратегии
Тестовый код и стратегия тестирования, зафиксированные в виде документов, заметно улучшаются, если подвергаются коллективному обсуждению. Такие обсуждения называются обзорами (review). Существует принятая в организации процедура проведения и оценки результатов обзора. Обзоры наряду с тестированием образуют мощный набор методов борьбы с ошибками с целью повышения качества продукта. Цели обзоров тестовой стратегии и тестового кода различны.
Цели обзора тестовой стратегии:
1. Установить достаточность проверок, обеспечиваемых тестированием.
2. Проанализировать оптимальность покрытия или адекватность распределения количества планируемых тестов по функциональности продукта.
3. Проанализировать оптимальность подхода к разработке кода, генерации кода, автоматизации тестирования.
Цели обзора тестового кода:
1. Установить соответствие тестового набора тестовой стратегии.
2. Проверить правильность кодирования тестов.
3. Оценить достигнутую степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п.
4. Если необходимо, проанализировать оптимальность тестового кода с целью удовлетворения требований к быстродействию и объему.
©www.intuit.ru
Описание тестов
Описание тестов разрабатывается для облегчения анализа и поддержки тестового набора. Описание может быть реализовано в произвольной форме, но при этом должны выполнять следующие задачи:
1. Анализировать степень покрытия продукта тестами на основании описания тестового набора.
2. Для любой функции тестируемого продукта найти тесты, в которых функция используется.
3. Для любого теста определить все функции и их сочетания, которые данный тест использует (затрагивает).
4. Понять структуру и взаимосвязи тестовых файлов.
5. Понять принцип построения системы автоматизации тестирования.
Документирование и жизненный цикл дефекта
Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят в базу дефектов. Для этого лучше всего использовать специализированные базы, поддерживающие хранение и отслеживание дефектов - типа DDTS . При занесении нового дефекта рекомендуется указывать, как минимум, следующую информацию:
1. Наименование подсистемы, в которой обнаружен дефект.
2. Версия продукта (номер build ), на котором дефект был найден.
3. Описание дефекта.
4. Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5. Номер теста, на котором дефект был обнаружен.
6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.
Занесенный в базу дефектов новый дефект находится в состоянии "New" . После того, как команда разработчиков проанализирует дефект, он переводится в состояние "Open" с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние "Resolved". При этом разработчик должен указать следующую информацию:
1. Причину возникновения дефекта.
2. Место исправления, как минимум, с точностью до исправленного файла.
3. Краткое описание того, что было исправлено.
4. Время, затраченное на исправление.
После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние "Verified". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на "Open".
Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние "Postponed" с указанием лиц, ответственных за это решение, и причин его принятия.
Тестовый отчет
Тестовый отчет обновляется после каждого цикла тестирования и должен содержать следующую информацию для каждого цикла:
1. Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2. Количество выполненных тестов – запланированное и реально исполненное.
3. Время, затраченное на тестирование каждой функции, и общее время тестирования.
4. Количество найденных дефектов.
5. Количество повторно открытых дефектов.
6. Отклонения от запланированной последовательности действий, если таковые имели место.
7. Выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла.
Тестовые метрики
Существует устоявшийся набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта. К таким метрикам относятся следующие:
1. Покрытие функциональных требований.
2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования.
3. Покрытие множества сценариев.
4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий.
5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов).
6. Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.
Обзоры тестов и стратегии
Тестовый код и стратегия тестирования, зафиксированные в виде документов, заметно улучшаются, если подвергаются коллективному обсуждению. Такие обсуждения называются обзорами (review). Существует принятая в организации процедура проведения и оценки результатов обзора. Обзоры наряду с тестированием образуют мощный набор методов борьбы с ошибками с целью повышения качества продукта. Цели обзоров тестовой стратегии и тестового кода различны.
Цели обзора тестовой стратегии:
1. Установить достаточность проверок, обеспечиваемых тестированием.
2. Проанализировать оптимальность покрытия или адекватность распределения количества планируемых тестов по функциональности продукта.
3. Проанализировать оптимальность подхода к разработке кода, генерации кода, автоматизации тестирования.
Цели обзора тестового кода:
1. Установить соответствие тестового набора тестовой стратегии.
2. Проверить правильность кодирования тестов.
3. Оценить достигнутую степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п.
4. Если необходимо, проанализировать оптимальность тестового кода с целью удовлетворения требований к быстродействию и объему.
©www.intuit.ru
Подписаться на:
Сообщения (Atom)