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

Английский для тестировщиков
онлайн, начало 21 июня
Погружение в тестирование. Jedi point
онлайн, начало 21 июня
Тестирование REST API
онлайн, начало 21 июня
Selenium WebDriver: полное руководство
онлайн, начало 18 июня
Фотография

Как Ускорить Процесс Написания Тест-кейсов


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 14

#1 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 898 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 04 июля 2007 - 12:41

У нас в компании crazy-agile разработка :clapping:

Нет времени расписывать тест-кейсы заранее. Тестирование большей частью происходит не по документации, а "на чутьё". Встать и сказать "Мужики, давайте все делать последовательно, по IEEEE стандартам!" не представляется возможным.

Однако необходимо собрать базу тест-кейсов:
- для проведения регрешн-тестирования,
- и для того, чтобы подключить к тестированию новых работников.
- и для того, чтобы упорядочить весь процесс тестирования.

Подскажите наиболее скоростной и эффективный способ для того, чтобы быстро записывать тест-кейсы.
Подскажите наиболее скоростной и эффективный способ для того, чтобы собрать веб-базу тест-кейсов.

Спасибо.
Спасибо большое.
  • 0

Software Testing Glossary - простыми словами о непростых словах.


#2 Pet[EG]

Pet[EG]

    Активный участник

  • Members
  • PipPip
  • 86 сообщений
  • ФИО:Петраш А.Ю.
  • Город:Харьков, Укр

Отправлено 04 июля 2007 - 14:20

Подскажите наиболее скоростной и эффективный способ для того, чтобы быстро записывать тест-кейсы.

У нас в таком случае использовались чек-листы. Для регрешена вполне себя оправдали.
С подключением новых работников есетственно будут возникать трудности, но при нормальном общении в команде трудности вполне решаемы. Зато новому человеку будет на что опираться при тестировании.
Вместо фразы "Вот тебе логины-пароли, на посмотри тут" у него уже будет обощенный план действий\список функциональности и почва для задавания конкретных вопросов в стиле "а как выполнить проверку бэкап скедьюлера? где он у нас в приложении находится?"
  • 0

#3 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 04 июля 2007 - 14:20

А Use Cases вы пишите? Или Story? Или еще что-нибудь?

Если да, то привязывайтесь к ним и пишите тесты со ссылкой на стори. Тогда будет видно что покрыто тестами, а что нет.

Прикидывайте, сколько тестов должно быть выполнено на это стори и пишите число, а потом смотрите сколько тест кейсов у вас есть. В результате будет видно насколько полно было протестировано это стори.

Составьте список стандартных тест-данных (речь идет не о тривиальных тестовых данных которые каждый может выдумать на ходу, а тех, которые нужно готовить заранее, например пустй файл, или файл большого размера, или файл со списком данных 1.000.000 пользователей). Указывайте связку: стори - тест кейс - тестовые данные.

Давно хочу придумать способ делать краткие тест кейсы. Точнее не столько тест кейсы, сколько их определение, что бы было понятно, что именно этот тест кейс проверяет. Но все "руки не доходят" сесть и подумать, как это может быть реализовано. Так что кроме как писать каждый тест кейс ничего предложить не могу.

Может кто поделиться своими приемами по определению тест кейсов (краткой записи)?
  • 0
Гринкевич Сергей

#4 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 898 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 04 июля 2007 - 15:45

Спасибо. Подумаю.

В общем, у нас в компании нестыковка в процессах происходит. Программисты предлагают тестировать то, над чем они работали (это отражено в Mantis). Я хочу поднять процесс тестирования до уровня процессов программирования:
- тестировщика должны извещать заранее о том, что начинается разработка того или иного функционала
- нужно планировать время не только на само тестирование, но и на подготовку к тестированию.

Чтобы показать начальству преимущества этой "подготовки", мне необходимо показать им расписанный мною комплект тест-кейсов, на основе которого я сделаю тест-план, и буду тестировать по плану. В плане будет указано время, необходимое для проведения тестирования. Перспективый радужные.

Отсюда и вопрос: подскажите наилучший образ того, как в условиях нехватки времени умудриться очень-очень быстро записать тест-кейсы и опубликовать их в каком-нибудь веб-приложенном test cases manager?

Писать ну очень короткие тест-кейсы, а потом "проводить" их один за другим в виде "тест-комплектов"?

Расписывать их сразу в test cases manager? ("Быстро записать" - это в Блокнот. Но это черновик. "Быстро записывать" в Twiki или в RTH (беловик) не получается...)

У нас почему такая ситуация сложилась - очень высокая скорость разработки, еженедельно в продакшн выходят новые версии программного обеспечения. Программное обеспечение разрабатывается для собственных нужд, программисты свой код изрядно комментируют, и считают, что менять ничего не требуется.

В Twiki лежит много документации на уровне технических спецификаций, которые менеджмент обсуждает с программистами. Иногда они подробно расписывают Use Cases, чаще - оставляют все на уровне схемы программных модулей, которые друг с другом взаимодействуют. Мол, все обсуждено и понятно. А на деле - тестировщик постоянно дергает программистов с просьбой разъяснить да уточнить. И постоянно "не хватает времени". И постоянно непонятно, что приоритетнее тестировать. А это непонятие происходит из того, что не составляется и не обсуждается тест-план :( А чтобы составить тест-план - нужно составить тест-кейсы...

  • 0

Software Testing Glossary - простыми словами о непростых словах.


#5 d4lt

d4lt

    Новый участник

  • Members
  • Pip
  • 43 сообщений
  • ФИО:Алексей
  • Город:Санкт-Петербург

Отправлено 05 июля 2007 - 08:48

Для меня оптимальным вариантом быстрого написания большого количества качественных тестовых кейсов стало составление списка функциональности и определение для каждой функции некоторого списка тестов.
Я открывал эксель, в ряды заносил все функции, которые только видел в приложении: нажатие/отжатие кнопок, обновление экрана, перемещение элементов по спискам и т.д. Чем более детально составлялся этот список, тем лучше в итоге получались процедуры. Если нужно было писать ну очень быстро, приходилось вносить только основной функционал, не опираясь на детали, но по возможности добавляя их в более спокойное время.
Для каждой функции было 4 колонки: санити тест, сложный тест, коррапт-тест и сценарный тест. Санити - это "дымовой тест", напраленный на быструю проверку работоспособности фичи. Сложный тест содержал в себя граничные, но допустимые для функции значения. Коррапт-тест был направлен на установку недопустимых для функции параметров. Со сценарным и так все ясно.
Так вот, очень срочное написание требует заполнение всего лишь первой колонки, в нее можно записывать только краткое описание теста (мол, убедись, что при включении флажка будет выводиться прямоугольник). При просто быстром написании можно заполнить первую и вторую колонки.
  • 1

#6 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 898 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 05 июля 2007 - 10:18

Для меня оптимальным вариантом быстрого написания большого количества качественных тестовых кейсов стало составление списка функциональности и определение для каждой функции некоторого списка тестов.


Супер.

Была ли задача перенести все результаты тестов в общую веб-базу?
Были ли какие-то требования о их оформлению?
  • 0

Software Testing Glossary - простыми словами о непростых словах.


#7 d4lt

d4lt

    Новый участник

  • Members
  • Pip
  • 43 сообщений
  • ФИО:Алексей
  • Город:Санкт-Петербург

Отправлено 05 июля 2007 - 11:25

Можно так и оставить в xls, только внести его под версионный контроль, это вполне годится для небольших проектов. Альтернативой является написание макроса или парсера, который дергал бы ячейки и составлял нормальный, отформатированный документ.
Мы пользуемся внутренней тулой, куда можно экспортить нужные кейсы. Обычно на подготовку шаблона и экспорт уходило не более 3-4 часов для 1000-15000 кейсов. В общем, все зависит от используемых средств.
  • 0

#8 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 898 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 05 июля 2007 - 11:44

Пока видится следующий самый "скоростной" метод:
  • открываем Excel (или Calc)
  • первая колонка - все функции, которые только попадаются на глаза
  • вторая колонка - результаты смок-тестов каждой функции
  • третья колонка - результаты тестов с граничными, но допустимыми для функции значениями
  • четвертая колонка - результаты тестов с недопустимыми для функции параметров
  • скоростной экспорт всей страницы с результатами в wiki-разметку и публикация файла на внутреннем сервере.
  • начальству летит отчет - сделано то-то, пройдено/не пройдено столько-то тестов.
Это чек-лист. Это ответ на то, как можно максимально быстро протестировать программу.

Но
  • здесь нет ответа на то, сколько времени заняла подготовка тест-кейсов. Не всё же постоянно на ходу придумывать, рассматривая интерфейс?
  • сколько времени уходит на расписывание какого-либо тест-кейса (по-моему, это ключевой момент для вычисления времени, необходимого для проведения тестирования и для определения приоритетов тестирования)?

  • 0

Software Testing Glossary - простыми словами о непростых словах.


#9 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 05 июля 2007 - 12:18

Можно так и оставить в xls, только внести его под версионный контроль, это вполне годится для небольших проектов. Альтернативой является написание макроса или парсера, который дергал бы ячейки и составлял нормальный, отформатированный документ.
Мы пользуемся внутренней тулой, куда можно экспортить нужные кейсы. Обычно на подготовку шаблона и экспорт уходило не более 3-4 часов для 1000-15000 кейсов. В общем, все зависит от используемых средств.


В Excel-е есть очень хорошая функционяльность для таких задач - Pivot Table.
Можно собирать любые типы данных с любыми преобразованиями.
  • 0
Гринкевич Сергей

#10 ArtemRudenko

ArtemRudenko

    Постоянный участник

  • Members
  • PipPipPip
  • 248 сообщений
  • ФИО:Руденко Артем Михайлович
  • Город:Минск


Отправлено 05 июля 2007 - 12:36

Описаный выше способ от d4lt, отчасти напомнил мне используемый нами на предыдущем проекте вариант:
Первый стобец в каждой строчке содержит одно, самое простое действие - клик,ввод,условие.
С второго по n столбцы могут содержать и содержат только какой-то символ, в нашем случае 'X', который означает, что это действие должно быть выполнено - таким образом в одной отдельно взятой колонке, начиная со 2 ,хранятся все действия необходимые для проверки тестового случая.
В самой нижней строке после всех действий заносится результат выполнения тест кейса - то с чем сравниваем в ходе тестирования.
Таким образом кол-во текста на реализацию одного кейса уменьшается до минимума.
Если надо будет пример обращайтесь.
  • 0
И всё-таки она вертится...

#11 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 05 июля 2007 - 12:45

У нас почему такая ситуация сложилась - очень высокая скорость разработки, еженедельно в продакшн выходят новые версии программного обеспечения. Программное обеспечение разрабатывается для собственных нужд, программисты свой код изрядно комментируют, и считают, что менять ничего не требуется.

В Twiki лежит много документации на уровне технических спецификаций, которые менеджмент обсуждает с программистами. Иногда они подробно расписывают Use Cases, чаще - оставляют все на уровне схемы программных модулей, которые друг с другом взаимодействуют. Мол, все обсуждено и понятно. А на деле - тестировщик постоянно дергает программистов с просьбой разъяснить да уточнить. И постоянно "не хватает времени". И постоянно непонятно, что приоритетнее тестировать. А это непонятие происходит из того, что не составляется и не обсуждается тест-план :( А чтобы составить тест-план - нужно составить тест-кейсы...



Описана типичная ситуация для небольших проектов (2-5 разработчика на проект). И так же указана типичная ошибка для таких проектов (для более крупных проектов эта ошибка "вылазит" раньше, поэтому чаще всего ее решают каким-нибудь способом).

Ошибка заключается в том, что разработчики и бизнес-заказчики (менеджеры, как я понял) общаются напрямую без специального посредника - бизнес-аналитика или системного аналитика (по RUP). В результате мало внимания уделяется документации. Программисты не хотят заниматься бумажной работой. В их понимании это пустая трата времени. Ведь они и так знают всю спецификацию почти наизусть. Рано или поздно это приводит к тому, что документация теряет свою актуальность и выбывает из практического использования. Требования и изменения в требования "размазываются" по письмам, всяким листочкам, дополнительным приложениям. Как результат, никто не может разобраться в документации (даже сам разработчик).

Выход очень прост. Работа с требованиями - это задача отдельной роли, которую выполняет бизнес аналитик. Если хотите иметь всегда актуальную информацию - выделяйте ресурсы и время на эту работу.

Здесь я не затронул другие выгоды от привлечения бизнес-аналитика. Согласен, что ведение документации и поддержание ее в актуальном состоянии не является его основной (точнее сказать, главной) задачей.


Очень часто бывает так, что не возможно повлиять на чужой участок ответственности. К примеру, невозможно заставить ПМ-а взять в проект аналитика. Значит нужно действовать с другого конца. Необходимо взять тест дизайнера (или назначить кого-нибудь на эту роль). Тест дизайнер будет постоянно поддерживать в актуальном состоянии матрицу соответствия актуальных функций проекта (требований) и тест-кейсов. Он будет "выбивать" из разработчиков информацию - откуда взять последние данные о том, какие именно требования входят в последную версию и вносить изменения в матрицу Требования-ТестКейсы.

Дополнительно можно договориться с разработчиками, что при выпуске очередного билда они дополняют файл "Build notes" о том, какая функциональность была изменена/добавлена в очередном билде. Вообще-то это можно делать автоматически, если налажен автоматизированный воркфлоу по configuration management-у. Тогда при создании автоматической сборке формируется файл с описание, какие изменения были включены в сборку.
  • 0
Гринкевич Сергей

#12 d4lt

d4lt

    Новый участник

  • Members
  • Pip
  • 43 сообщений
  • ФИО:Алексей
  • Город:Санкт-Петербург

Отправлено 05 июля 2007 - 13:15

Но

  • здесь нет ответа на то, сколько времени заняла подготовка тест-кейсов. Не всё же постоянно на ходу придумывать, рассматривая интерфейс?
  • сколько времени уходит на расписывание какого-либо тест-кейса (по-моему, это ключевой момент для вычисления времени, необходимого для проведения тестирования и для определения приоритетов тестирования)?


Рассматривая интерфейс можно одновременно записывать функционал и добавлять тесты.
На выявление фичи уходит ~2 минуты, на запись 2 тестов разных описаний тестов ~2-4 минут (замечу, что это санити и простой тест) с пересмотром и правкой неточностей. Итого 6 минут, и это в худшем случае.
  • 0

#13 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 05 июля 2007 - 14:17

У нас почему такая ситуация сложилась - очень высокая скорость разработки, еженедельно в продакшн выходят новые версии программного обеспечения.


astenix,

полагаю, это ошибка выпускать фичи с такой быстротой. Надо учитывать, что тестирование имеет большую инертность по отношению к разработке (так как тестирование - это зависимый процесс). При такой скорости выпуска невозможно проводить регрешн тестирование. Выходит, что или у вас очень маленькие проекты (длительностью до 1-2 недель), либо это не полноценная разработка, а выпуск патчей (соответственно, и тестирование патчей а не всей функциональности).

В случае полноценной разработки такая скорость не только не оправдана, но и опасна. Нет никакой гарантии, что в продакшн не попадет критичный баг.
  • 0
Гринкевич Сергей

#14 Dimis

Dimis

    Новый участник

  • Members
  • Pip
  • 7 сообщений
  • Город:Riga

Отправлено 11 сентября 2007 - 14:27

Рассматривая интерфейс можно одновременно записывать функционал и добавлять тесты.
На выявление фичи уходит ~2 минуты, на запись 2 тестов разных описаний тестов ~2-4 минут (замечу, что это санити и простой тест) с пересмотром и правкой неточностей. Итого 6 минут, и это в худшем случае.


А как происходит запись в чек-лист если фичу нужно проверять несколькими тестами? Например есть несколько вариантов использования. Т.е. одной строки для одной фичи недостаточно. Тогда записывается несколько строк для одной фичи с разными вариантами использования?

И ещё вопрос делаете ли вы сортировку тестов в чек листе? Например чтобы выполнять однотипные тесты, а не как попало.
  • 0

#15 Kaermo

Kaermo

    Новый участник

  • Members
  • Pip
  • 1 сообщений

Отправлено 12 ноября 2007 - 13:25

Описаный выше способ от d4lt, отчасти напомнил мне используемый нами на предыдущем проекте вариант:
Первый стобец в каждой строчке содержит одно, самое простое действие - клик,ввод,условие.
С второго по n столбцы могут содержать и содержат только какой-то символ, в нашем случае 'X', который означает, что это действие должно быть выполнено - таким образом в одной отдельно взятой колонке, начиная со 2 ,хранятся все действия необходимые для проверки тестового случая.
В самой нижней строке после всех действий заносится результат выполнения тест кейса - то с чем сравниваем в ходе тестирования.
Таким образом кол-во текста на реализацию одного кейса уменьшается до минимума.
Если надо будет пример обращайтесь.

неплохо было бы посмотреть пример, на первый взгляд идея ясна, но хотелось бы наглядности. Заранее спасибо.
  • 0


Практикум по тест-дизайну 2.0
онлайн
Школа для начинающих тестировщиков
онлайн
Школа тест-аналитика
онлайн
Техники локализации плавающих дефектов
онлайн



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

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

Яндекс.Метрика
Реклама на портале