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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Допустим,
событие 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 и другие, извините, может я не понимаю ни постановки задачи, ни вашей логики относительно того, что вы делаете (какие комбинации и как должны быть распределены по соответствующим классам эквивалентности? и почему два кейса?).

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

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

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

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

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

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