1) Хорошее уточнение.

2) Связку "удобный UI и возможность генерировать наборы тестовых данных не только с парами" можно считать особенностью. Но отдельно тройки нельзя считать особенностью. Поскольку тройки умеет PICT, набравший львиную долю голосов:

/o:N    - Order of combinations (default: 2)

Правда более 6 на моём железе PICT за сутки сгенерить не смог для 13 параметров по 3-4 значения в каждом (3-way дал три сотни кейсов для файла модели). Впрочем, стресс-тест бесполезный, поскольку на 6-way мало дураков.  Ожидается, что мильён кейсов утилита командной сроки умеет генерить для автотестов - жаль не было в опросе вопросика о % применения для генерации автотестов/ручных.

2) Надо же, какие интересные подробности. Не за всяким обзором софта такой опыт.

PS. Яростно отозвавшегося уволили? Или героя притчи? Вы знаете что-то помимо этого коммента ниже?

клиент выбрал одновременно три значения,( а вы проверяли только пару), и клац, клиент из этого выбора получает баг, приговаривая, wat the fck, и отказывается от системы стоимость в 100к$. выходит: "мы вас увольняем, но вы держитесь, здоровья вам и хорошего настроения"

 

Спасибо за сбор статистики!

" Pairwiser и Hexawise, которые замыкают пятерку лидеров. Эти инструменты подойдут тем людям, которые не умеют программировать. Главными их преимуществами является удобный UI и возможность генерировать наборы тестовых данных не только с парами зависящих значений, а и с тройками, четверками и т.д...

..платным является только Hexawise"

1) Разве программировать надо уметь для пользования другими инструментами, у которых интерфейс командной строки?

2) Почему считаете, что тройки и т.д. их преимущество? 

3) "Hexawise is available for free to schools, open source projects, other non-profits, and teams of up to 5 users from any kind of company"

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

Можно 24 трэкать, если не лень плодить писанину. Можно 3. Можно и один кейс с разными данными. Сомнения-то какие?

Есть способ - пригласить разработчика за комп тестировщика, пусть он потыкает и воспроизведет. Разработчик написал как воспроизводил? Описал свои настройки Хрома, версию браузера, у него тоже El Capitan? Кэширование у провайдера не могло повлиять?

Подозрение скорее всего не верное, что огромных файлов для этого формата не бывает в принципе. Юзкейс из реального мира такой - поток IPTV дампят mplayer в файл на диске с конвертацией в mp4.

MP4 это контейнер. https://en.wikipedia.../MPEG-4_Part_14 Внутрь можно затолкать по разному пожатое видео. Или даже не видео, а что-то иное, соответствующее стандартам mp4. Лучше даже не стандартам, но вашему детектору - валидатору mp4. Ориентироваться надо не на стандарт, а на вашу аппликуху, что она распознаёт как валидный mp4, то и подсовывать.

В постановке нужны уточнения что понимается под загрузкой: "загружать с помощью нашей аппликухи" и "проверить, насколько быстро проходит загрузка". Поскольку скорость этой самой "загрузки" может зависить от того, чем напичкают контейнер mp4. Если аппликуха сетевая и от пропускной способности сети зависит, то узкое место может быть и не в контенте. Тяжелым может быть не только размер, но и компрессия тяжелая. Значит есть смысл задавать разную степень компрессии разными кодеками, нарисовать графики, зависимости.

Тестовые mp4 есть в репозиториях разработчиков открытого софта, например

https://samples.ffmpeg.org/MPEG-4/

В аппликуху как будете скармливать видео? Я бы с помощью curl скормил. Гуглятся репозитории так:

mp4 intitle:"Index of"

4 гига это еще не тяжелое тестовое видео - вон терабайты: http://media.xiph.org/

Самому можно за ночь записать видео с экрана. Если не под Линуксом, а под Win32, то https://ffmpeg.zeranoe.com/builds/, а для понимания опции dshow доустановить http://www.umediaser...reenCapture.zip

Команды записи и конвертации такие, например:

C:\portable\ffmpeg-20160718-450cf40-win32-static\bin\ffmpeg -f dshow -i video="UScreenCapture" -vcodec libx264 -threads 0 f:\tmp\video.mkv

C:\portable\ffmpeg-20160718-450cf40-win32-static\bin\ffmpeg -i f:\tmp\video.mkv -vcodec libx264 -crf 22 -threads 0 f:\tmp\video.mp4

Не-не, я такого не говорил. Минимум шагов не значит абы как, а наоборот тщательная вычистка лишней путаницы.

ах да, конечно четвёртый резон это ass

Василий, расписанная таблица кажется удобнее. Но не быстрей скрина, и не объективней - лишний человеческий фактор.

 

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

 

Стоит! Потому что иначе кто-то будет тратить кучу времени потом, работая с вашим избыточным описанием.

Локализовывать надо не потому, что это интересно, а потому что это работа тестировщика!

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

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

 

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

И что тогда делать?

 

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

Похожий вопрос http://sqa.stackexch...dencing-testing Из ответов зацепило следующее.

0) Шон МакХью делится видеозаписями, демонстрирующими успешное прохождение, чтобы вернуться к ним позже как как оригиналу. 

1) Сбор доказательств навязывается регуляторами в областях типа MIL-STD-2167, telecom TL9000, Sarbanes-Oxley.

2) PSR для исследовательских сессий - Записи больше нужны выполнявшему тесты, а команде только вывод.

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

Ну если тестировщик не может сделать вывод об увиденном, то может он не совсем в теме?

Даже если в теме, вывод может оказаться противоположным. Из соседней темы цитата Баха "Свидетельства очевидцев могут оставить за бортом важную информацию, поэтому слушайте, но не нужно излишней уверенности в чужих словах" http://software-test...ittent-problems

Коммент касается только первого резона прикладывать скрины. Остаются 2 других: как свидетельство ограничений и для регресс-тестирования.

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

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

В-третьих, регрессионное тестирование облегчит скриншот состояния, расцененного как ОК при закрытии issue. 

 

 

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

Ну тогда возникают вопросы к менеджеру по персоналу или начальнику "тестера" 

 

Уметь делать и делать - 2 большие разницы. Не пробовали понять мотивы тестеров, которые ставят баги (не верстки) в стиле "см. скриншот"?

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

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

Углубляться можно в разных направлениях. Одно дело выяснять технические детали типа кук в примере выше. Другое дело сокращать до минимума число шагов, чтобы оставить в описании бага только необходимые. Полтора часа это еще не большие трудозатраты. Если баг воспроизводится при точном выполнении избыточного числа шагов, стоит ли выяснять необходимый минимум? Локализовывать интересно, да, это в характере у тестировщиков, докопаться до причин. Но не правильней ли просить описать причину разработчика, переводя баг в статус ON TESTING?

За качество отвечают разработчики и их начальник, тестировщики только оценивают

Оно чуток не так, когда кейсы пишут не у себя на локалхосте, а чтоб разработчики читали.

"Earlier I asserted that testers can't directly improve quality; they can only measure it. That's true only if you find yourself starting testing too late. Tests designed before coding begins can improve quality. They inform the developer of the kinds of tests that will be run, including the special cases that will be checked. The developer can use that information while thinking about the design, during design inspections, and in his own developer testing"

Но тема не про влияние тестировщиков на качество вообще, а узкий аспект: именно багрепортами.

Прочел десятка два из 80 ссылок в FAQ: отчет об ошибке. Как, что, зачем? Шаблоны баг-репортов - как-то не нашел, что хороший багрепорт должен побуждать разработчика исправлять (видимые ему лучше) похожие проблемы в соседних участках кода и функционала, непосредственно связанных с описанным проявлением, попавшим в сети тестов. 

создайте новую тему о з/п

Ага, поддерживаю.

Без дубины вы ничего из них не вытяните, а у вас её нет.

Дубина есть - принципиальная обреченность продукта, в котором фиксят не более, чем описанные багрепортами проявления ошибок, где extra mile не идут.

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

Кстати, книжку со слоном читал, может потому чувство и возникло. Подчиненной тестировщице тоже давал читать.

извините, с вами говорит человек, очень сильно разочаров...

Неужели в больное попал?

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

Хотелось бы узнать как воспринимают разработчики ваши багрепорты. Насколько часто фиксят не только описанное, но и близкие вещи, связанные сценарии? Отписываются в комментарии, перечисляя смежные пользовательские сценарии, затронутые фиксом? Ведь часто в описании от тестировщика только конкретика по обнаруженному 1 проявлению проблемы, а разработчик (подумав немного и grep-нув код) найдет еще 10 мест. Возможно в системе их все 12 (но два не важны, поскольку раз в тысячу лет их проявление).

Мое предположение, которое выношу на обсуждение - что качества не достичь, если ждать замечаний и фиксить только их. Черным ящиком не выгодно и принципиально не возможно выявить тысячи потенциально проблемных кейсов - такое полное покрытие не обеспечить - то есть проект обречен, если разработчики не станут ловить намеки тестировщиков, по собственной инициативе идя extra mile при каждом баге.