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