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

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

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

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

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

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

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

Порадовали!

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

А что касается

Здесь все более точно расписано как про задачу, так и про возможные тесткейсы под нее:
http://testingworld....isaniya-testov/

это я это могу слушать бесконечно:
- девушка!
- чуувиха!
- да не...английский!
- ну герл!
- о ес ес герл!
- (из testingworld) представьте трудности тестирования программ размером, например, в 1 000 000 и более операторов. А если это программа по управлению реактором АЭС?
- ес ес обэхээс

По существу же сначала сказал:

...Так вот, хочется спросить, а Вам что нужно тестить?
Что нужно, то и будем.
...А может быть, для начала проанализируем качество требований..?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как и что будем тестить? :)

Кто-нибудь знает, что такое простой треугольник? Просьба "не кидать по понятиям", а, пож-та, дайте ссылку на авторитетный источник с определением этой фигуры, точнее - данного типа треугольника, в (желательно ограничиться: Евклида; Лобачевского; Римана) геометрии.

У вас есть замечательная возможность лично пристыдить автора этой задачи...

Нет, мне как-то так неудобно сразу стало перед другими за вашу наводку, а вы не застестняетесь, если я вас лично попрошу тому, кого вы мне (тук-тук-тук - это Glenford Myers) подсказали, передать некоторые очевидные умозаключения по поводу некорректности этой задачи?

Я не увидел.

А я - увидел!

Формулировка задачи не является математически точной, но этого и не требуется.

Не требуется?! откуда вы знаете? ведь вы - не автор задачи!

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

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

что _не_ является непредолимым препятствием.

Буратино всегда сам создавал себе препятствия, и, они не являлись непредолимыми... многим очень нравится эта сказка...

---

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

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

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

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

Ну вот я даю такое задание. Именно в приведенной формулировке.
А почему так,

на выходе следует ожидать одно из 5 значений:
1 - невырожденный треугольник, у которого все 3 стороны равны;
2 - невырожденный, у которого только 2 стороны равны;
3 - невырожденный, у которого нет равных сторон;
4 - вырожденный треугольник;
5 - в случае ошибки ввода/обработки.

если я ожидаю на выходе увидеть тип треугольника, а не 1,2,3,4,5?

Это из разряда - Заказчик сам толком не понимает, чего хочет.

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

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

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

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

Судя по всему

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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