Тестовая документация, на мой взгляд, чаще всего нужна для того, чтобы:

* не забыть что-то проверить
* наглядно увидеть, что мы проверили, что нет
* наглядно увидеть, что работает, что нет

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

Это случаем не чек лист? />

Тоже так кажется, чек-листы у меня есть) Спасибо всем в любом случае, для себя сделал выводы :)

Вопрос второй: как быть? :)

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

Примеры формулировок:
* Чтобы не забыть выполнить все тесты
* Чтобы новым тестерам было легче работать с приложением
* Чтобы знать, сколько еще тестов нужно написать / выполнить / автоматизировать
* Чтобы произвести впечатление на руководство
* ...

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

Спасибо! Если подумать, для меня тест-кейсы нужны, главным образом, как объективная оценка качества моей работы :) Ну и вроде как главное для тестировщика - тест-кейсы и еще раз тест-кейсы.
Судя по всему, для этой цели они не сильно подходят.
По пунктам:
* Чтобы не забыть выполнить все тесты - использую чек листы
* Чтобы новым тестерам было легче работать с приложением - думаю, новых пока не предвидится
* Чтобы знать, сколько еще тестов нужно написать / выполнить / автоматизировать - чек-листы и код
* Чтобы произвести впечатление на руководство - им пофиг, лишь бы багов не было

Здравствуйте, ув. форумчане!
В должности тестировщика я недавно и у меня есть большая проблема (проблема ли?) - я не пишу тест-кейсы!
Опишу ситацию.
Тестер в компании один - я. До этого тестеров не было, и до этого я никогда тестером не работал. Тестирую один единственный сайт - сайт компании (интернет-магазин). Различные нововведения, акции и фишки на сайте появляются с завидной регулярностью. Процесс разработки (и тестирования) поставлен плохо, по сути, никак не поставлен. Собственно, тестер понадобился после многочисленных крэшей и фейлов при релизах на продакшен, когда руководство, с огорчением, на пополам с пользователями занималось отловом багов.
Так вот... Я пытался писать тест-кейсы и суиты, но все заканчивалось тем, что потом просто в них не заглядывал потому что:
1) Некоторые из них (примерно половина) доходила до автоматизма и я просто уставал каждый раз открывать и читать одно и тоже, чтобы выполнить то, что я и так уже знаю, как выполнять и чего ожидать
2) Некоторые (другая половина :) ) теряли свою актуальность из-за постоянных меняющихся требований и функционала сайта. При этом желания поддерживать состояние таких кейсов совсем не возникает.
В общем, весь опыт работы по созданию тест-кейсов - негативный, связанный с бюракратией и ни разу не эффективный.
Все это, как я понимаю, создавалось для регрессионного тестирования. Единственная альтернатива от меня этим тест-кейсам это создание автоматизированных тест-кейсов на selenium'e. Собственно, эти сделанные мною автокейсы и есть мои тест-кейсы, тупо код, без нормального, обычного документирования (как положено).

Вопрос первый: нормальна ли такая ситуация, когда тест-кейсы оформлены только в виде C# кода?

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

Вопрос второй: как быть? :)

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