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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

negro, почему вас так задела эта тема?
Какая вам разница...

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

aya, можно не обращать внимание на то, что я сказал выше...
А теперь на все ваши "почему?" я отвечаю: да потому что вы в разделе [Форум тестировщиков> Тестирование> Начинающему тестировщику] написали о своём "шкурном" интересе (кстати, делайте у себя в компании, что хотите, и говорите здесь - я против цензуры), а не полезные замечания или умные мысли для пользы теории/практики тестирования!!!

...вы иногда "перегибаете палку"...

и иногда "разгибаю кочергу", Vasiliy:

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

aya, это не менее оригинально, чем см. http://software-test...hp?/topic/7660/ , а с учётом "за бесплатно" - более.

...товарищ просто троллит...

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

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

CAPTCHA [ˈkæptʃə]
[k] - к
[æ] - э
[p] - п
[tʃ]- ч
[ə] - э
Смотрим в Википедию: "CAPTCHA - ...В Рунете часто транскрибируется как «капча»..."
Теперь я понимаю, почему руководство не против, чтобы с вами ещё кто-то тестировал.

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

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

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

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

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

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

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

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

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

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

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

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

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

Был вопрос "Если тот, кто думал, что он мудрец, вдруг отказывается искать всего в себе, то что могло заставить его это сделать?", на него ответил тот, кто ответил,- Vita и Drag, спасибо.

nhuber, ты сказал:

Виктория, верю... Ваше зерно прорастёт.

Вопрос 1.1: правильно ли я понимаю твой сарказм,- что это обращение к лисе Алисе, которая ведёт Буратино на поле Чудес в стране Дураков, а он - дурачок ей и верит, что посеянное там прорастёт?
Вопрос 1.2: чьё зерно? Это про ту же лису: зерно выпало - с ним была плутовка такова?
Вопрос 1.3: разве не очевидно, что лиса не способна отделить зерно от плевел?

Вопрос 2 (для всех): где же "прорастёт зерно"? Выберите ответ:
- в стране Д на поле Ч , т.е. в Данной Чудесной теме лисы, её так сказать стараниями, при её чутком руководстве;
- в себе у каждого думающего человека;
- можно свой вариант мудрого ответа.

Мудрость тестировщика: ищите мудрость в себе, разочарование в найденном - не повод от этого отказаться.

Всегда стараюсь понять того, кто делает...

С этой мудростью согласен (особенно, если старания результативны).
А дальше:

А может преимущество, победа дипломатии тогда, если ... ваш коллега по прошлому месту работы знает много о Вашем трудолюбии, успехах, развитии и той же дипломатии и коммуникабельности, зовет вас к себе.

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

Мой начальник предприятия мне нравится...Мой начальник отдела мне нравится, говорила ему что люблю...Зам. начальника отдела мне нравится

с другой - опускаетесь до озабоченности о примитивной выгоде (и свет погас):

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

Это мудрость тестировщика или типа - а понимайте как хотите?

Для тестировщика также очень важно уметь видеть, замечать и учитывать все...

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

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

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

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

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

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

nhuber, допустим вы начали взаимодействие с Заказчиком, который задачу толком вам сформулировать не может и т.д. и т.п. короче, на деле оказывается, что Заказчик - старший субподрядчик младшего субподрядчика... Вы что, на своём примере:

...Я такие бегло сформулированные неполные требования получаю регулярно, и по таким требованиям часто вполне возможно спроектировать приложение, которое затем реализуется, тестируется...

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

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

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

предлагаете тратить время на бессмысленное собеседование, развивая в себе комплекс неполноценности?

...то многоугольник называют простым...

Вы нашли определение простого многоугольника, из которого следует, что "треугольник" является "простым многоугольником" (т.е. множество треугольников является подмножеством простых многоугольников).
Если использовать употреблённое в исходном задании понятие "простой треугольник", то это <нечто> есть "простой простой многоугольник" по вашему?
Кому не очевидно, что это - "масло масленное"?
И вообще, я просил дать определение простого треугольника, а вы (математик) дали определение простого многоугольника. Ничего страшного - бывает.
Для гуманитариев, кто не понял: спрашивали определение "селёдка", а дали определение "рыба", но селёдка - это не вся рыба! Это азы логики.

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

Поэтому я и говорю:
- получив такую задачу, (тем более с вашим пессимистическим подтекстом), на собеседовании надо

сразу вставать и уходить искать работу в другой компании

Спасибо, что дали понять, как вас позиционировать:

правильный неравносторонний треугольник?

...слово "правильный" (в определении треугольника) лишнее везде. Постольку, поскольку "правильный" - это есть "равносторонний"

...следовало бы формулировать вопрос, ответ на который должна давать программа, как-то так...

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

Вы придираетесь к мелочам в формулировках задачи
Вытащите бревно из своего глаза

и увёртки ничего не несут теории и практике тестирования, потому что вопрос задан:

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

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