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

Есть нагрузочная серия из 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 (не дождавшись ответа) сбрасывает запрос как ошибку обработки.
Одной машиной не создать адекватной граничной нагрузки, на которой ещё нет ошибок обработки. А на нескольких машинах не понятно как считать интенсивности приёма/обработки.

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

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

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

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

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

эталонное поведение...формы

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

Короче, надо обобщить требования (с учётом специфики слабовидящих пользователей ПК и т.п.), сформулировать/стандартизировать эталонную событийную модель интерфейса для общих форм (регистрации, поиска, почтового сообщения...). Если на просторах software-testing есть тот, кто готов заняться подобным делом, или имеются материалы, которые сообщество могло бы обсуждать/затачивать - было бы здорово!

Организаторы software-testing, у меня есть предложение/просьба:
создайте на вашем портале ресурс для генерации, публичного обсуждения документов типа стандартов, которое сообщество могло бы формировать самостоятельно (если в нашей стране больше, кроме нас, никто этим заниматься не может) для нас же самих: тестеров, специалистов по качеству, (разработчиков и т.п.)!

...функция, класс, метод? Есть языки не объектно-ориентированные, где код пишется в функциях. Есть строго обьектно-ориентированные, где все функции пишутся в классах.

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

какие статические методы есть ?

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

Допустим,
событие 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)Разные ошибки по их локализации:
- в требованиях;
- в документации;
- в архитектуре;
- в алгоритмах/логике/вычислениях;
- в управлении данными;
- в коде;
- в интерфейсе (вы говорите о сайте, тогда копнём проблематику: авторизованный доступ; удобство и кроссбраузерные вёрстка и дизайн и активные сценарии; локаль и информационное наполнение; навигация; валидация ввода; обратная связь; и отдельно защита, быстродействие, устойчивость);
- в интеграции;
- в сборке версии;
- в аппаратуре/окружении;
...
2)Разные ошибки, выявляемые соответственно разными методиками/видами тестирования;
3)Разные ошибки по их критичности;
...
Естественно, прежде чем что-либо серьёзно посоветовать, важно уточнить подробности.

я устроился на временную удаленную работу, связанную с ручным тестированием

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

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

Почему вы хотите обмануть Работодателя, занявшись автоматизацией?
Лучше откажитесь от данного задания, если не хотите работать, т.е. выполнять ручное тестирование.

Насколько я понял...Однако, в ином случае...Мне представляется...

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

План проведения испытаний и test plan - это один и тот же документ?.. По мне - одно и то же...

Предлагаю вашему мозгу такой, адаптированный к вашему теоретическому вопросу, ответ:
Сходство:
- оба - документы и, как ни странно, планы, по идее составляемые на стороне Разработчика
Разница:
- test plan - это по которому тестеры Разработчика "жмакают по кнопкам", и является тем, за что Заказчик не платит, ибо он ему абсолютно не нужен
- План проведения испытаний - это по которому на стороне Заказчика, при приёме программного продукта, специалисты Заказчика "жмакают по кнопкам". На него забивается не так часто как на test plan
Парадокс:
- то, что будет написано в Плане проведения испытаний - по глубине смысла, имеющего отношение к качеству, далеко до test plan

...Спрашивать у программиста смысл имеет...

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

...сохраняет старый функционал, но принцип работы меняет...

Не знаю как вы, - я буду во фрустрации!

Столкнулся с такой мыслью, как правильно протестировать что-то, что сохраняет старый функционал, но принцип работы меняет...

Регрессионное тестирование: "Я вижу твоё желание. Твоя цель здесь. Иди ко мне.".

А если серьёзно:
1)

...возникали некоторые накладки...

1.1 Накладки кто выявил, вы? нет - изучите их как следует (локализацию и проявление).
1.2 Если имеете доступ к системе хранения версий исходников и умеете читать код - проанализируйте, что и где поменяли девелоперы.
1.3 Подготовьте/проведите адекватные тесты, чтобы убедиться - проблема решена.
2)

...что мне первое пришло в голову: убедится в том что все старое работает так же как и работало

2.1 Автоматизированные тесты есть?
2.2 Убедились, что старое работает на старых сценариях и наборах данных - это здорово, но:
2.3.1 Старые наборы сценариев модифицировали?
2.3.2 Наборы данных модифицировали?
3)

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

Нет!
Естественно, они не только чинят, но и ломают. Знали бы где и что - не было бы проблем, поэтому спрашивать у девелоперов: "где в программе баги?" - это для неадекватного тестера. Кстати, девелоперы "под шумок" наверняка, что-нибудь ещё где-нибудь отрефакторили...
<<Тестер, никому не верь!>>
4)

3. Проверять, основываясь на рисках

Нет!
Да - основываясь на плане тестирования (чек-листе, кейсах...)
<<Тестер, проверяй всё, за что отвечаешь!>> (но! заметишь дефект, который пропустил коллега, - быстрее беги к тест-лиду и доложи! а потом с этим коллегой, например, попейте кофе в непринужденной беседе...)

...хочу начать тестировать...PRD нет...напишите список документации, которых я должен составить...

sachok777 задал вопрос об артефактах, с которых, как правило, начинается тестирование, в контексте своей задачи.
Кроме недоумения:
1. от неуместных упреков, типа 'что и как вы там читали?' и комплекса эстетического восприятия UI;
2. от рекомендаций (не по теме вопроса) пересматривать какие-то youtube-ролики;
3. от недовольного хмыканья типа: 'чего и как вы там хотите добиваться? начинайте прямо с функционального тестирования!'
т.е. отсутствия культуры слышать, что спрашивают... я уже давно наблюдаю другую глубокую проблему.

Надеюсь, что многие специалисты с ясной головой согласятся:
- Существуют:
-- методологии управления разработкой (scrum...);
-- методологии разработки программного обеспечения (xp...);
- Отсутствуют (и в этом большая проблема):
-- методология управления качеством;
-- методология тестирования программного обеспечения.
Уверен, что многие специалисты без "каши" в голове понимают разницу между методологией и подходами, техническими приёмами...

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

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

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

Судя по всему

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

и т.д., к сожалению, не все товарищи глубоко понимают суть вопроса о КЭ.
Более того, вы задали 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

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

Есть размерность int, есть размерность byte. Соответственно и набор классов должен быть другой.

Чтобы не путать неопытных читателей типами (особенно размерностями), а яснее донести подход к определению КЭ для числовых значений в общем случае, надо иметь в виду: диапозон (непрерывный или с правилом дискретизации); точность (порядок целой или дробной части с учётом правила округления); формат (представление в соответствии с локалью и единицами измерения и т.п.).

Нестандартных задачек я не боюсь, наоборот с детства люблю их решать.

Linkoln19, пять ваших комментов "Отправлен 05 август 2013": 22:55, 22:58, 23:01, 23:02, 23:03 - многое говорят о частоте ваших бессознательных реакций на потребность в стандартном восприятии объективной реальности и ничего о нестандартности вашего мышления. Чтобы заинтересовать работодателя, начните своё резюме, например с: "В детстве в меня попала молния..."

КЭ это набор значений, который программа ДОЛЖНА обрабатывать одинаково (по требованиям к ней)

Замечание 1: пож-та, не выделяйте регистром слова (например, "ДОЛЖНА"), их смысл не зависит от размера.
Замечание 2: своей иллюстрацией я ничего не утверждал, только хотел понять вашу логику.
По существу: с вашим определением не согласен.

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

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

С ЧЕГО НАЧАТЬ... Возникают трудности...

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

Итак, "пусть это будет таблица с данными", спасибо за показательный объект!
Чем <<Модель-представление-контроллер>> не основа для абстрактного подхода!?
Здесь есть "С ЧЕГО НАЧАТЬ ПИСАТЬ ТЕСТОВЫЙ СЦЕНАРИЙ":
Модель:
- адекватно (с учётом pagination) выведены все записи resultset;
- null в поле DB - пустая ячейка в таблице;
- форматы, правила округления, типы (из sql-запроса) соответствуют значениям в ячейках;
...
Представление:
- форматирование чётко отделяет ряды и колонки записей;
- частично cкрытые из-за недостаточной ширины ячейки данные помечены;
- при вертикальном скроллинге header таблицы не пропадает;
...
Контроллер:
- клик по header любой колонки вызывает адекватную сортировку;
- расширение колонки не вызывает частичной потери визуализации - появляется горизонтальный скролл для просмотра всех полей;
- сужение колонки не приводит к её безвозвратному схлопыванию;
- корректно работают операции для групп выделенных записей и для отдельной строки;
...
Быстродействие.
Кроссбраузерность.
...
сhaikova, мысль уловили? Разницу почувствовали? Это было бы смешно - пойти за информацией к пользователям; в каком плане? в любом случае таблица выводит информацию - когда бы не было так грустно.

А теперь плохая новость, точнее выберите то, что вам (ситуация у вас на работе) больше подходит, из-за чего у всё такое "размытое, и без требовани":
1. Неадекватный менеджмент, особенно жжёт ваш непосредственный руководитель;
2. Бессмысленность вашей работы - увеличивать объём письменной документации бесполезными тест-кейсами;
3. Роль, которую вы выполняете в проекте, не соответствует вашему уровню компетентности;
4. Локализация тестируемого вами приложения на ломаном китайском языке, а таблица - таблица шифров с грифом государственной важности;
...

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

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

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

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

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

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

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

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

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

есть какие-нибудь предположения для воспроизведения ошибки ?

Если бага не идет к Тестеру, то вот как Тестеру идти к баге:
1) Внимательно изучите по требованиям, какой рабочий диапозон дат ожидается, (чтобы не создавать надуманных трудностей);
2) Попросите девелоперов включить подробное логгирование (запись в файл истории событий ввода/вывода данных, т.е. какие соответствующие даты пользователь задавал, как они обрабатывались/сохранялись, как подготавливались для отображения), и можете ждать, когда проблема проявится - по логу будет проще найти её причину.
3) Если у вас есть соответствующие знания,- проверьте (белый ящик):
3.1) корректность валидаторов вводимых значений дат (с учётом локали и [min;max]);
3.2) наличие глюко-функциональности по автозамене невалидной даты (по формату или диапозону значений д м г) на некую валидную;
4) Если есть возможность - автоматизируйте сценарий ввода/вывода даты, подготовьте тестовые наборы: позитивные (хоть перебором - лишних тестов в случае, когда нет идей, есть только глюки - не бывает) и негативные - этих побольше/разных

Вопрос: karakoz, можете представить ваши тестовые наборы (классы эквивалентности):
- что не сработало для воспроизведения?
- что планируете?

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

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

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

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

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

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

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

Извините, но даже если вам "вариант использования" встретится 64 раза,- для их применения требуется очень хорошая подготовка, иначе это чревато визитом в травмпункт.

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

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

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

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

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