Перейти к содержимому

Фотография

Проблемы тестирования это результаты тестирования


  • Авторизуйтесь для ответа в теме
В этой теме нет ответов

#1 baranceva

baranceva

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 4 247 сообщений
  • ФИО:Баранцева Наталья


Отправлено 24 октября 2011 - 06:06

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Testing Problems Are Test Results
Перевод: Сергей Высоцкий и RA

Часто во время курса "Быстрое Тестирование ПО", я провожу упражнение, в ходе которого прошу людей записать те вещи, которые, по их мнению, замедляют тестирование и делают его сложней. Эти списки отлично ложатся на шаблон, который я снова и снова слышу от тестировщиков (вы можете посмотреть пример такого шаблона в этой беседе на Stack Exchange). Обычные пункты в этих списках выглядят так:

  • Я - тестировщик, работающий один с несколькими программистами (или несколько тестировщиков работающих с большим числом программистов).
  • Мне приходится работать в чудовищных временных рамках. Сборки приходят постоянно и мы работаем в одно- двух-недельных циклах.
  • Продукт(ы) который(е) я тестирую очень сложный(е).
  • Очень много взаимозависимостей между компонентами продукта или между продуктами.
  • Я вижу устоявшийся шаблон ошибок, связанных с этими взаимозависимостями. Даже малейшие изменение может привести к чудовищным последствиям по всему продукту.
  • Я думаю, мне нужно прогонять полный цикл регрессионных тестов, чтобы обнаружить как можно больше таких ошибок.
  • Я пытаюсь справиться со всем этим при помощи автоматических проверок, но вся эта сложность делает автоматизацию крайне затруднительной, в лучшем случае у меня есть пара способов обойти проблему при помощи нескольких тестовых приемов, а частые изменения делают всю эту конструкцию очень хрупкой.
  • На поддержание автоматических тестов уходит столько времени, что почти ничего не остается на другую тестовую активность.
  • Я чувствую, что перегружен всем этим, но я пытаюсь справиться.
В добавок к этому:

  • Организация на которую я работаю говорит, что она работает по Agile.
  • Кроме двухнедельных итераций мы так же активно практикуем две другие вещи, часто ассоциирующиеся с Agile разработкой, обычно это ежедневные скрам митинги или доски Канбан.
Ах да, вот еще:

  • Сборки, которые я получаю, очень нестабильные. Система практически всегда валится после нескольких простейших smoke-тестов. Мне приходится тратить много времени на ожидание новой сборки или переконфигурацию, прежде чем я могу приступить к другим вещам
Как мы можем принять во внимание все эти наблюдения?

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





Читать дальше
  • 0
Наталья Баранцева
Тренинги по тестированию ПО


Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных