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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тэшт шьют

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Судя по всему

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

Я не увидел.

А я - увидел!

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

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

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

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

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

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

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

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

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

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

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

Порадовали!

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

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

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

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

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

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