среда, 19 октября 2011 г.

Как use case могут изменить подход к тестированию

Для всех нас не секрет, что тестировщики используют самые разные подходы в своей работе. Иногда мы знаем, какую технику применяем, иногда делаем это чисто интуитивно.
В моей практике был случай, когда внедрение новой техники тестирования на основе use case (далее для простоты буду называть UC) помог нам несколько изменить процесс разработки в положительную сторону. Говорить о том, что у нас все стало очень круто и прекрасно, не буду, т.к. это не так. Мы только-только начали перестраивать уже имеющиеся процессы и это было очень нелегко. Но мы смогли!!!

Итак, немного предыстории:
Фирмы-аутсорсеры выдавали нам разные модули продукта, а мы их проверяли в интеграции.  Точнее так должно было быть, но до интеграции с нашей стороны дело редко доходило. Обычно тестировщики в нашей фирме проводили более полноценное тестирование отдельных модулей. Вот так уж повелось с начала проекта. В один прекрасный день команда тестировщиков в нашей фирме полностью сменилась. Именно в этот момент пришла на проект и я. Когда мы увидели, что происходит с тестированием – пришли в ужас. Ну и пошли разные митинги-документы об изменении процессов.
А теперь сама история:
В один день мы получили совсем нестабильную версию модулей. Скоро планируется выпуск продукта в продакшен, функции частично не реализованы, в интеграции большие проблемы… Немного попечалились и поняли: надо вводить еще одно изменение в процесс! Теперь наши аутсорсеры должны прогонять версию в соответствии с некоторыми сценариями и предоставлять нам отчет. Сценарии для них будем писать мы. Сами мы потом тоже будем проводить первоначальную приемку версии по тем же самым сценариям (ну возможно еще и дополним). Ну и соответственно будем сильно “ругаться”, если найдем ошибки, которые должны были быть найдены аутсорсерами.
Встал вопрос: “А на основе чего писать эти сценарии? Продукт-то мы и сами еще не до конца изучили”. Покумекали и решили: попробуем-ка составить сценарии ориентированные на нашего пользователя. Ну а раз так, значит нам прямая дорога к аналитикам выспрашивать UC.
Но, как обычно это и бывает, препятствия на этом не закончились. UC у нас были, но к другому проекту, в UML, да еще и в поверхностном виде… Но разве мы привыкли уступать? Ничего подобного! Гугл помог и у нас появилась настольная книга А. Коберна “Современные методы описания функциональных требований к системам”. Ура! В конце тоннеля забрезжил свет!
Собрали митинг и обсудили следующие вопросы:
  1. Кто будет писать UC?
  2. Насколько детализируем UC? Будем ли использовать альтернативные сценарии?
По результатам митинга поняли: тестировщики сами будут писать UC (развитие такого навыка не помешает, благо, что под боком есть аналитики, которые могут проконсультировать :) ). Т.к. ресурсов у нас не очень много и нам надо дать хотя бы начальный толчок: альтернативные сценарии отбрасываем, действия системы описываем в общем виде.
Работа закипела… В результате были созданы основные UC. Ну а дальше дело техники: написали сквозной приемочный сценарий. Сделали себе много пометок на будущее (как улучшить, какие еще сценарии разработать и т.п.).
Получившийся сценарий отправили аутсорсеру и согласовали с ним вид отчета. К сожалению, не удалось полноценно проверить наше нововведение в процессе, в связи со сменой проекта :(. Но я уверена, что задумка была классная и в очень скором времени дала бы плоды!
P.S.
У вас на проекте нет UC, а вы хотите использовать тестирование по ним в своем проекте? Нет ничего невозможного! У меня есть примерный перечень шагов, которые надо пройти:
  1. Читаем книгу Коберна.
  2. Определяем как и кем будет использоваться наш продукт (диаграмма прецедентов).
  3. Определяем какая детализация UC-ов нам на данном этапе будет оптимальна. Обязательно учитываем: имеющееся время, количество сотрудников и их знания (проекта, потребностей пользователя и написания UC).
  4. Записываем UC. Не забываем про нумерацию!
  5. Определяем детализацию сценариев тестирования на основе UС. Обязательно учитываем: на каком этапе тестирования мы будем использовать UC, квалификацию тестировщиков и их знание о продукте.
  6. Разрабатываем сценарии тестирования. Сразу же предусматриваем трассируемость между UC и сценарием, создаем оптимальные для нас наборы сценариев.
  7. Проводим пилотное тестирование по разработанным сценариям. На данном этапе нашей задачей является не проверить продукт (хотя это тоже может быть одной из целей, но не супер-важной). Нам здесь важнее протестировать наши сценарии: все ли понятно, возможно пропущены какие-то важные пункты (особенно касается, когда пишут разные люди, проект большой и сложный). Так же мы собираем некоторые метрики, к примеру, замеряем время для прохождения сценария (или набора сценария).
  8. Вносим данный вид тестирования в общую сетку работ. Тут, конечно, еще важно оценить сколько человек будет вовлечено в этот вид тестирования, сколько времени потребуется и др. вопросы менеджерской стороны :)
Желаю вам удачи в нашем интересно деле!

3 комментария:

  1. Отличная заметка! Имхо юз кейсы рулят!

    ОтветитьУдалить
  2. Как по мне, вы выбрали черезчур сложный путь. Написание хороших Use Cases не такое простое занятие. Да и выгода минимальна, потому как их еще потом и поддерживать нужно будет. А это опять падает на вас. И по итогу вы занимаетесь больше поддержанием "документации" чем тестированием.

    Да и отчего вы так уверены, что это бы помогло решить ваши проблемы?

    ОтветитьУдалить
    Ответы
    1. Николай, верные замечания! Спасибо.
      Мы не расценивали Use Case полной тратой времени. В дальнейшем поддержка нужна была бы минимальна, т.к. разрабатывалось второе "рождение" проекта и функциональность была известна и большей частью стабильна. Для нас это было:
      1. Дополнительный опыт (ведь под рукой были опытные аналитики, которые с этим сталкивались и могли подсказать).
      2. Дополнительное знакомство с продуктом (ведь мы не так давно пришли на проект).
      В общем мы взвешивали все "ЗА" и "ПРОТИВ". Положительного оказалось больше :)

      Однако, это бы не решило всех наших проблем, но определенные плоды бы точно дало! Тем более любой опыт (будь то и отрицательный) - полезен.

      Удалить