...если надо подробности,напишу...

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

Не понятно: какая СУБД вас интересует; для каких задач тестирования вам требуется изучение SQL.
Однако, для вас будет полезно знание DDL, DML, DCL включая процедуры массового создания/удаления/обновления объектов (пользователей, схем, таблиц, механизмы создания primarykey, заданий ...):
- знание инфоструктуры - это большой плюс (возможно для этого пригодится и знание hibernate) для понимания бизнес-логики;
- важно знать определения форматов данных;
- вам придётся после тестирования приводить базу в исходное состояние;
- возможно придётся выполнять сложные выборки/фильтрацию.
Также потребуется умение создавать и разворачивать backup, знать, как выявлять наличие deadlock, инициировать/читать логи БД.
Для прочувствования проблем параллельного доступа желательно разобраться с TCL.
Хорошо понимать, что такое datasorce, dao, jdbc и изучить работу с клиентами к БД (работать из командной строки скучно).

В частности, если у вас есть амбиции, хорошо изучите сначала что-нибудь одно, например попроще MySQL (очень распространена в использовании), а потом ознакомьтесь по мере необходимости с MS SQL, PL/SQL, DB2. Это пригодится для владения методикой тестирования "белый ящик".

Советую выбрать самую тонкую книгу.

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

Допустим,
событие A: 1 <= x
событие В: х <= 9;
событие С: 10 <= y
событие D: у <= 99

Таким образом количество входных комбинаций 9:
(A и В) и (C и D)
(A и В) и неС
(A и В) и неD
неA и (C и D)
неA и неС
неA и неD
неВ и (C и D)
неВ и неС
неВ и неD

Класс эквивалентности объединяет те комбинации исходов, которые приводят к одному и тому же результату.
Количество классов эквивалентности 2: валидно; не валидно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...ещё надо...

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

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

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

Как пронегативить?

А как вы позитивите?
Например, число календарных дней:
- 31 в июле;
- 31 в августе;
- 30 в сентябре.

Понятна разница в два календарных месяца, когда 1 и 2 даты:
- с 1 июля по 1 сентября (63 дня включительно c начала по начало);
- с 31 июля по 30 сентября (62 дня включительно с конца по конец).

Вопрос 1: если первая дата 30 июля, то какая по вашему вторая дата (в сентябре), которая удовлетворяет условию: разница между датами 2 месяца?

Разница между датами 2 месяца.

Вопрос 2: это вы неряшливо сформулировали свою мысль или как соотносятся между собою даты (date1 > date2 или date1 < date2) действительно неважно?

Плюс даты ... далекого прошлого (смотря какие есть ограничения).

Ага, обязательно надо рассмотреть date1 из до нашей эры и чтоб date2 уже через два месяца из нашей эры было.

В упрощённом варианте задача следующая:

Есть нагрузочная серия из 100 запросов к Системе.
Эти запросы однотипные, (немного отличающиеся по ресурсозатратам на их обрабатку на стороне Системы), одновременно и параллельно запускаемые с Клиента.
Временем передачи (запросы/ответы) по каналу между Системой и Клиентом пренебрегаем.
Система - чёрный ящик, все метрики можно снимать на Клиенте.

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

Отправка на Систему (100 запросов) серии длилась:
- с первого Клиента 4 сек.
- со второго Клиента 2 сек.
Приём ответов из Системы на серию запросов длился соответственно:
- на первом Клиенте 10 сек.
- на втором Клиенте 20 сек.

Требуется оценить интенсивность приёма запросов и выдачи ответов Системой.

Я сомневаюсь в корректности своих расчётов:
1) (100 + 100) / ((4 + 2) / 2) = 200/3 - интенсивность приёма входных запросов системой;
2) (100 + 100) / ((10 + 20) / 2) = 200/15 - интенсивность формирования/отсылки ответов системой;
где на все запросы не было ответов с ошибками.

Подскажите, как это сделать правильно!?

Поясню смысл оценки и проблему:
Система может одновременно обрабатывать N запросов, остальные ставит в очередь длинной K, время жизни запроса в очереди T. Те запросы которые не попали в очередь из-за ограничения на её длинну или превысили время ожидания в ней сбрасываются с ошибкой обработки.
Клиент с момента посылки запроса по тайм-ауту t (не дождавшись ответа) сбрасывает запрос как ошибку обработки.
Одной машиной не создать адекватной граничной нагрузки, на которой ещё нет ошибок обработки. А на нескольких машинах не понятно как считать интенсивности приёма/обработки.

Существуют ли программы по тестированию, которые запускают программу и начинают нажимать на все подряд и вводить какие попало данные и т.д?

1) Ненапряжные для интеллекта и несерьёзные подходы - это для начинающих тестеров-сангвиников.
2) Допустим ТеститКакПопалоПрограмма отработала... Что имеем в результате, если ничего особенного не нашла? Ваша оценка о качестве продукта повысилась?
3) ТеститКакНадоПрограммы не интересуют? Грамотный тест-дизайн не для вас?
4) Можно ли расценивать ваш ответ "защита от дурака" на три вопроса ch_ip "зачем?", как проблему: имбицилы-разработчики не заботятся о собратьях кретинах-пользователях, (которые могут, например, в поле логина или пароля ввести 1000 символов), а дауны-тестеры не додумаются это проверить от чего страдает стабильность...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Собственно хотелось бы узнать
...когда исследовательское тестирование имеет смысл
...как можно использовать исследовательское тестирование?

Фрося, обратите внимание на Exploratory Тesting в нашей реальной жизни.

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

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

Хотите искать смысл там, где он как в сказке Баха?

Есть пример программы - на вход даются 3 числа, на выходе - тип треугольника - равнобедренный, равносторонний, простой.
Как и что будем тестить? :)

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

Знаю, где это задание дают на собеседовании тестерам. :)

Передайте, пожалуйста, туда, где эти задания дают, чтобы они не позорились (а то тестеры, получив такое на собеседовании, будут сразу вставать и уходить искать работу в другой компании) и исправили своё задание:
на выходе следует ожидать одно из 5 значений:
1 - невырожденный треугольник, у которого все 3 стороны равны;
2 - невырожденный, у которого только 2 стороны равны;
3 - невырожденный, у которого нет равных сторон;
4 - вырожденный треугольник;
5 - в случае ошибки ввода/обработки.

Судя по всему

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

и т.д., к сожалению, не все товарищи глубоко понимают суть вопроса о КЭ.
Более того, вы задали 8 (два, но по четыре в каждом) вопросов, а вам ответили на 3 (меньше, чем наполовину) и вы говорите

Спасибо! Оперативно, по существу и, главное, понятно!

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

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

Поясню на вашей задаче. Представляете, если программа будет реагировать одинаково позитивно, т.е. обрабатывать входные негативные значения -430; -200; 320; 530 (типа корректные) как позитивные значения от 16 до 85. Они что, из одного класса эквивалентности?!
А вот и иллюстрация (Problem.java - ящик с проблемой преобразования типов, кстати корректно работающий на интервале [-128; 127]):
public class Problem{
public static void main(String[] args) {
/*Входные значения*/
int [] input = {-430, -200, 50, 320, 530};
for(int i : input){
System.out.print("i = " + i + "; ");
byte age = (byte)i;
if(16 <= age && age <= 85){
System.out.println("Ok: " + age);
/*Блок обработки входных значений, успешно прошедших проверку
...
*/
}else{
System.out.println("Fail: " + age);
}}}}
Результат работы:
i = -430; Ok: 82
i = -200; Ok: 56
i = 50; Ok: 50
i = 320; Ok: 64
i = 530; Ok: 18

Хороший вопрос!