Допустим, кому, как писать и контролировать качество тест-кейсов проехали, несмотря на следующие трудности:

...будет писать иначе. Чтобы не тыкали...

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

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

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

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

Хорошо бы расширить тему ответом на вопрос: "каковы должны быть причины, из-за которых нельзя обойтись без тест-кейсов?"
Кто-нибудь может исходному теоретическому вопросу помочь обрести практический смысл?

Пишу сейчас свои первые тест кейсы. По чужим работю уже с пол года, примерно. Что посоветуете при написании? Давайте составим 5 золотых правил для тест кейсов.

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

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

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

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

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

Тест-Суйте...

Тэшт шьют

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечание 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

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

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

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

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

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

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

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

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

Я предложил решить задачу.

По-моему, её предложил решить earx, а ваше разъяснение к вопросам в её уточняющей формулировке:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Порадовали!

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

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

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

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

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

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