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

Фотография

Проверка подчиненного бага


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

#1 Dob3r

Dob3r

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

  • Members
  • Pip
  • 27 сообщений
  • ФИО:Dober


Отправлено 17 октября 2018 - 14:28

Добрый день

Поделитесь пожалуйста своим опытом.

Вопрос такой (речь идет только о ручном тестировании) :разработчики подчинили баг и стоит задача протестировать его. Как стоит проверить:пройти точ в точ шаги указанные в баге и все? Или еще дополнительно к основной проверке всегда надо пройти регрессионные тесты?
  • 0

#2 selen

selen

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

  • Members
  • PipPip
  • 102 сообщений
  • ФИО:Сергей

Отправлено 17 октября 2018 - 14:55

Что?? Уточните свою задачу)

 

Как "подчинили"? Да как они могли себе такое позволить..


  • 1

#3 Dob3r

Dob3r

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

  • Members
  • Pip
  • 27 сообщений
  • ФИО:Dober


Отправлено 17 октября 2018 - 15:09

Что?? Уточните свою задачу)
 
Как "подчинили"? Да как они могли себе такое позволить..


Ну пофиксили баг
  • 0

#4 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 17 октября 2018 - 17:52

Проверить стоит согласно стратегии тестирования.
  • 1

#5 aksi

aksi

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

  • Members
  • PipPipPip
  • 182 сообщений
  • ФИО:Ольга Алифанова
  • Город:Санкт-Петербург


Отправлено 17 октября 2018 - 20:53

Мини-регресс. Что фикс мог затронуть? Где еще проявлялся баг? Вот все это проверить.


  • 0

#6 Dob3r

Dob3r

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

  • Members
  • Pip
  • 27 сообщений
  • ФИО:Dober


Отправлено 18 октября 2018 - 12:58

Мини-регресс. Что фикс мог затронуть? Где еще проявлялся баг? Вот все это проверить.

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

 

Я думаю что вы тоже сталкивались с такой же проблемой что голова кругом идет от того когда начинаешь думать какие регрессы делать, поделитесь пожалуйста опытом вы как то научились останавливать эту параною?


  • 0

#7 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 18 октября 2018 - 13:33

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

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

Которого из?
Того который выкатил изменения в прод под лозунгом "в моем коде багов не бывает"?
Или того, который баги перевесил на коллегу находящегося в отпуске?
Или того, который запушил код в чужую ветку и на предложение создать свою, соблюдая naming convention, и влить код туда, ответил, что у него есть множество гораздо более интересных дел (это не считая истерики про тупых QA, которые не могут взять код из ветки, вот-же в 38-м комменте написано из какой)
Или того, который оптимизирует очистку таблицы в БД не задаваясь вопросом кто и зачем писал delete from вместо drop.
  • 2

#8 alexsvn

alexsvn

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

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

Отправлено 18 октября 2018 - 13:42

Я бы предложил разделить ретест бага и проведение регрессионного тестирования. Для ретеста достаточно пройтись по шагам плюс проверить самые очевидные сценарии.

А после этого имеет смысл оценить области, которые могли быть затронуты и заложить отдельно регрессионное тестирование.


  • 0

#9 Сергей

Сергей

    Профессионал

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

Отправлено 18 октября 2018 - 20:52

мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?
  • 1

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


#10 Dob3r

Dob3r

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

  • Members
  • Pip
  • 27 сообщений
  • ФИО:Dober


Отправлено 19 октября 2018 - 15:09

мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?


Вы можете без ёрничаний и умничаний просто поделиться своим опытом, как вы делаете проверку пофиксинного бага? Пожалуйста.
  • 0

#11 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 19 октября 2018 - 15:12

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

#12 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 19 октября 2018 - 15:48

мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?


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

Он не может, он недавно начал собеседовать кандидатов, и его еще не отпустило.
Делаем мы по ситуации.
Разве что полный регресс на каждый багфикс не делаем. Ну опять же, если каждый багфикс не выкатывается на прод персонально, но и там возможны ньюансы.
  • 0

#13 Spock

Spock

    Профессионал

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

Отправлено 19 октября 2018 - 16:58

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

 

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


  • 0

#14 Сергей

Сергей

    Профессионал

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

Отправлено 19 октября 2018 - 19:20

7 лет назад начал, никак не отпустит). Сейчас совсем беда. HR-ы, видимо, сдались.

мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?

Вы можете без ёрничаний и умничаний просто поделиться своим опытом, как вы делаете проверку пофиксинного бага? Пожалуйста.
Он не может, он недавно начал собеседовать кандидатов, и его еще не отпустило.
Делаем мы по ситуации.
Разве что полный регресс на каждый багфикс не делаем. Ну опять же, если каждый багфикс не выкатывается на прод персонально, но и там возможны ньюансы.

  • 0

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


#15 Сергей

Сергей

    Профессионал

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

Отправлено 19 октября 2018 - 19:27

Вы считаете, я просто так задал вопросы про ПО? Кстати, вам плюс, и Вы не псих) Это вопрос на собеседовании?

мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?

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

  • 0

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


#16 Dob3r

Dob3r

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

  • Members
  • Pip
  • 27 сообщений
  • ФИО:Dober


Отправлено 19 октября 2018 - 21:03

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


То есть регрессивные тесты вы не выполняете совсем для проверки фикса?
  • 0

#17 Сергей

Сергей

    Профессионал

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

Отправлено 19 октября 2018 - 21:15

По ситуации
  • 0

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


#18 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 21 октября 2018 - 07:11

Регресс это набор тестов перед выпуском версии. Сразу после проверки одного бага его выполнять бессмысленно.
В целом, Сергей прав - по ситуации.
  • 0

#19 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 22 октября 2018 - 11:22

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

вот так и появляются ошибки в головах. Василий, отправлю вас на Вики, там, кстати, очень даже неплохо описана суть регрессионных тестов, и зачем они появились как класс. Регрессионные тесты призваны устранить ошибки работы разработчиков с системами контроля версий. Именно так, во времена когда не было ГИТа, мержы разных веток вызывали головную боль у всех участников процесса разработки, так как разработчики плохо работают с чужими изменениями. С появлением ГИТа, жизнь стала проще, так как система очень хорошо сама разруливает конфликты изменений одного и того же файла, остались только конфликты изменения оного и того же куска кода. 


  • 0

#20 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 22 октября 2018 - 12:47

 

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

вот так и появляются ошибки в головах. Василий, отправлю вас на Вики, там, кстати, очень даже неплохо описана суть регрессионных тестов, и зачем они появились как класс. Регрессионные тесты призваны устранить ошибки работы разработчиков с системами контроля версий. Именно так, во времена когда не было ГИТа, мержы разных веток вызывали головную боль у всех участников процесса разработки, так как разработчики плохо работают с чужими изменениями. С появлением ГИТа, жизнь стала проще, так как система очень хорошо сама разруливает конфликты изменений одного и того же файла, остались только конфликты изменения оного и того же куска кода. 

 

 И проблема переформатирования кода. gitу рвет крышу когда 1 длинная строка превращается в 3 коротких


  • 0


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

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