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

Тестирование REST API
онлайн, начало 29 июля
Школа для начинающих тестировщиков
онлайн, начало 25 июля
Python для начинающих
онлайн, начало 26 июля
Автоматизация функционального тестирования
онлайн, начало 26 июля
Фотография

Насколько вы углубляетесь в найденный 'явный' баг?

Ручное Тестирование

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

#1 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

Отправлено 07 Октябрь 2015 - 07:46

Возник вопрос из - за спора с сотрудником.

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

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

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

По моему такой подход более эффективен.

А у Вас какое мнение по этому вопросу?


  • 0

#2 Freiman

Freiman

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 414 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 07 Октябрь 2015 - 07:53

У меня мнение:

1. Если баг стабильно воспроизводится - выясняем точные шаги для воспроизведения.

2. Углубляемся внутрь. Если причина на поверхности и быстро находится - ок.

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

Пытаться докопаться до сути, может, и полезно на некотором "сферическом в вакууме" проекте, но в общем случае - чем быстрее о проблеме сообщили разработчикам, тем лучше.


  • 3

#3 clipsa

clipsa

    Специалист

  • Members
  • PipPipPipPipPip
  • 520 сообщений
  • ФИО:Ермолаева Ольга
  • Город:Москва


Отправлено 07 Октябрь 2015 - 07:58

ИМХО зависит от ситуации на проекте и самого бага.

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

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

Ну и конечно, от конкретных людей зависит, от их квалификации, настроения, фазы луны и пр.)))


  • 2
Не следует заставлять тестировщиков тестировать быстрее. Что может быть хуже испуганых, усталых, цинично настроенных тестировщиков?
-----------------
Хорошо, когда человек заводит баги. Плохо, когда баги заводят человека (с)
-----------------
Проект для начинающих тестировщиков Хомячки

#4 Molechka

Molechka

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 203 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 07 Октябрь 2015 - 08:09

Не нужно вдаваться в крайности.

 

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

Но и не надо торопиться «увидел, что упало — поскакал заводить», потому что в таком случае вы перекладываете свою работу на разработчика. Допустим, система ломается, если ввести именнго слово «ромашка». Ну, условно. А тестировщик пытается создать описание чая, заполняет его — БАХ, упало. И вот он радостно заводит баг «Нельзя добавить описание к чаю !!11». А это явная ложь, такая гипотеза опровергается за минуту.

 

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

Если тестировщик умеет, он может собрать доп информацию. Если умеет и у него есть доступ к ней. Зависит также и от работы, от компании. Где-то тебя загнобят, что без логов или другой детализации, потому что тестировщики все умеют это делать. А где-то в логам вообще не пустят


  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/

#5 Сергей

Сергей

    Гуру

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

Отправлено 07 Октябрь 2015 - 08:17

Коротко из реалий (все варианты с точным сценарием):

1. если разработчик за стенкой и дедлайн, то сообщить сразу

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

3. если аутсорс, то максимально углубиться в баг, провести код-анализ и потом сообщить с указанием места в коде ошибки и т.п.

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

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

и т.д. и т.п.

 

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

 

Считайте, что вам повезло, что ваш руколь позволяет вам такую роскошь - время.

 

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

 

з.ы. блин, коротко не получилось, однако


Сообщение отредактировал Сергей: 07 Октябрь 2015 - 08:17

  • 0

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


#6 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

Отправлено 07 Октябрь 2015 - 08:44

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

  • 0

#7 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

Отправлено 07 Октябрь 2015 - 08:52

Где-то тебя загнобят, что без логов или другой детализации, потому что тестировщики все умеют это делать. А где-то в логам вообще не пустят

это понятно, но я говорю про явный баг, который воспроизводится всегда.

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


  • 0

#8 Little_CJIOH

Little_CJIOH

    Гуру

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


Отправлено 07 Октябрь 2015 - 09:28

 

Где-то тебя загнобят, что без логов или другой детализации, потому что тестировщики все умеют это делать. А где-то в логам вообще не пустят

это понятно, но я говорю про явный баг, который воспроизводится всегда.

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

 

Который у вас всегда воспроизводится, а у разработчика - всегда нет.

От ситуации все зависит.

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


  • 0

#9 Molechka

Molechka

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 203 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 07 Октябрь 2015 - 09:53

 

Где-то тебя загнобят, что без логов или другой детализации, потому что тестировщики все умеют это делать. А где-то в логам вообще не пустят

это понятно, но я говорю про явный баг, который воспроизводится всегда.

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

 

Если проблема в куках, то, вполне возможно, она будет только у вас на компе.

Вы не покопаетесь, просто опишите. Разработчик пойдет по шагам — а фиг, не воспроизводися.

 

Придет к вам, посидите вместе за компом, найдет ошибку.

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

Разработчик пофиксит и не опишет, что баг был «если только звезды вот так срослись», ну вы жеж выяснили уже, зачем ему вашу работу делать?

 

Проверку отдадут другому тестировщику. Тот такой, чтобы вникнуть в баг, на старой версии сначала проверяет шаги (чтобы точно воспроизвести) — а оно не воспроизводится оО

И как ему теперь понять, исправлено или нет, если он исходной причины не знает?


  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/

#10 vkazar

vkazar

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

  • Members
  • PipPip
  • 128 сообщений
  • ФИО:Виктор
  • Город:Москва

Отправлено 07 Октябрь 2015 - 09:59

У меня был случай, когда разработчик не смог воспроизвести багу.
Сначала баг-репорт был простейшим (т.к. ошибка, как мне казалось, очевидна):
При редактировании почтового сервера организации вылезает ошибка: скрин, лог
Он мне возвращает с резолюцией "не воспроизводится". Я попробовал - и правда что, не воспроизводится. Потом вспомнил, что это было на новой организации. Пишу кейс:
1. Нажать "Добавить организацию вручную"
2. Ввести ИНН любой (я вводил 1111111117 и 9952703211)
3. Ввести любое краткое название
4. Нажать "ОК"
5. Выбрать почтовый сервер

Он мне опять - не воспроизводится. Начали разбираться. В итоге выяснилось, что в его гениальную голову пришло выбрать другую организацию из списка (после добавления она сразу не выбирается, надо найти её в списке)
 
Это я к чему? К тому, что всё от человека зависит. Некоторым и разбор бага не помогает...
Скрытый текст

  • 0

Тестировщик должен быть умнее программиста... ну, по крайней мере, хитрее. ©


#11 alehander

alehander

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

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

Отправлено 07 Октябрь 2015 - 13:33

 

Где-то тебя загнобят, что без логов или другой детализации, потому что тестировщики все умеют это делать. А где-то в логам вообще не пустят

это понятно, но я говорю про явный баг, который воспроизводится всегда.

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

 

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

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


  • 1

#12 Snap

Snap

    Специалист

  • Members
  • PipPipPipPipPip
  • 792 сообщений
  • ФИО:Роман
  • Город:Москва


Отправлено 08 Октябрь 2015 - 08:36

Бывает самому интересно покопаться, чтобы узнать откуда корни растут, чтобы в будущем уже прогнозировать подобные ошибки.

Я до сих пор знаю тестеров, которые ставят баги (не верстки) в стиле "см. скриншот".


  • 0

http://starbugss.blogspot.ru - "Звездные баги", мой блог.


#13 aid

aid

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

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 08 Октябрь 2015 - 08:49

Бывает самому интересно покопаться, чтобы узнать откуда корни растут, чтобы в будущем уже прогнозировать подобные ошибки.

Я до сих пор знаю тестеров, которые ставят баги (не верстки) в стиле "см. скриншот".

 

Я знавал тестера, который "писал" баг репорт так - заголовок - название модуля в котором ошибка. Описание пусто, просто прикладывал видео.


  • 0

#14 Snap

Snap

    Специалист

  • Members
  • PipPipPipPipPip
  • 792 сообщений
  • ФИО:Роман
  • Город:Москва


Отправлено 08 Октябрь 2015 - 08:55

Я знавал тестера, который "писал" баг репорт так - заголовок - название модуля в котором ошибка. Описание пусто, просто прикладывал видео.

Ну, видео, это не так и плохо.


  • 0

http://starbugss.blogspot.ru - "Звездные баги", мой блог.


#15 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

Отправлено 08 Октябрь 2015 - 09:54

 

Я знавал тестера, который "писал" баг репорт так - заголовок - название модуля в котором ошибка. Описание пусто, просто прикладывал видео.

Ну, видео, это не так и плохо.

 

 

Видео то конечно не плохо, но для отчетности или поиска заголовок только с названем модуля не очень информативен )


  • 0

#16 Snap

Snap

    Специалист

  • Members
  • PipPipPipPipPip
  • 792 сообщений
  • ФИО:Роман
  • Город:Москва


Отправлено 08 Октябрь 2015 - 10:02

Видео то конечно не плохо, но для отчетности или поиска заголовок только с названем модуля не очень информативен )

Не спорю, но может это было dekstop-приложение или т.п.?


  • 0

http://starbugss.blogspot.ru - "Звездные баги", мой блог.


#17 aid

aid

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

  • Members
  • PipPipPipPip
  • 445 сообщений
  • ФИО:Николай


Отправлено 08 Октябрь 2015 - 10:07

 

Видео то конечно не плохо, но для отчетности или поиска заголовок только с названем модуля не очень информативен )

Не спорю, но может это было dekstop-приложение или т.п.?

 

 

Приложение было веб и со сложной логикой. Понять в чём ошибка было не возможно вообще, так как основные баги были именно в логике работы приложения.


  • 0

#18 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

Отправлено 08 Октябрь 2015 - 14:04

Подводя итог по вопросу:

У нас принято проставлять время, затраченное на задачу как тестироващиками , так и программистами(для отчетности).

Картина такая :

Затраты времени разработчика на исправление бага - 30 минут

Затраты тестировщика на разбор бага - 1 час 30 минут... На явный баг...

Вот такая эффективность работы...


  • 0

#19 Сергей

Сергей

    Гуру

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

Отправлено 08 Октябрь 2015 - 14:12

И какая эффективность? З/пл разработчика (0.5 ч) и тестировщика (1.5 ч)? Имхо, нормальный расклад.


  • 0

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


#20 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

Отправлено 08 Октябрь 2015 - 14:19

И какая эффективность? З/пл разработчика (0.5 ч) и тестировщика (1.5 ч)? Или кто-то предпочитает по другому вести дело? Имхо, нормальный расклад. Было бы ненормально, если было бы наоборот.

 

ты считаешь эффективность по зарплате?

за эти полтора часа можно было бы найти еще как минимум 5 таких же 'явных' багов, я считаю


  • 0


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




Темы с аналогичным тегами Ручное Тестирование

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

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

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