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

Тестирование без требований
онлайн, начало 25 января
Тестирование безопасности
онлайн, начало 25 января
Школа Тест-Аналитика
онлайн, начало 27 января
Тестирование производительности: JMeter 5
онлайн, начало 22 января
Фотография

Как вы храните повторяющиеся кейсы?


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

#1 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 19 января 2020 - 20:44

Всем привет, хочу посоветоваться как хранить повторяющиеся кейсы.

Простой пример, думаю, что многие с таким сталкивались. Есть поле ввода данных. Оно повторяется на разных страницах сайта и даже скопировано на другой аналогичный сайт. Допустим поле совершенно идентичное везде и ни для одной страницы нет какой-то специальной проверки. Проверяется везде, но речь не об этом. А о том как кейсы на это поле организовать в системе (у меня TestRail).

 

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

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

 

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

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

 

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

 

Как вы выходите с подобных ситуаций? Есть ли у вас какие-то элегантные способы организовывать секции и сабсекции?

Спасибо, что поделились!

 

 


  • 0

#2 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 20 января 2020 - 08:38

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.


  • 0

#3 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 января 2020 - 09:05

третий способ:

 

написать наконец компонентные юнит-тесты для этого поля и удалить все соответствующие мануальные тесты


  • 0

#4 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 20 января 2020 - 09:50

третий способ:

 

написать наконец компонентные юнит-тесты для этого поля и удалить все соответствующие мануальные тесты

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


  • 0

#5 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 20 января 2020 - 09:51

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

то есть есть список кейсов, проваливаешься в один, а там только ссылка и больше ничего?


  • 0

#6 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 января 2020 - 10:16

 

 

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

может скажете почему он нереализуемый в Вашем конкретном случае?


  • 0

#7 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 20 января 2020 - 10:44

 

 

 

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

может скажете почему он нереализуемый в Вашем конкретном случае?

 

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

А еще в том, что это пример простой, но у меня в проекте сейчас похожие по сути, но более сложные наборы кейсов и ресурсов на это нет.

Извините, если говорю слишком уклончиво, пока не очень понимаю, что можно, а что нельзя рассказывать. Я тестирую аналог Unity, он включает в себя много разных редакторов и они используют одинаковые механизмы типа copy/paste или создание связей между объектами, я не чувствую себя вправе сказать - а покройте-ка мне тестами половину редактора, а я пока на остальное кейсы попишу. 


  • 0

#8 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 января 2020 - 11:05

 

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

А еще в том, что это пример простой, но у меня в проекте сейчас похожие по сути, но более сложные наборы кейсов и ресурсов на это нет.

Извините, если говорю слишком уклончиво, пока не очень понимаю, что можно, а что нельзя рассказывать. Я тестирую аналог Unity, он включает в себя много разных редакторов и они используют одинаковые механизмы типа copy/paste или создание связей между объектами, я не чувствую себя вправе сказать - а покройте-ка мне тестами половину редактора, а я пока на остальное кейсы попишу. 

наоборот, именно надо привлекать других людей для тестирования

 

девелоперы должны свою часть тестирования делать, чтобы мануальщикам не приходилось создавать/поддерживать/выполнять тест-кейсы-монстры для таких мелочей как поля

 

да, надо говорить девелоперам, и Вы имеете на это право, пусть покрывают тестами, даже не половину а весь редактор. А то у Вас не остаётся времени на действительно важную работу


  • 0

#9 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 20 января 2020 - 13:27


девелоперы должны свою часть тестирования делать, чтобы мануальщикам не приходилось создавать/поддерживать/выполнять тест-кейсы-монстры для таких мелочей как поля

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

 

Вокруг меня, как правило, разработчики считают, что на тесты нужно тратить минимум времени. Пишут для формального покрытия кода, и пишут в стиле "2+2=4" вместо проверки хотя бы граничных значений.

 

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


  • 0

#10 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 20 января 2020 - 13:29

 

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

то есть есть список кейсов, проваливаешься в один, а там только ссылка и больше ничего?

 

Главное же идея, а как именно оформить - смотрите сами.

 

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


  • 0

#11 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 января 2020 - 13:32

 

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

 

Вокруг меня, как правило, разработчики считают, что на тесты нужно тратить минимум времени. Пишут для формального покрытия кода, и пишут в стиле "2+2=4" вместо проверки хотя бы граничных значений.

 

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

вводить такую систему просто

 

пусть отдел разработки в "Definition of Done (DoD)" добавит пункт "написать автоматические тесты"

 

а Вы потом при тестировании просто иногда заглядывайте в код, и смотрите чтобы там нормальные тесты были (конечно иногда там и должно быть 2*2=4, например если это тест АПИ а функционал уже протестирован уровнем ниже)


  • 1

#12 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 20 января 2020 - 13:58

 

 

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

 

Вокруг меня, как правило, разработчики считают, что на тесты нужно тратить минимум времени. Пишут для формального покрытия кода, и пишут в стиле "2+2=4" вместо проверки хотя бы граничных значений.

 

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

вводить такую систему просто

 

пусть отдел разработки в "Definition of Done (DoD)" добавит пункт "написать автоматические тесты"

 

а Вы потом при тестировании просто иногда заглядывайте в код, и смотрите чтобы там нормальные тесты были (конечно иногда там и должно быть 2*2=4, например если это тест АПИ а функционал уже протестирован уровнем ниже)

 

Эх...

Чтобы заглядывать в код, нужно понимать, что там происходит. Я слышала истории, что разрабы писали тесты, чтобы они были зеленые, а не чтобы проверяли. Если понимания кода пока нет, то быстро оно не появится, хотя, к этому, безусловно, нужно стремиться.

Еще момент, что автотесты часто пишут по готовым ручным, значит создать эту ручные все же нужно. А потом уже по мере покрытия автотестами удалять из ручных ранов.

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


  • 0

#13 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 20 января 2020 - 13:59

 

 

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

то есть есть список кейсов, проваливаешься в один, а там только ссылка и больше ничего?

 

Главное же идея, а как именно оформить - смотрите сами.

 

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

 

Спасибо! Попробую приложить к своим кейсам, посмотрю, что получится.


  • 0

#14 Marinka1002

Marinka1002

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

  • Members
  • Pip
  • 1 сообщений
  • ФИО:Коростова Марина Вадимовна

Отправлено 20 января 2020 - 14:12

Привет всем) Совершенно не знаю в какой чат писать, по этому пишу сюда)

Я начинающие тестеровщик, мой руководитель дал мне задание зарегаться  на форме и спросить у более опытных людей, где найти примеры задания и отчетов по тестированию, чтобы знать на что опираться и как лучше писать отчеты, буду благодарна за помощь ))

p.s. Будет здорово, если кто нибудь сможет мне скинуть пример, HELP ME!!!!!!! :shout:  :shout:  :shout:


  • 0

#15 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 20 января 2020 - 14:37

Привет всем) Совершенно не знаю в какой чат писать, по этому пишу сюда)

Я начинающие тестеровщик, мой руководитель дал мне задание зарегаться  на форме и спросить у более опытных людей, где найти примеры задания и отчетов по тестированию, чтобы знать на что опираться и как лучше писать отчеты, буду благодарна за помощь ))

p.s. Будет здорово, если кто нибудь сможет мне скинуть пример, HELP ME!!!!!!! :shout:  :shout:  :shout:

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


  • 0

#16 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 января 2020 - 14:41

 

Эх...

Чтобы заглядывать в код, нужно понимать, что там происходит. Я слышала истории, что разрабы писали тесты, чтобы они были зеленые, а не чтобы проверяли. Если понимания кода пока нет, то быстро оно не появится, хотя, к этому, безусловно, нужно стремиться.

для начала смотрите не в код проекта, он скорее всего очень сложный - а смотрите в код тестов, там код простой и понятный

 

 

 

Еще момент, что автотесты часто пишут по готовым ручным, значит создать эту ручные все же нужно.

это самый плохой вариант, в тестах будет мешанина которая толком ничего не тестирует. Хороший вариант это просто удалить все ручные тесты, пусть разработка делает свое дело а тестировщик тестирует фичи а не какие-то поля

 

 

 

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

перестать тестировать эти поля, которое по описанию то же самое но в десяти местах. И освободившуюся кучу времени тратить на более важные таски, на тестирование требований и т.д. 

 

а создание ручных монстро-тестов с повторяющимися шагами это не облегчит жизнь, а доведёт до нервных расстройств


  • 0

#17 Vienta

Vienta

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

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Юлия Голутво


Отправлено 20 января 2020 - 15:19

 

 

Эх...

Чтобы заглядывать в код, нужно понимать, что там происходит. Я слышала истории, что разрабы писали тесты, чтобы они были зеленые, а не чтобы проверяли. Если понимания кода пока нет, то быстро оно не появится, хотя, к этому, безусловно, нужно стремиться.

для начала смотрите не в код проекта, он скорее всего очень сложный - а смотрите в код тестов, там код простой и понятный

 

 

 

Еще момент, что автотесты часто пишут по готовым ручным, значит создать эту ручные все же нужно.

это самый плохой вариант, в тестах будет мешанина которая толком ничего не тестирует. Хороший вариант это просто удалить все ручные тесты, пусть разработка делает свое дело а тестировщик тестирует фичи а не какие-то поля

 

 

 

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

перестать тестировать эти поля, которое по описанию то же самое но в десяти местах. И освободившуюся кучу времени тратить на более важные таски, на тестирование требований и т.д. 

 

а создание ручных монстро-тестов с повторяющимися шагами это не облегчит жизнь, а доведёт до нервных расстройств

 

Мне очень нравится то, что Вы говорите. В такой рабочей ситуации хочется оказаться. Можете, пожалуйста, тогда дать более конкретный совет? Если отбросить пример про поля, как простой, а взять конкретную задачу моей реальности. В аналоге Unity, который я тестирую, появился новый редактор, который мне отдали покрыть кейсами. Требований нет, писался из головы и теперь разработчик вместо требований, все рассказывает, объясняет. Как-то этот редактор тестировали пока разрабатывали (я тогда в компании еще не работала и ничего сказать не могу), баги есть, но в целом все работает. И вот я начинаю писать кейсы, нахожу похожие проверки, думаю как мне это лучше организовать и пока что даже не представляю что из этого и как можно отдать на тестирование разработчикам. Начать с разговора с разработчиком, что из этого он мог бы покрыть проверками, чтобы не проверять это в каждом регрессе, а значит и нет необходимости хранить в виде кейсов? А если он скажет, что ничего не может сделать, занят другими вещами, если менеджер мне скажет, что нет возможности выделить время на это сейчас? Как тогда быть? Создавать кейсы/чеклисты, стараться не плодить монстро-кейсы и доносить необходимость? Мне кажется, что это выглядит так, что мне дали покрыть функционал кейсами, а я с разворота - а давайте вы сами большую часть работы сделаете, а я буду делать что-то более важное. Если я сама в это не верю, то не смогу убедить других.

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


  • 0

#18 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 января 2020 - 15:27

создайте список фич и всего что надо проверять, получится чек-лист

 

тестирование должно быть более исследовательским чем заскриптованным

 

а тест-кейсы не нужны, Вас же не заставляют их писать

 

тестируйте фичи , регрессионное тестирование по чек-листу

 

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


  • 1

#19 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 179 сообщений
  • Город:Москва

Отправлено 20 января 2020 - 18:55

1. Самое элегантное в теории, что я видел, - BPT в ALM от HP. В связке с UFT ураган. Реализуемо, но тормознуто все. Надеюсь, октан будет в разы лучше.
2. Чеклист.
3. Коберн.
4. Spock.
Как меня достали эти монстры кейсы.
  • 2

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс



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



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

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

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