Сообщений в теме: 18

[Vienta]

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

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

 

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

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

 

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

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

 

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

 

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

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

 

 

[checo]

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

[Spock]

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

 

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

[Vienta]

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

 

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

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

[Vienta]

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

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

[Spock]

 

 

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

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

[Vienta]

 

 

 

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

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

 

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

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

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

[Spock]

 

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

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

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

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

 

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

 

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

[checo]

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

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

 

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

 

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

[checo]

 

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

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

 

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

 

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

[Spock]

 

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

 

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

 

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

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

 

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

 

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

[Vienta]

 

 

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

 

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

 

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

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

 

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

 

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

 

Эх...

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

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

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

[Vienta]

 

 

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

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

 

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

 

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

 

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

[Marinka1002]

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

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

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

[Vienta]

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

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

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

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

[Spock]

 

Эх...

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

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

 

 

 

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

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

 

 

 

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

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

 

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

[Vienta]

 

 

Эх...

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

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

 

 

 

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

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

 

 

 

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

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

 

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

 

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

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

[Spock]

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

 

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

 

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

 

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

 

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

[Сергей]

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