Тестирование проекта

Добрый день уважаемые господа тестировщики :)
Некоторое время назад я решил вступить в ваши ряды имея за плечами небольшой
опыт программирования...
После получения теста на вакансию я немного удивился....ведь получил описание того как работает
проект...я привык работать с чем-то что можно "поклацать"....а тут надо создать несколько тестовых кейсов и ожидаемый результат имея только System Requirements Specification О_О

Как надо поступать в таких случаях? о_о

Да тебе ещё повезло крупно. Я в 60% сначала получаю программу, потом сам на неё SRS пишу, потом с этогол SRS план, потом тесты, а потом сам эти тесты выполняю.
Плюс ещё приходится рекомендации по исправлению ошибок вёрстки писать со ссылками на источники доп информации.
+ если баг забористый и требует доработки - приходится для програмистов писать требования к реализации доработки.

Да тебе ещё повезло крупно. Я в 60% сначала получаю программу, потом сам на неё SRS пишу, потом с этогол SRS план, потом тесты, а потом сам эти тесты выполняю.
Плюс ещё приходится рекомендации по исправлению ошибок вёрстки писать со ссылками на источники доп информации.
+ если баг забористый и требует доработки - приходится для програмистов писать требования к реализации доработки.

но ведь ты получаешь программу....а у меня только srs....и не понятно как там все реализовано О_О

Если по SRS не понятно как будет реализовано - то это не очень хорошее SRS мне таккажется...

а есть какие-нибудь примеры создание тестовых случаев (test cases) на основании одного лишь srs?

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

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

Советую подучить матчасть. Если с английским нормально, то начать можно с общей методологии (Ron Patton - "Software Testing") и продолжить подходами к созданию тестов (Lee Copeland - "Guide to Software Test Design").

А вообще, мне кажется, что навык абстрагироваться от UI и конкретики реализации - это очень важный навык, особенно для создания тестового набора.

Как-бы я считаю что есть стандарт на SRS - IEEE 830-1998,
вот хотя-бы в таком виде:
русский перевод IEEE 830-1998
Конечно ушлые разработчики могут под видом SRS подсунуть всё что угодно. Они, как правило такие доки, не читают.

Там в SRS как правило есть раздел функции изделия, либо в виде use cases либо в виде списка, либо в виде рисунка интрефейса, либо ещё в каком нибудь вдие.
Написать для чего нужна программа и что она должна делать - ну даже если такого не написано то это вообще не SRS.

По технической составляющей - если это web то подразумевается что http + html, если приложение - то всё равно подразумевается какая-то библиотека окошек.

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

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

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

а есть какие-нибудь примеры создание тестовых случаев (test cases) на основании одного лишь srs?

Запостите SRS мы вам составим тесткейсов.

Как-бы я считаю что есть стандарт на SRS - IEEE 830-1998,
вот хотя-бы в таком виде:
русский перевод IEEE 830-1998

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

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

Пример. У меня в проекте сейчас есть некий параметр (назовем его кренделем ), изменять который можно с помощью кнопки (железной), ручки-крутилки (железной) и может еще что появится. Управлять кренделем в одних случаях пользователь может, в других - нет.
Проверять правильность отработки ПО этого кренделя надо? Да!
Поэтому
1. Правильность отработки кренделя
1.1. Управление кренделем с помощью.... (ежели - знаем.., нет - ну и пусть многоточие ПОКА!)
1.2. Управление кренделем с помощью....
и т.д.
2. Возможность управления кренделем в ситуации 1 .... (и сколько там вариантов?)

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

Вот как-то так.

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

Да тебе ещё повезло крупно. Я в 60% сначала получаю программу, потом сам на неё SRS пишу, потом с этогол SRS план, потом тесты, а потом сам эти тесты выполняю.Плюс ещё приходится рекомендации по исправлению ошибок вёрстки писать со ссылками на источники доп информации. + если баг забористый и требует доработки - приходится для програмистов писать требования к реализации доработки.

но ведь ты получаешь программу....а у меня только srs....и не понятно как там все реализовано О_О

Если по SRS не понятно как будет реализовано - то это не очень хорошее SRS мне таккажется...

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

у меня только srs....и не понятно как там все реализовано

Слова программиста, а не тестировщика :) Вам нужно тесты писать или в коде разбираться? :)

alexdfry, а не дали ли Вам задачу про стороны треугольника? :) очень уж любят ее на собеседованиях.
Вот здесь в средине текста есть описание: http://window.edu.ru...2txt?p_id=22383

Так вот второй вариант по-моему намного лучше. Потому что программу уж точно кто то напишет. =))

Добрый день уважаемые господа тестировщики :)
Некоторое время назад я решил вступить в ваши ряды имея за плечами небольшой
опыт программирования...
После получения теста на вакансию я немного удивился....ведь получил описание того как работает
проект...я привык работать с чем-то что можно "поклацать"....а тут надо создать несколько тестовых кейсов и ожидаемый результат имея только System Requirements Specification О_О

Как надо поступать в таких случаях? о_о

Я думаю у вас все-таки не SRS, а BRS(Business Requirement Specification), потому как SRS это скорее требование к "железу" (но это впринципе неважно как назвать).
Примеры можно посмотреть тут и описание к подходу тут.

Пожалуй что появились еще темы для обсуждения.
1. Коммуникация тестировщик - авторы SRC.
2. Как фиксировать баги в SRC (спецификации, требованиях к ПО)

Как фиксировать баги в SRC (спецификации, требованиях к ПО)

Да известно на самом деле, вопрос в том как сделать так чтобы эти баги ещё и фиксились...

Как надо поступать в таких случаях? о_о

Ровно сейчас и прогоняю тесты, написанные ЛЕТОМ.
Тогда и спецификация на ПО еще не полностью была утверждена.
Еще и нюансы (специфика работы):
- жесткие требования к документированию
- внешняя среда представляет собой набор имитаторов (программ для ПК), которые на тот момент тоже не были реализованы (на них тоже были только спецификации)

При этом - исправления в тесты вносить конечно приходиться, но!
гораздо проще, чем писать с "чистого листа".