Сообщений в теме: 9

[idunin]

Здравствуйте,

Вопрос такой, может ли заменить чек-лист тест кейс? Я так понимаю, что тест кейсы пишутся для людей, которые не разбираются в программе, чтобы они выполняли все строго по плану, а чек-лист - это описание пунктов, которые надо проверить на работоспособность? Так? И работать по чек-листу может только человек, который знаком с программой и знает, как выполнить тот или иной пункт.

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

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

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

[Clauster]

1. Нет, потому что вы не можете всё держать в голове
2. Не так. Поищите в интернете определение тест-кейса и чек-листа.

[idunin]

1. Нет, потому что вы не можете всё держать в голове
2. Не так. Поищите в интернете определение тест-кейса и чек-листа.

1. Не понял, что я не могу держать в голове?
2. Искал. Нашел сравнение тест плана с чек-листом, здесь же на форуме нашел про применение чек-листа для тестирования.

[Case]

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

Я примернял оба этих документа примерно в такой ситуации:
Один тест кейс порождает столько изменений, что проверка этих изменений требует отдельного рабочего документа в качестве которого я применял чек-лист. Например операция "Закрытие месяца" в биллинге это ОДНА операция и один тест-кейс по сути: с точки зрения end-user-а он делает один шаг и получает от системы один ответ "месяц закрыт", но на уровне базы данных и логики системы изменения у нас занимали порядка 2 десятков точек проверки.

Другой пример: тестирование инсталляции. Визард из 2-3 формочек: буквально 2-3 user actions, но в зависимости от условий окружения (environment conditions) результаты работы инсталлятора могут быть очень разными. Чтобы не описывать тест кейс как ФИКСИРОВАННЫЙ набор действий + список условий окружения, я использовал перечень test cases + несколько чек-листов, в которых указывал и параметры окружения и ожидаемые результаты: точки проверки.

PS
Попробуйте чуть шире поискать, а не только по нашему серверу.

[Clauster]

1. Не понял, что я не могу держать в голове?
2. Искал. Нашел сравнение тест плана с чек-листом, здесь же на форуме нашел про применение чек-листа для тестирования.

1. То, что есть в тест-кейсах, но нет в чек-листах. Наверно у нас разные понятия о тест-кейсах и чек-листах.
2. Тут ещё почитайте.

[avk]

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

Поэтому мое мнение таково: если хватает ресурсов, то можно иметь описание тестовых прецедентов, если нет - нужно обходиться чек-листами. Они, по крайней мере, позволят систематизировать тестирование. Я в фирме ввел как правило "имение как минимум чек-листов".

[idunin]

Поэтому мое мнение таково: если хватает ресурсов, то можно иметь описание тестовых прецедентов, если нет - нужно обходиться чек-листами. Они, по крайней мере, позволят систематизировать тестирование. Я в фирме ввел как правило "имение как минимум чек-листов".

Спасибо большое! Это очень хорошая идея. Наверное я пока для критического функционала продолжу написание сценариев, а для не критического пока обойдусь чек-листами. Ресурсов мне одному действительно не очень хватает.

Clauster, тоже спасибо. Читаю.

[Inquisitive]

На мой взгляд, кое-где усложняете понятия.

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

Конкретный пример универсального требования к любому сайту (является пунктом в универсальном чек-листе):
"- проверить, чтобы последняя крошка была некликабельной и полностью совпадала с пунктом меню и названием текущей страницы".

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

[Clauster]

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

[Inquisitive]

Абсолютно логично.
И писать их (чек-листы и тест-кэйсы/сценарии/скрипты) - весьма полезное занятие.