Feeds:
Posts
Comments

Archive for November, 2011


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 »

    Severity vs Priority


    Серьезность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения.

    Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

    Severity выставляется тестировщиком
    Priority  –  менеджером,  тимлидом или  заказчиком
    Градации серьезности и приоритета устанавливаются индивидуально для каждой компании
    Примеры: 

    Read Full Post »


    Не секрет ,что скорость устранения ошибки в программе зависит от качества баг репорта.  Если он ясен и позволяет легко воспроизвести ситуацию, то  все отлично, а если  он – это некая каша, то толку от него мало.  Правильно говорят .что хороший тестировщик не тот, кто выставит максимальное количество  багрепортов, а тот по тикетам которого исправят максимум багов.

    Что же такое хорошо и что такое плохо?

    В приложении paint winWP есть занятный глюк,   система позволяет ввести отрицательные значения  размера изображения.  Попробуем написать  багрепорт.

    Summary 

    ААА, какая клевая бага!

    Винда без багов не бывает

    WinXP.Paint.В поле размер изображения система позволяет ввести отрицательные значения

    Reproducible

    Always

    Steps to reproduce

    *начинаем с точки, известной разработчику. Не стоит начинать с инсталляции  WinXP*

    1. В  меню Рисунок выбрать пункт Атрибуты

    2. В единицах измерения задать “точки”  *иначе  система может сказать ,что недостаточно ресурсов и это будет уже иной класс бага*

    3. В одно из полей размера вводим 10, во второе -1

    4. Нажать кнопку ОК

    Description

    При вводе отрицательного числа  в поле размера изображения система интерпретирует его как очень большое положительное (из -1 в 4294966) и в соответствии с этим  масштабирует исходное изображение.  Система нарушает как логическое условие на то, что размер рисунка не может быть неположительным,  дополнительно в таких условиях нарушается ограничение, что размер рисунка не может превышать 99999.  (more…)

    Read Full Post »


    У вас бывает такое, что вы откладываете начало выполнения какого-то большого задания, пока не начинает маячить срок сдачи?  Порой мы это называем студенческим подходом и  любовью затянуть все под сессию.   На практике задача выглядит несколько иначе. Мы опасаемся начать большое задание,  ибо просто не понимаем с чего начать.

    По сути  от нас требуется съесть слона. Вы слона видели? Это весьма таки огромное млекопитающее. Среднестатистический самец весом 5 тонн, высотой 3,5 метра.  Представили?  С чего начнем?

    Чтобы съесть слона, надо нарезать его на бифштексы.

    Съесть слона Уши в одну сторону, хобот в иную, из хвоста варим суп, из ног – холодец и т.д.  Главное,  теперь задача становится решаемой.

    В тестировании ситуация зачастую аналогична.  Необходимо разделить все множество тестов на группы, чтобы знать за что хвататься. Чтобы иметь возможность распараллелить работу (Вася ест хобот, а Коля – левую переднюю ногу)  и чтобы  учесть  приоритеты пользователей (уши надо употребить в первую очередь, а то они испортятся) .

    Как же выделить группы?

    Существует три основных подхода:

    1. На основе приоритета: 

    У вас налажен хороший контакт с заказчиком и требования у вас  имеют приоритеты.  При этом  нет ситуации, что 90%  требований имеют наивысший приоритет.

    Тогда вы создаете тесты на базе требований, на базе приоритетов требований присваиваете приоритеты тестам и  выполняете их в соответствии с этими приоритетами.

    Жаль, что не всегда так выходит.

    Допустим, что приоритетов нет, или 90%  требований имеют наивысший приоритет, тогда  у нас есть два варианта:   код доступен или нет.

    (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 »


    Sometimes it’s possible to find information that smoke testing and sanity testing are the same, it’s not really so.

    When a build is received, a smoke test is run to ascertain if the build is stable and it can be considered for further testing.

    Once a new build is obtained with minor revisions, instead of doing a through regression, a sanity is performed so as to ascertain the build has indeed rectified the issues and no further issue has been introduced by the fixes.  It’s generally a subset of regression testing.

    Some more facts about the difference between Smoke and Sanity testing

    SMOKE TESTING:

    • Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.
    • A smoke test is scripted, either using a written set of tests or an automated test
    • A Smoke test is designed to touch every part of the application in a cursory way. It’s shallow and wide.
    • Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. (Such as build verification).
    • Smoke testing is normal health check up to a build of an application before taking it to testing in-depth.

    SANITY TESTING:

    (more…)

    Read Full Post »

    Older Posts »