По теме... Не?

Неа! признак регрессии - это не то, чтобы новая функциональность или тестирование того, что уже было протестировано, а тестирование так, как это уже тестировалось раньше...

...и то, и то, и то...

Допустим, есть ПО, работая с которым Разработчик:
- ничего не исправил и не сломал
- не исправил, что надо, и сломал другое
- исправил, что надо, но другое сломал
- всё в коде починил, но неадекватно произвёл сборку продукта
Затем ПО передали Тестировщику, который:
- искал, но не нашёл баги
- нашёл баги не там, где их надо было искать
- закрыл актуальные баг-репорты
- не понимая требований, накидал неадекватных баг-репортов
- подтвердил, что ПО работает стабильно как и прежде - криво и хромая
При этом 100% имел место факт тестирования, направленного на проверку ПО с попыткой доказать...
И что?
Это и есть регрессионное тестирование?

Ну вы поняли

SALar, а я не понял - почему одну половину вашего комментария занимает копи-пэст мыслей AnastasiaM88 из коммента выше, а другую - цитаты неуместных определений из области математики, медицины и политологии?

Комментарии по тексту:

...имели значительное количество отказов торпед...1942 год...U-94...причину искали два года...

1940 год - нацисты оккупировала Норвегию, использовали её промышленный потенциал. U-47, U-94 - немецкие подводные лодки. Фашисты, используют территорию Норвегии как базу для борьбы с советским флотом и союзными конвоями.

Далее гуру восторженно резюмирует:

...могли бы и не найти...

но нашли...
Потом был 1944 год - активизация фашистких подлодок на Балтике, задача - уничтожение советского флота на этом участке.

Классическое полное затмение разума в выборе иллюстрации.

Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?

Очевидно, от Тестировщика требуется создать на мбаг репорт с атрибутом «невоспроизводимый». Если потребуется, специально выделят время и ресурсы для попытки его выявления/устранения. Как правило, это в компетенции только разработчиков, а тестеру – только время зря тратить.

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

В отношении «забить на мбагу» возникает дилема:
1) может быть когда-нибудь некритичный мбаг потом и обнаружится Заказчиком, но раз не воспроизводится, то ничего не поделаешь (отмазок в данном случае у службы поддержки Разработчика найдётся предостаточно)...
2) если потом мбаг проявится так, что Заказчик/Пользователь из-за него понесёт серьёзные убытки, то Разработчику, вероятно, мало не покажется - наверняка возникнут серьёзные проблемы со штрафными санкциями, с репутацией...
Здесь самое главное – Разработчику грамотно составить договор с Заказчиком на создаваемое/сопровождаемое ПО... но это за рамками данной темы...

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

Уместно ли считать такое задание некорректно составленным ?

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

Каким инструментом можно протестировать по методу "черного ящика" ? Нужно сделать тест ЭТОЙ программы. Тестировать по принципу "вижу ошибку, записываю"?

Mr_Constantine, мне лично на ЭТУ программу наsрать, я про "вижу ошибку, записываю" для метода "чёрного ящика"... Почему так тупо? Предлагаю усложнить - "где предвижу, там ищу и вижу ошибку, записываю" - вы не возражаете?
PS: для тех, кто знает принципы соответствующего метода, прошу не делать скоропалительных выводов...

А форум для чего создан?

Вопрос сложный.
Какой вопрос, такой и ответ:
1. Для Вас, при этом, кто Вы - никто не знает и знать не хочет.
2. Для поиска Истины, при этом, что Это - никто не знает, но хочет знать.

...я склонна делать все настолько хорошо... до зубовного скрежета...

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

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

Tagira, я понял вашу ситуацию, но вы не описали, как вы (сами или согласно доведённой до вашего сведения инструкции) дифференцируете уровни критичности, а самое главное - что вас беспокоит? Вы, как тестировщик, подробно описали проблему и риски. Допустим, менеджер проекта рассматривает следующие возможные уровни severity: 1-"смертельно"; 2-"опасно"; 3-"возможны проблемы"; 4-"криво". Ну выберите вы 1 или 2 или 3 и что? Самое главное, чтобы он по отношению к вам не видел ни паникёра и ни неадекватного специалиста в сравнении с severities, заданных вами для других багов. Я, как тестер, указал бы 2, а какой Priority задаст менеджер и исходя из каких соображений вас уже не касается, - вы молодец, сделали своё дело, вам спасибо. Судить о решении менеджера будут другие люди, которые, если потребуется, обратятся и выслушают ваше мнение.

Подождите благодарить...
1) Немного критики в ваш адрес: не нравится ни ваша нерешительность, ни терминология типа "выкрутилась"... Похоже на проблемы с рабочей атмосферой, которые влекут параноидальность, перестраховку в мелочах. Уверяю вас, по большому счёту никто (кому по-настоящему есть, чем заниматься) на severity особо не смотрит, если только оно не волшебное. Главное, чтобы чётко и лаконично было описание бага, а не Баллада о баге.
2) Не понятно, почему Лично вы пользуетесь мелко дробленным шагом из 6 вариаций, что это за ноу-хао в процессе обеспечения качества со свободной формой багрепорта? Разве в багтрекере для выбора severity не используется dropdown, предустановленный менеджером с пояснением системы оценок?

Совет: не погружайтесь в нездоровый формализм, а например, добейтесь/убедите менеджера, что для качества программного продукта в части данной проблемной функциональности при создании xml к нему требуется xsd-описание для его автоматической валидации, т.е. девелоперы должны разработать xsd и включить в решение. А вам, как специалисту по "белому ящику", в последствие будет необходимо проверить хорошо ли написана xsd, чтобы надёжно защищать xml от ошибок.

Да подождите уходить от сути дискуссии, переходить на эмоции (со спасибо моему коту, собаке...)!

Molechka, обратитесь к исходному вопросу Автора. Коротко его суть: одно приложение создаёт xml-файл с описанием путей файловой системы для... далее следует легенда Автора о данном приложении:

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

Извините, я не понял вашего вопроса:

...с чего вы вообще взяли, что ее легенда - нечто огромное и не лаконичное?..

Я ничего не говорил о легенде Автора, она говорит сама за себя!

Отбросим эмоции, поговорим как специалисты (я ни на что не претендую, кроме как подумать).

Мой кругозор подсказывает следующую Легенду: имеет место интеграция с другим приложением, использующим xml от первого, и, вероятнее всего на стороне второго валидируется корректность входных данных.
Вопрос: Molechka, если вы - тестировщик второго приложения и гарантируете, что оно корректно обрабатывает/находит ошибки входного xml (в противном случае вы будете виноваты, если из-за ошибки будут удалены, например, системные каталоги и т.п.), то какое severity должна задать Tagira багу, как тестировщик первого приложения, создающего некорректный xml?

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

...уж прям совсем...не слушайте его!..
...поддерживайте дружелюбную атмосферу на работе...

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

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

Хорошо бы, если кто-то кое-чему научился...

Тест-Суйте...

Тэшт шьют

Задача группы: полное покрытие требований тестами через интерфейс.
Состояние проекта автоматизации: на каждое требование есть тест
Дальнейшие действия: усложнять сценарии.
Вопрос: Как расставить приоритеты?
Я хочу, чтоб на этот вопрос мне ответили аналитики и ручные тестировщики. Они, в свою очередь, спрашивают: "А на что уже есть тесты?"
Проблема: каким образом организовать коммуникацию?
...Моя версия - выделить специально обученного мануал тестера, обучить тест дизайну для автоматизации и сделать его междумордием...

Судя по вашим словам ни аналитики, ни ручные тестеры о вашей автоматизации ранее ничего не слышали, вы с ними свою деятельность не согласовывали, им ваша автоматизация по-барабану.
Из этого следует вопрос: для чего/кого существует и кому в помощь были созданы 600 тестов?
И почему вдруг сейчас, когда вам захотелось усложнять сценарии, расставить какие-то приоритеты... с какого перепугу это за вас должны сделать аналитики и ручные тестировщики, на хрена им надо это и ваша навязчивая коммуникация?
Междумордие - это между вашей и чьей? Не распространяйте самооценку на других людей, особенно на тестеров - это такие ребята, на которых как сядешь, так быстро и слезешь.

Дано:400 качественных требований в вики;баги и таски ведутся в JIRA;600 тестов через интерфейс (Selenium, Java, git)
...
Задача группы: полное покрытие требований тестами через интерфейс.

1. Хорошо если ваши 400 качественных требований ассоциированы c use-case (ранжированы по рискам, важности и т.п.), ещё лучше, если ваши 600 тестов ассоциированы с test-case, совсем прекрасно если вы и все тестеры отлично знаете прикладную область, архитектуру системы, её информационную структуру, событийную модель интерфейса... Раз вы сказали, что ваши требования качественные, - это здорово, - значит вы их протестировали и как минимум уже заготовлены чек-листы...
2. Похоже ваша система сложная. А вы уверены, что ваша задача полного покрытия требований достижима? Хорошо себе представляете расчёт метрики, не путаете с покрытием функциональности, опирающейся на покрытие кода?
3. Что будет с вашей первой сигнальной системой, если смешать зелёный и жёлтый? Однако, какие капризные у вас тестеры и аналитики...

kitsune, чтобы, не флудить, типа:

У тестеров попросить инфу, какие области наиболее рискованные ("В какой функциональности в каждом релизе Вы находите больше всего багов? ...")

будьте внимательнее, например, следует увидеть в постановке/описании вопроса автора:

Уже сделано: 1. Пишутся тесты на дефекты, на области где дефектов много.

То, что вы советуете автору о расстановке приоритетов (упорядочить) требованиям:

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

очень маргинально. Но, когда вы предлагаете в связи c вышесказанным:

Продумать, как мотивировать выбранный порядок

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

1. ...Архитектуру программисты...
2. Система для меня - сложная. Полное покрытие недостижимо, но стремиться надо, для минимизации риска рекгрессии, который высок, так как связность кода высокая, следавательно покрытие кода мало кореллирует с покрытием функциональности.

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

Вопрос такой - что можно считать модульным тестированием?

Ответ такой: что посчитаете необходимым. Обычно (чаще всего что я видел\слышал, о чем говорят...

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

Допустим, кому, как писать и контролировать качество тест-кейсов проехали, несмотря на следующие трудности:

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

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

...чем таким нужно прославиться...какой промежуток времени, чтобы быть допущеННЫ к написанию собственных тест кейсов?

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

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

Хорошо бы расширить тему ответом на вопрос: "каковы должны быть причины, из-за которых нельзя обойтись без тест-кейсов?"
Кто-нибудь может исходному теоретическому вопросу помочь обрести практический смысл?

Пишу сейчас свои первые тест кейсы. По чужим работю уже с пол года, примерно. Что посоветуете при написании? Давайте составим 5 золотых правил для тест кейсов.

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

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

1.Как определить, что является дефектом ПО, а что не является?

Это зависит от того, как составлен договор на разработку/сопровождение, т.е. на что Заказчик вправе предъявить претензии к Разработчику, включая штрафные санкции. Остальное - пустое словоблудие (т.е. вам, начинающему, можно не заморачиваться на эту тему).

2.На что Вы бы обратили внимание в первую очередь при тестировании социальной сети?

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

3.Опишите основные виды тестирования.

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

...
12) насколько у вас модульные автотесты? можно ли запустить любой тест отдельно? Можно ли запустить тесты только на часть системы?
14) кто умеет запускать автотесты и понимать их результат?
...
18) позволяет ли код вашего приложения автоматизировать его или приходится искать обходные пути?

ch_ip, прикиньте, 19 июня a.dobrinina пишет, что руководство поручило ей подготовить самооценку её автоматизации (типа срочно помогите).
Все, кто и как смогли оперативно, что-то сделали для её анализа.
Ваша инициатива, спустя неделю (26 июня), не то, чтобы своевременна, но и как бы неадекватна...
Вопросы:
1. ch_ip, уточните, пожалуйста, ваш вопрос № 13 ?!
2. ch_ip, скажите, пожалуйста, с кем вы ведёте диалог и на какую тему, задавая свои вопросы ?!
2.1 Например, a.dobrinina спрашивает, как оценить "выгодны ли нам автотесты, которые мы пишем?" Вы это видите/слышите? Они пишут автотесты! А ваш вопрос № 18: "позволяет ли код вашего приложения автоматизировать его..." - к чему или к кому ?!
2.2 Допустим, если ответить на ваш вопрос № 18 "Нет, не позволяет", тогда какой смысл в ваших предыдущих (почти двух десятках) вопросах ?!
Просьба: ch_ip, беда какая-то, ваш предыдущий комментарий занял много места, а толку? Будьте, пожалуйста, кратки, точны и логичны, высказывайтесь по теме, не сомневаюсь, что вы - Специалист!

Подскажите: на что можно протестировать веб-страницу уа.ги?

Подсказка_1: проверьте на кросс-браузерность.
Подсказка_2: в IE.9 и GC.27 - FAIL, а в FF.21 - OK.