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

[ksena]

Ок. Попробую по-другому объяснить. Вы на стрельбище. Снайпер. Стреляете в мишень. Будете после каждого выстрела подходить проверять результат? Или сделаете несколько выстрелов, а потом подойдёте и посмотрите?

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

[stmark]

Я понимаю, что вы хотите сказать. По аналогии - у меня есть несколько автоматизированных тестовых прогонов в разных конфигурациях. Я их запускаю и я не кидаюсь писать баг (тест №333 упал) сразу же после того как он упал, а дожидаюсь конца прогона и анализирую результаты и стараюсь понять: разные тесты попадали по одной причине или по разным в рамках одной конфигурации. Далее я запускаю тесты (или они сами запускаются) в других конфигурациях - это дает мне знание о том, где тот или иной тест падает и наводит на мысли от чего это зависит.
Конечно же я начнаю писать баги, когда у меня перед глазами есть полная картина. Это вполне очевидно. По некоторым из них я пишу письма на общий элиас или разговариваю с конкретными разработчиками, прежде чем занести баг в трэкер. Но я считаю, что я делаю это сразу, а никуда не откладываю. Или я не так вас понял?

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

PS: есть кнопка ответить на коментарий

Аха. спасибо :)

[stmark]

Данный пример не подходит под процесс тестирования.

Почему?

Я вам приведу другой пример. Вы чините машину, у вас сломалось 3 детали в разных местах, вы почините одну деталь - проверите, дугую - проверите... или сделаете все 3, а потом только проверите?

Тестировщики не занимаются починкой. Соответственно преобразовываем ситуацию: есть машина, нужно узнать как ведёт себя спидометр. Как вы поступите? Проедите дистанцию побольше, постоянно меняя скорость, поворачивая, тормозя и при этом кратко записывая данные? Или же после каждого поворота\ускорения,будете останавливаться и писать отчёт?

[ksena]

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

В авто тестировании и ручном тестировании есть разница. Я так понимаю мы про ручное говорим.

[stmark]

В авто тестировании и ручном тестировании есть разница. Я так понимаю мы про ручное говорим.

Про ручное. В данном случае просто подход одинаков.

[ksena]

Тестировщики не занимаются починкой. Соответственно преобразовываем ситуацию: есть машина, нужно узнать как ведёт себя спидометр. Как вы поступите? Проедите дистанцию побольше, постоянно меняя скорость, поворачивая, тормозя и при этом кратко записывая данные? Или же после каждого поворота\ускорения,будете останавливаться и писать отчёт?

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

[VLana]

Кажется я начинаю улавливать суть проблемы.
Вообще говоря, в данной ситуации невозможно дать определенный ответ.
Баг нужно регистрировать как можно скорее и это бесспорно.
Но любой более или менее опытный тестировщик в любом случае сначала самостоятельно попытается проанализировать проблему.
Подобный анализ помогает
-Не регистрировать баги, которые появились в следствии уже зарегистрированного.
-Оценить критичность бага
-Локализовать...

Исходя из собственного опыта, скажу, что регистрировать сразу стоит баги,которые каким-то образом блокируют работу функционала или те, которые серьезно влияют на работоспособность других функций системы.
Когда мне разработчик отдает функционал, то первое что он ждет, это информации, что там нет критичных багов.
Если они есть, сразу информирую.
Если я не смогла полностью оценить серьезность проблемы я лучше напишу баг. Лучше перестраховаться.
Если основной функционал прошел тестирование, то все последующие замечания (баги)уже могут регистрироваться хоть пачкой, хоть каждый в отдельности. Это не имеет большого значения. Каждому разработчику удобно по своему.
Порядок работы оговаривается устно.
Но тут нужно понимать, если ты продолжаешь тестирование, зная что в функционале есть серьезные проблемы, то как мне кажется, вероятно последующие баги будут следствием ошибок в системе.
Чтобы так делать, нужно хорошо знать систему и отдавать себе отчет в своих действиях.

Немного сумбурно получилось...

[stmark]

Немного сумбурно получилось...

Умничка! :) На самом деле наоборот всё по полочкам разложила. Про критические, а тем более блокирующие баги здесь речи не идёт, уже писал об этом. Когда блокирующий баг обнаруживается, я частенько вообще напрямую к разработчикам обращаюсь и мы вместе разбираемся с проблемой.

[stmark]

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

Не совсем понял Вас. Вроде речь шла про процесс "Тестирование функциональности", а не работа с найденным багом?

[ksena]

Не совсем понял Вас. Вроде речь шла про процесс "Тестирование функциональности", а не работа с найденным багом?

Я не говорю что с ним нужно работать, о нем нужно сообщить вовремя.

[Куатор]

Всё зависит от ситуации.
Если я делаю санити, тогда сначала пробегаюсь по всему функционалу рысцой + записи на бумажке.
Если тестирую новую фичу (уже после санити на неё), то баги оформляю последовательно, один за другим (если много хайных багов, лоу выписываю на бумажку и дальше искать и оформлять по-серьёзней вещи).
Если баг в другой области (не относящейся к этой новой фиче) и не особо критичный - тоже на бумажку. Сначала надо разобраться с новой фичей. Бывает, что девы пишут комменты с задержкой в минуту после отправки бага и приступают к исправлению.
Желательно конечно две машины, чтобы на второй проверять тоже

[Freiman]

u doin it rong!

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

1. Перерыв делается в любом случае, неважно - для тщательной записи или для краткой "пометки"
2. Как уже сказали, важнее не скорость проверки, а качество. Выяснение причин бага может указать на тонкие места в приложении => можно тщательнее протестировать эту область и найти больше проблем.

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

Проблема опытности тестировщика и разработчика. С временем занесения багов никак не связано.

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

Что мешает взглянуть на баг с другой стороны? Только необходимость пройти все кейсы за N часов или еще что-то?

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

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

[stmark]

2Freiman:

Я полагаю ты решил не читать всё обсуждение целиком. Верно? Ибо на твои вопросы я уже отвечал.

2all:

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

Процесс
Нам нужно протестировать приложение, которое состоит из множества функциональностей. Берём отдельную функциональность. У нас для неё есть тест-кейсы, подробные чек-листы, автотесты, etc. Мы по-порядку прогоняем каждый сценарий. Если встречается блокирующий или критичный баг сразу же локализуем и вносим в багтрекер. Если баг средней тяжести, то делаем краткую запись. Через час-два заканчиваем тестирование конкретной функциональности. Теперь у нас есть набор багов и видение всей картины целиком. Локализуем каждый баг, создаём баг-репорты.
Чем это может быть для нас полезным:
1. Можем объединять однотипные баги, которые при локализации мы и не заметили бы.
2. Сама проверка функциональности закончилась очень быстро и мы можем уже создать небольшую отчётность о количестве и качестве ошибок.
3. Все самые серьёзные баги уже в багтрекере, мы не завязли в локализациях всякой мелочи.
4. Мы с не большими исключениями разделили два процесса (прогонка тестовых сценариев и локализация + создание репорта)что вновь даёт нам прирост по времени.

[Freiman]

2Freiman:

Я полагаю ты решил не читать всё обсуждение целиком. Верно? Ибо на твои вопросы я уже отвечал.

Я высказал свое мнение. Если оно с чьим-то совпадает - это неплохо.

2all:

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

Процесс
Нам нужно протестировать приложение, которое состоит из множества функциональностей. Берём отдельную функциональность. У нас для неё есть тест-кейсы, подробные чек-листы, автотесты, etc. Мы по-порядку прогоняем каждый сценарий. Если встречается блокирующий или критичный баг сразу же локализуем и вносим в багтрекер. Если баг средней тяжести, то делаем краткую запись. Через час-два заканчиваем тестирование конкретной функциональности. Теперь у нас есть набор багов и видение всей картины целиком. Локализуем каждый баг, создаём баг-репорты.

Что-то это на Вашу первоначальную позицию не очень похоже :) Сначала Вы говорили про все баги: сначала тестим, потом исследуем и вносим. Теперь - про некритичные.
И всегда ли можно без дополнительных исследований определить - критичный это баг или нет?
А что если тестирование отдельной функциональности занимает 6-8 часов?

Чем это может быть для нас полезным:
1. Можем объединять однотипные баги, которые при локализации мы и не заметили бы.
2. Сама проверка функциональности закончилась очень быстро и мы можем уже создать небольшую отчётность о количестве и качестве ошибок.
3. Все самые серьёзные баги уже в багтрекере, мы не завязли в локализациях всякой мелочи.
4. Мы с не большими исключениями разделили два процесса (прогонка тестовых сценариев и локализация + создание репорта)что вновь даёт нам прирост по времени.

1. Спорное утверждение
2. Кому необходим отчет о 2-часовом тестировании? И сколько времени займет подготовка этого отчета?
3. Тестирование должно быть построено таким образом, чтобы наиболее критичные области проверять в первую очередь
4. Нет ли тут противоречия с фразой "Если встречается блокирующий или критичный баг сразу же локализуем и вносим в багтреке"?

[stmark]

Я высказал свое мнение. Если оно с чьим-то совпадает - это неплохо.

Дык дискуссия - само оно :)

Что-то это на Вашу первоначальную позицию не очень похоже :) Сначала Вы говорили про все баги: сначала тестим, потом исследуем и вносим. Теперь - про некритичные.
И всегда ли можно без дополнительных исследований определить - критичный это баг или нет?
А что если тестирование отдельной функциональности занимает 6-8 часов?

Во-первых, судя по ответам я был неточным, во-вторых, ничто не мешает мне корректировать свои мысли. Мы же ведь не бараны упертые, которые здесь просто для того, что бы стоять на своём, не слушая других. Если ты систему видишь в первый раз. то да, не всегда сожно определить критичность бага, если же не в первый и есть опыт, то практически всегда. Если тестирование отдельной функциональности затягивается, значит мы неправильно разбили приложение на функциональности или не знаем, что такое data testing + автоматизация.

1. Спорное утверждение
2. Кому необходим отчет о 2-часовом тестировании? И сколько времени займет подготовка этого отчета?
3. Тестирование должно быть построено таким образом, чтобы наиболее критичные области проверять в первую очередь
4. Нет ли тут противоречия с фразой "Если встречается блокирующий или критичный баг сразу же локализуем и вносим в багтреке"?

1. Давайте спорить :) Мы прогнали сценарий и видим, что на некоторой странице отсутствуют заголовки, полазали, везде отсутствуют. Записали репорт. А вот если бы дождались окончания тестирования всей функциональности (а нашем случае "добавление объявления"), то выяснилось, что пропадает любой текст, выделенные тэгом [/b]. Просто заголовки то же выделены этим тэгом повсеместно.
2. Устно, словами на вопрос "как ситуация?" можем ответить "пару мелких багов" или "багов тьма тьмущая".
3. Если область не критичная, то это совсем не значит, что там будет меньше критичных багов. На практике как раз их там более всего и бывает, так как критичные части покрываются авто-тестами довольно тщательно.
4. Частота появления этих критичных багов мала, так что спишем на погрешности.

[ksena]

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

[stmark]

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

Как же Вы боитесь что-то упустить! В заметки баг в первоначальной форме записан? Записан. И куда он денется? Убежит? А по описанному подходу мы экономим кучу времени, быстрее вносим критичные баги, не делаем в багтрекере мусорку, которая отнимет кучу времени у всех участников процесса.

[Clauster]

Про 1-10-100-1000 слыхали?

Clauster, а что это такое? Я тоже не сталкивался.

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

[ksena]

Как же Вы боитесь что-то упустить! В заметки баг в первоначальной форме записан? Записан. И куда он денется? Убежит?

И кто о нем знает кроме Вас? Когда он записан у вас на бумажке, разработчик не может на него отреагировать. Если речь не о юзабилити и не о low багах, то считаю что сообщать о них нужно вовремя.

[Clauster]

>Пока вы умалчиваете о найденных багах, разработчики пишут новые. Про 1-10-100-1000 слыхали?

Про "1-10-100-1000" не слышал, буду благодарен, если просвятите.
Видимо в наших компаниях по-разному устроен процесс работы над релизом. Пока я выкатываю баги, разработчики правят предыдущие.
Да и выкатка осуществляется не так и редко.

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

>Это чья аргументация? Ваша?

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

Интерпретация чего?