Проверка подчиненного бага
#1
Отправлено 17 октября 2018 - 14:28
Поделитесь пожалуйста своим опытом.
Вопрос такой (речь идет только о ручном тестировании) :разработчики подчинили баг и стоит задача протестировать его. Как стоит проверить:пройти точ в точ шаги указанные в баге и все? Или еще дополнительно к основной проверке всегда надо пройти регрессионные тесты?
#2
Отправлено 17 октября 2018 - 14:55
Что?? Уточните свою задачу)
Как "подчинили"? Да как они могли себе такое позволить..
#3
Отправлено 17 октября 2018 - 15:09
Что?? Уточните свою задачу)
Как "подчинили"? Да как они могли себе такое позволить..
Ну пофиксили баг
#4
Отправлено 17 октября 2018 - 17:52
#5
Отправлено 17 октября 2018 - 20:53
Мини-регресс. Что фикс мог затронуть? Где еще проявлялся баг? Вот все это проверить.
#6
Отправлено 18 октября 2018 - 12:58
Мини-регресс. Что фикс мог затронуть? Где еще проявлялся баг? Вот все это проверить.
Да, но когда начинаешь задумываться то голова кругом начинает идти что вот там надо проверить, а может и вот там, а может и вот там и тд.....Я вот думаю, все таки мы - тестировщики же не в силах все все протестировать, наверное на добропорядочность, опыт и знания разработчиков тоже можно рассчитывать?
Я думаю что вы тоже сталкивались с такой же проблемой что голова кругом идет от того когда начинаешь думать какие регрессы делать, поделитесь пожалуйста опытом вы как то научились останавливать эту параною?
#7
Отправлено 18 октября 2018 - 13:33
Трассировка требований.
Разделение управления тестированием и выполнения тестирования. Это две разных роли, а попытка играть две роли одновременно проверенная дорога в шизу.
Которого из?наверное на добропорядочность, опыт и знания разработчиков тоже можно рассчитывать?
Того который выкатил изменения в прод под лозунгом "в моем коде багов не бывает"?
Или того, который баги перевесил на коллегу находящегося в отпуске?
Или того, который запушил код в чужую ветку и на предложение создать свою, соблюдая naming convention, и влить код туда, ответил, что у него есть множество гораздо более интересных дел (это не считая истерики про тупых QA, которые не могут взять код из ветки, вот-же в 38-м комменте написано из какой)
Или того, который оптимизирует очистку таблицы в БД не задаваясь вопросом кто и зачем писал delete from вместо drop.
#8
Отправлено 18 октября 2018 - 13:42
Я бы предложил разделить ретест бага и проведение регрессионного тестирования. Для ретеста достаточно пройтись по шагам плюс проверить самые очевидные сценарии.
А после этого имеет смысл оценить области, которые могли быть затронуты и заложить отдельно регрессионное тестирование.
#9
Отправлено 18 октября 2018 - 20:52
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#10
Отправлено 19 октября 2018 - 15:09
мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?
Вы можете без ёрничаний и умничаний просто поделиться своим опытом, как вы делаете проверку пофиксинного бага? Пожалуйста.
#11
Отправлено 19 октября 2018 - 15:12
У бага есть шаги, есть результат, есть ожидаемый результат. Повторите ситуацию и проверьте, что ошибка ушла.
#12
Отправлено 19 октября 2018 - 15:48
Он не может, он недавно начал собеседовать кандидатов, и его еще не отпустило.мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?
Вы можете без ёрничаний и умничаний просто поделиться своим опытом, как вы делаете проверку пофиксинного бага? Пожалуйста.
Делаем мы по ситуации.
Разве что полный регресс на каждый багфикс не делаем. Ну опять же, если каждый багфикс не выкатывается на прод персонально, но и там возможны ньюансы.
#13
Отправлено 19 октября 2018 - 16:58
в Гугле есть детектор зависимостей, и после любого изменения кода запускаются только те тесты, которые тестируют функционал который зависит от того кода
старайтесь тоже определять зависимости, только мануально
#14
Отправлено 19 октября 2018 - 19:20
Он не может, он недавно начал собеседовать кандидатов, и его еще не отпустило.Вы можете без ёрничаний и умничаний просто поделиться своим опытом, как вы делаете проверку пофиксинного бага? Пожалуйста.мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?
Делаем мы по ситуации.
Разве что полный регресс на каждый багфикс не делаем. Ну опять же, если каждый багфикс не выкатывается на прод персонально, но и там возможны ньюансы.
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#15
Отправлено 19 октября 2018 - 19:27
Вы можете без ёрничаний и умничаний просто поделиться своим опытом, как вы делаете проверку пофиксинного бага? Пожалуйста.мдааа, а ведь просто надо было проверить баг, видимо, лучше форум спросить, чем баг проверить, как взяли то вас в профессию? Написали бы хоть, что за ПО, сроки, про приоритеты, дедлайна, критичность, ничего не слышали. Сдаётся мне - это кусок г-на, а не ПО. Целую стратегию тестирования сюда привязали, импакт анализ и всякая другая лабуда. Следущая тема будет - что это все такое. Bob3r, а вы не задумывайтесь, а просто бегите от тестирования ибо думающие голову сломят, а не думающие кнопку нажмут. Кстати, у вас разработки свой г-нокод разве не поверяют по линейному сценарию?
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#16
Отправлено 19 октября 2018 - 21:03
Вы спрашиваете настолько странные вещи, что ответ будет еще более странным. Взять и проверить!!
У бага есть шаги, есть результат, есть ожидаемый результат. Повторите ситуацию и проверьте, что ошибка ушла.
То есть регрессивные тесты вы не выполняете совсем для проверки фикса?
#17
Отправлено 19 октября 2018 - 21:15
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#18
Отправлено 21 октября 2018 - 07:11
В целом, Сергей прав - по ситуации.
#19
Отправлено 22 октября 2018 - 11:22
Регресс это набор тестов перед выпуском версии. Сразу после проверки одного бага его выполнять бессмысленно.
В целом, Сергей прав - по ситуации.
вот так и появляются ошибки в головах. Василий, отправлю вас на Вики, там, кстати, очень даже неплохо описана суть регрессионных тестов, и зачем они появились как класс. Регрессионные тесты призваны устранить ошибки работы разработчиков с системами контроля версий. Именно так, во времена когда не было ГИТа, мержы разных веток вызывали головную боль у всех участников процесса разработки, так как разработчики плохо работают с чужими изменениями. С появлением ГИТа, жизнь стала проще, так как система очень хорошо сама разруливает конфликты изменений одного и того же файла, остались только конфликты изменения оного и того же куска кода.
#20
Отправлено 22 октября 2018 - 12:47
Регресс это набор тестов перед выпуском версии. Сразу после проверки одного бага его выполнять бессмысленно.
В целом, Сергей прав - по ситуации.вот так и появляются ошибки в головах. Василий, отправлю вас на Вики, там, кстати, очень даже неплохо описана суть регрессионных тестов, и зачем они появились как класс. Регрессионные тесты призваны устранить ошибки работы разработчиков с системами контроля версий. Именно так, во времена когда не было ГИТа, мержы разных веток вызывали головную боль у всех участников процесса разработки, так как разработчики плохо работают с чужими изменениями. С появлением ГИТа, жизнь стала проще, так как система очень хорошо сама разруливает конфликты изменений одного и того же файла, остались только конфликты изменения оного и того же куска кода.
И проблема переформатирования кода. gitу рвет крышу когда 1 длинная строка превращается в 3 коротких
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных