Тестирование скорости и надежности (load/stress/performance testing)
Тестирование опыта пользователя (usability testing)

Таки не скорости и надежности и не опыта пользователя (который вообще UX).

Но вообще:
1. Гугль все еще не переплюнут.
2. "Общество без цветовой дифференциации штанов не имеет цели. А если нет цели - нет будущего" (с). Вопрос цели все еще не понятен.

Я говорю что не уверен что это хороший метод. Все.

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

Это уже BDD какой-то получается. В любом случае и те и те проверки стоит скорее называть "rejection checks" а не "acceptance tests", как это принято. По смыслу корректнее получится. И в любом случае это все еще недостаточные процедуры.

ручное нагрузочное тестирование

Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.

Я жажду подробностей этого извращения.

http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php

Это где-то очнь далеко от тестирования. Но вообще можно и как фб делать - нагрузки сразу на живых пользователях проверять.
Главное чтобы мозг рака вот до такого не добрался (а необремененный знаниями и перенасыщенный терминами мозг может): http://loadstorm.com.../happy-new-year

Виды контроля качества должны выбираться исходя не из типа ПО, а в первую очередь из уровня культуры разработки в компании. Во вторую очередь исходя из заранее заданных требований к атрибутам качества ПО. А веб там или не веб - дело 100500-ое. "Там где моют руки - там все нормально."

Я боюсь все еще сложнее и волшебный ответ как всегда - "there is no silver bullet for this problem".
Опять же - "контроль качества" это странная фикция, просто потому что "Там где моют руки - там все нормально", например. С другой стороны, "качество" это субъективное понятие и активность тестировщика по выявлению нужных субъектов и выявлению их же нужд она +/- всегда нужна. Опять же - опеределение атрибутов качества которые нас интересуют вопрос зачастую вполне обсуждаемый: http://thetesteye.co...acteristics.pdf

Я не уверен что пытаться собрать и упорядочить over 9000 терминов это хороший способ что-то понять.

А причина всему одна...

Эти споры баг/не баг возникают потому что баг (дефект, проблема?) - понятие субъективное. И возникает оно когда ожидания одного лица отличаются от увиденного. Второе еще можно жестко зафиксировать, а первое никак, т.к. оно у разных лиц разное и, более того, еще во времени меняется. Usability баги тому отличные примеры. А дальше начинается social science woodoo со всякими Парадоксами Эрроу и другими интересными штуками, косвенно имеющими отношение к тестированию. Ну и согласно тому же social science woodoo приходится применять соответствующие примеры - контекст, ограничение влияющих лиц и т.п.


ЗЫ: Я к тому что ch_ip прав - для производителя телефонов косяки железа для одной модели это очень серьезная проблема, т.е. баг.

Жизнь у бага несколько иная, чем у железячного косяка.

Опять же - it depends. Как ни странно у железячного косяка и у бага есть много разных способов как прожить свою жизнь. iPhone4, например, ничего нигде не меняли. Мучения Symbian отдельная история того как одна маленькая, но очень замечательная ось пыталась мутировать подстраиваясь под изменившиеся требования реальности (epic fail в итоге, а в целом баги/дефекты/проблемы мешали).

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

Это лишь один из возможных вариантов.

А другие какие?

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

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

ЗЫ: Overquoting FTW

А я и не писал, что если не могут ответить, то это хорошо. Это плохо, только вопрос в том, где оно плохо. Не факт что в архитектуре.

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

Это лишь один из возможных вариантов.

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

Так вот и получается, что бага все-таки локализована была неправильно

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

Ну а вообще, дефекты вида "Не отрабатывает ajax-запрос на записях с NULL в таблице REFERENCES" нравятся разработчикам на порядок больше, чем описание "крутится круглый значок и ничего не появляется". Хотя конечно всегда приходится искать баланс между своим временем и трудозатратами разработчиков.

Баги вида "НИЧЕГО НЕ РАБОТАЕТ!" (общий случай бага "крутится круглый значок и ничего не появляется") это в худшем случае совершенно бесполезная паника (читать как "вредительство"), а в лучшем просто флажок вида "копать тут". ответ на вопрос кому копать во многом зависит от задач, которые ставятся. Если нужно посмотреть (поверхностно) как можно больше в сжатые сроки - тогда копать разработчику (тут, правда, предполагается что его время не казенное). Если нужно искать проблемы, причем проблемы серьезные - копать тестировщику.

Конечно :) Писать код намного проще :)

Смотря какой

почему именно на перле?)
мало ли кто с чем и как работает то)

Потому что читать я его могу. Писать на нем желания не возникает от слова "вообще".

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

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

Вы не поймете если вы занимаетесь только автоматизированным тестированием.

Я занимаюсь очень разным тестированием. В том числе не очень автоматизированным тестированием в местах где GUI не светит.

Не знаю)
возможно, но сомнительно.

"Я могу печатать до 9000 знаков в минуту, правда фигня какая-то получается" (с)

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

Вы не поверите, но читать код и писать код это две большие разницы.

ЗЫ: У меня нет должностной инструкции. У меня теперь нет обязанностей? Или есть? Можно я буду считать что мои обязанности это кушать пончики и смотреть телек? "Если в ваши обязанности не входит..." - аж ругаться хочется от такого рудимента.

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

Основной инструмент тестировщика это его мозг. Все остальные инструменты применяются когда мозга уже явно недостаточно (я не про наркотики!)

но когда умеешь читать, хочется попробовать писать и т.д.

Писать на перле? Боженька упаси!

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

надеюсь понятно обьяснила.

Вот это, кстати, я категорически не понимаю.

То кем оно обнаружено не важно.
С другой стороны не очень понятно зачем пихать в CI всякую ерунду, которая не имеет значения.

И severity тоже не стоило. Не у всех есть. Да и заказчик понятие растяжимое. А менеджера вообще может и не быть.

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

Если у вас много жалоб пользователей на какую-то проблему, которую вы считаете незначительной, то, возможно, у вас просто что-то не так с приоритетами и стоит пересмотреть не только одну эту проблему, но и аналогичные, если есть. Точно так же с заказчиком. То что заказчик чего-то не нашел, а нашли другие не должно влиять на приоритет. И vice versa. Т.е. если оно обнаружено заказчиком и это влияет на приоритет, то или вы не пытаетесь осознать нужды заказчика или кто-то прячет от него аналогичные проблемы (есть еще много вариантов, но это долго перечислять).

В первую очередь они нужны чтобы получать более качественные сборки. Все. Гарантий что ничего не поломалось они никогда не дадут.

То кем оно обнаружено не важно.

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

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

Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.

(с) Velocity is Killing Agility by Jim Highsmith

Хотя... who cares?

stmark, ящетаю не стоит нам скатываться в обсуждение того чем severity от priority отличается (это уже бюрократия, а не тестирование). Тем более что по работе я с первым вообще последние года четыре практически не сталкиваюсь. Договорились что не важно кто обнаружил и ладушки.

Wolonter, тогда в чем вопрос? Надо ли править ошибки приводящие к "красной лампочке"? Или надо ли подкрутить автоматическую репортилку с CI?

Я собирался в конце прошлого года, но вдруг стало мало времени. Как появится смогу, но тут никакой конкретики по датам.