Feeds:
Posts
Comments

Posts Tagged ‘Test Case’


Checklist 

Пусть у нас есть поле, которое принимает буквенно-цифровые значения (латиницу). Длина поля ограничена 35 символами.

Вспоминая  рекомендации набросаем чеклист:

1. Можно ли ввести в поле буквенно-цифровые значения до 35 символов?  (да)

2. Можно ли ввести в поле буквенно-цифровые значения  35 символов?  (да)

3. Можно ли ввести в поле буквенно-цифровые значения более 35  символов?  (сообщение об ошибке)

4. Можно ли оставить поле пустым?   (уточнить спецификацию)

5. Можно ли заполнить поле пробелами? (уточнить спецификацию)

6. Можно ли заполнить поле табуляциями?  ( уточнить спецификацию)

7.  Можно ли ввести специальные символы (‘,$,/,\, &,-,…)? (сообщение об ошибке) (more…)

Read Full Post »


  1. Необходимо понять, что за программное обеспечение должно быть протестировано, как оно будет использоваться, кем, какие задачи решать.   Если пропустить этот шаг,  то тестировщик рискует пропустить ряд концептуальных багов, которые очень важно  выявить до начала реализации архитектектуры и, тем более, кода.
  2. Создать  тесты для дымового тестирования
  3. Нарезать “слона на бифштексы”  – выделить группы тестов
  4. Написать чек лист для каждой группы тестов, при этом следует не забывать о:
  1. порядке тестов – от простых тестов к сложным. Если на прогоне не пройдут простые тесты, то будет ли смысл в сложных ?
  2. тестах с пустыми полями,  с пробелами, табуляцией,  спецсимволами, значениями по умолчанию, максимальную длину/значение поля.
  3. негативных тестах –  приложение не делает того чего не должно делать (например, нельзя ввести больше 100 символов или дату не в правильном формате.
  4. наличии простых позитивных тестов;
  5. систематичности – лучше одна часть структуры расписанная хорошо, чем везде по чуть-чуть
  6. креативных идеях 😉  – нарабатывайте ваш опыт ))
  7. вопросах по ожидаемым результатам –  помните, что спецификация не идеальна и нуждается в уточнениях  )
  • При наличии времени – детализируйте  чеклист в тест кейсы. Опять же, следует помнить о том: (more…)
  • Read Full Post »


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

    Начнем с  более формального, Тест Кейса.

    По стандарту IEEE Standard 610 (1990)  test case – это:

    A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

    По стандарту IEEE Std 829-1983 test case – это:

    Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.

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

    Checklist is a list of steps or a funcationality which  guides the Tester to verify the features or functionality of the application.  The basic purpose of Checklist is that you should not    miss anything required to complete the job.

    Чек лист — список  шагов или перечень функциональности   который позволяет тестировщику убедиться в корректной работе приложения.

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

    Обычно чек лист представляет собой таблицу из двух колонок:

    Проверяемый фактор  | Есть он у системы или нет

    Например, мы хотим создать чек лист для чайника

    (more…)

    Read Full Post »