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

[Clauster]

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

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

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

1. Баги объединять крайне не рекомендуется
2. Проверка может закончиться ещё быстрее, если обнаружить критичную проблему, при которой дальнейшая проверка не имеет смысла.
3. См. выше
4. См. п.2 Плюс ко всему, для локализации всякой мелочи вам может понадобиться восстанавливать различный контекст, что потребует в разы больше времени, нежели делать всё по ходу - допустим, вы тестируете инсталляцию сложной системы.

[barancev]

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

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

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

[LeshaL]

2LeshaL:

>Что касается всего остального, так я считаю, что гонять тесты которые не находят баги или не имеют цели найтии их - вот это точно пустая трата времени.

Цель тестирования найти баги? Может я конечно и не прав, но мне всегда казалось, что конечной целью тестирования является проверка работоспособности тестируемого объекта. А если ни одного бага не найдено, значит тестировщик зря работал?

Цель тестирование не только найти баги, Clauster уже тут упоминал одну из важнейших целей - дать информацию всем заинтересованным товарищам. Но мы ведь говорим сейчас о ситуации когда баг не то что есть, но и уже найден (но ещё не препарирован должным образом). Но теперь, я уже понял о чем вы хотели сказать, что и описал в прошлом моём коменте. А по поводу информации - большинство заинтересованых товарищей (во время разработки, а не на финальной стадии, при которой все согласны, что баг надо писать сразу же) - они заинтересованы в том, чтобы были найдены баги. И никого кроме тестера (и возможно его начальника) не волнует были ли прогнаны все тесткейсы или не все и сколько на это ушло времени.

[Freiman]

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

а если тестировщик находит баги быстрее, чем программист их правит? :)

[stmark]

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

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

При чем тут релиз? В исходном сообщении об этом не упоминается.

Это был ответ на фразу "пока Вы умалчиваете о багах, разработчики пишут новые". Ок, если не нравится релиз, то напишу просто "процесс". У нас не бывает так, что тестируемое приложение меняется во время тестирования, даже исправления, если не критичные, попадают лишь по завершении этапа тестирования.

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

Интерпретация доводов, которыми руководствуются другие тестировщики. Сам же я почерпнул их из статей, обсуждений, книг, etc.

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

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

1. Баги объединять крайне не рекомендуется
2. Проверка может закончиться ещё быстрее, если обнаружить критичную проблему, при которой дальнейшая проверка не имеет смысла.
3. См. выше
4. См. п.2 Плюс ко всему, для локализации всякой мелочи вам может понадобиться восстанавливать различный контекст, что потребует в разы больше времени, нежели делать всё по ходу - допустим, вы тестируете инсталляцию сложной системы.

1. Объединяются не баги, а разрозненные "недобаги" в один полноценный баг
2. Дык вот поэтому очень важно проверить функциональность целиком как можно быстрее, а не копаться в одной её части по полчаса
4. Согласен, когда повторить крайне затруднительно, то стоит всё записывать сразу. Но в подавляющем большинстве случаев мы имеем объект в лёгкую возвращаемый к исходному состоянию.

2ksena:

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

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

[stmark]

Знаете, что самое любопытное в этой дискуссии? То, что правы обе спорящие партии :)

Нейтралитет это здорово. Но как бы всё-таки поступили Вы, если бы пришлось одному проводить ручное тестирование? :)

[ksena]

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

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

[Clauster]

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

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

У меня на столе всегда лежит блокнот, который я использую во время выполнения сценариев. Баги, которые относятся непосредственно к test area заносятся сразу, периферийные в блокнот и потом выясняется, известная бага или нет. Хочу ещё отметить, что тест-кейсы я не гоняю, у меня вообще нет тест-кейсов в классическом понимании. Но это не то разделение процессов, о котором вы говорите.

При чем тут релиз? В исходном сообщении об этом не упоминается.

Это был ответ на фразу "пока Вы умалчиваете о багах, разработчики пишут новые". Ок, если не нравится релиз, то напишу просто "процесс". У нас не бывает так, что тестируемое приложение меняется во время тестирования, даже исправления, если не критичные, попадают лишь по завершении этапа тестирования.

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

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

Интерпретация доводов, которыми руководствуются другие тестировщики. Сам же я почерпнул их из статей, обсуждений, книг, etc.

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

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

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

Проблема в том, что программисты тоже не могут, речь не о внутреннем устройстве ПО. Это головная боль Product Owner или похожего(-их) по роли людей.

1. Баги объединять крайне не рекомендуется
2. Проверка может закончиться ещё быстрее, если обнаружить критичную проблему, при которой дальнейшая проверка не имеет смысла.
3. См. выше
4. См. п.2 Плюс ко всему, для локализации всякой мелочи вам может понадобиться восстанавливать различный контекст, что потребует в разы больше времени, нежели делать всё по ходу - допустим, вы тестируете инсталляцию сложной системы.

1. Объединяются не баги, а разрозненные "недобаги" в один полноценный баг
2. Дык вот поэтому очень важно проверить функциональность целиком как можно быстрее, а не копаться в одной её части по полчаса
4. Согласен, когда повторить крайне затруднительно, то стоит всё записывать сразу. Но в подавляющем большинстве случаев мы имеем объект в лёгкую возвращаемый к исходному состоянию.

1. На моей практике такие случаи можно пересчитать пальцами одной руки. Для меня очевидно, что прогон кейсов в данном случае выполняется поверхностно.
2. А вы не копайтесь, обратитесь к разработчику, который это делал.
4. Вашем контексте, возможно, у меня наоборот.
Смысл в чем, не в том что такой подход лучше или хуже, а в том, что один подход хорош для одного контекста, а другой для другого. На это намекал Алексей Баранцев. И я не спорю и не переубеждаю, я предлагаю альтернативные варианты, для которых ваш подход может не сработать. [тут должен быть текст про context driven testing school, но лень писать, информации в сети довольно много]

[astenix]

>Можно не воспроизвести (вы же первым делом баг воспроизводите при обнаружении, нет?!).

Если баг не воспроизводится то о нём тем более не следует сразу же сообщать. А стоит внести в заметки и отложить для дальнейшего рассмотрения. Или я не прав?

Это полностью зависит от вашего окружения.

В моем окружении о багах надо сообщать максимально быстро. Иногда я нахожу баг, иногда только тень или намек, и не знаю, баг там или нет.

Бывали компании, в которых меня ругали и пинали за то, что я сообщаю "о всякой ерунде" :) Там процесс был очень, сцуко, жёсткий, международные команды в разных концах света, программисты принимали на рассмотрение только те баги, которые можно было таковыми назвать исключительно на основе анализа требований. Поэтому менеджер тестировщиков очень тщательно всё фильтровал по три раза, чтобы выпустить на багтрекер клиента только сообщения о "стопудовых" багах. Мелкие же почти что игнорировались.

Но потом я подрос, и сам стал пинать в ответ на "носют тут всякую ерунду", а также выбирать, с кем работать.

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

Если от вас требуют сообщения только о "настоящих багах", и осуждают за "ненастоящие" - то вы правы, надо делать заметки, перепроверять, и тыды. В другом окружении и в других обстоятельствах вы будете полностью, тотально, уничтожающе неправы :)

[astenix]

С какой целью вы тестируете - прогнать тест-кейсы не отвлекаясь?

А это бывает нередко :)

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

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

[ksena]

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

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

[Clauster]

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

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

потому что автоматизация дорогая штука

[barancev]

Знаете, что самое любопытное в этой дискуссии? То, что правы обе спорящие партии :)

Нейтралитет это здорово. Но как бы всё-таки поступили Вы, если бы пришлось одному проводить ручное тестирование? :)

Это не нейтралитет, я предложил win-win решение, позволяющее с одной стороны не отвлекаться, а с другой стороны не откладывать.
Почему я должен следовать придуманным искусственным ограничениям и искать решение в рамках этих ограничений?
Одна из вещей, которую должен научиться делать каждый тестировщик -- не следовать предложенным правилам, а нарушать их с пользой для себя.
Кстати, эту идею я навсегда запомнил после предыдущего тренинга Майкла Болтона, когда в одной из игр на этом тренинге я увидел, что одна из команд выиграла ровно потому, что они сумели нарушить правила игры.

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

Но у такого моего поведения есть и более глубинная причина.
Дело в том, что при тестировании я протоколирую не только дефекты, но и разную другую информацию.
Соответственно, я выбираю такой инструмент, в который мне удобно всё это записывать.
А потом часть этой информации переносится в баг-трекер, другая часть -- в систему управления тестами, третья часть -- в вики, четвёртая часть преобразуется в запросы аналитикам по уточнению требований, пятая часть потом будет включена в отчёт о тестировании в виде отмазок ("это не было протестировано потому что...") и т.д.

[Vasiliy]

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

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

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

Понятно. Сталкивался, но в таком названии раньше не видел.

[Vasiliy]

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

А менеджера проекта или Product Owner, как уже упомянул Clauster, Вы уже в расчет не берете? Только разработчики и тестировщики? А то, что Product Owner только что вернулся от заказчика и эта ваша мелкая бага уже является мега-фичей всего продукта, Вы не думаете?

[barancev]

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

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

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

Информация к размышлению:
http://www.developse...anny-of-always/
http://www.stickymin...p?F=S3223_COL_2

[Clauster]

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

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

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

Информация к размышлению:
http://www.developse...anny-of-always/
http://www.stickymin...p?F=S3223_COL_2

А что тут размышлять? Болтон выступает в роли капитана очевидность, а в формулы подсчета, я, если честно, не верю - на практике все гораздо сложнее. Своей головой надо думать прежде всего.

[Drag]

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

Неплохой вариант, но в данном случае при большом объеме работ и отвлекающих задач вполне возможно просто потеряться либо просто забыть что имелось ввиду под таким "посланием самому себе". Я например, если нахожусь в процессе и обнаруживаю что то, то сперва смотрю на приоритет этой вещи, затем не было ли подобного либо связанного в баг трекере(такое часто встречается в нашей компании, т.к. работает отдел поддержки и от них тоже идет поток информации), только и потом решаю что с этим делать - сразу занести, либо отложить на потом.

А что тут размышлять? Болтон выступает в роли капитана очевидность, а в формулы подсчета, я, если честно, не верю - на практике все гораздо сложнее. Своей головой надо думать прежде всего.

Желательно рассуждать с точки зрения полезности действий для проекта, т.к. своя голова не всегда может помочь (не знаю как у остальных но иногда из процесса тестирования вообще сложно вылезти) и здесь с оценкой приоритета\важности тоже можно промахнутся. Конечно в некоторых ситуациях легче сделать "пометку" и забыть про нее или иногда даже отдать ее сразу на правку (хотя за такое можно и отхватить), а затем уже заниматься бумажной волокитой.

[VikaCP]

>неужели это занимает меньше времени чем оформить баг?

Тест-сессия проводится с чётко обозначенным окружением. Так что эта информация фиксируется до начала такой тест-сессии и записывать её не требуется.

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

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

Я так понимаю, что у вас налажен процесс тестирования, основанный на сессиях, так?
Просто если это верно, то тогда ваш подход к описанию багов оправдан самой теорией.
В общих чертах теория тут
Просто если сессия по стандарту длится до 2 часов и имеет какую-то четко обозначенную цель, то, зачастую, баги действительно оформляются после ее окончания.
Создатели теории session based testing (Джеймс и Джонатан Бах) выступали на одной из конференций Star West с однодневным семинаром на эту тему. Мне посчастливилось на нем побывать. Так как в компании, на которую я работаю, exploratory тестирование широко применяется, я даже пыталась внедрить сессии в свою работу, однако это было принято командой без особого энтузиазма. В результате от такой практики мы отказались, так как видимого улучшения результатов работы нам она не принесла. Но тем не менее, такой подход к тестированию хорош и работает, что доказано временем.
В таком случае задержка оформления бага в 2 часа, на самом деле, не существенная и, в общем случае, на скорость фикса не вилияет. Конечно, если это мега критичный баг и до релиза осталось пару часов - история другая. Но, как я понимаю, автор всего лишь за то, чтобы разумно подходить к вопросу срочности.

Оличительная особенность сесси в том, что для нее формулируется цель и в ней трекается время, которое работник затратил на непосредственное достижение цели (например, протестировать on-demand scan антивируса на XP). Время, затраченное на разговоры с программистами, на внесение бага в трекер и на перекур считается временем, затраченным "впустую". И, кстати, каждая сессия, помомо цели, времени на выполнение и задач, еще характеризуетсяи определенной програмной и системной средой.

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

[Natalya Rukol]

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

Это слово было в UI с самого первого билда. Никто не заводил, потому что ОЧЕВИДНО что и сами поправят.

Для меня это бесценный и наглядный опыт. Баги надо заводить СРАЗУ, иначе глаз замыливается.

И естественно, это не значит "заводи багу как только где-то что-то сломалось". Все дефекты надо ЛОКАЛИЗОВЫВАТЬ. И сразу же ЗАВОДИТЬ :)