Обратная связь

ПОЗНАВАТЕЛЬНОЕ

Сила воли ведет к действию, а позитивные действия формируют позитивное отношение

---

Как определить диапазон голоса — ваш вокал

---

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

---

Целительная привычка

---

Как самому избавиться от обидчивости

---

Противоречивые взгляды на качества, присущие мужчинам

---

Тренинг уверенности в себе

---

Вкуснейший «Салат из свеклы с чесноком»

---

Натюрморт и его изобразительные возможности

---

Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д.

---

Как научиться брать на себя ответственность

---

Зачем нужны границы в отношениях с детьми?

---

Световозвращающие элементы на детской одежде

---

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

---

Как слышать голос Бога

---

Классификация ожирения по ИМТ (ВОЗ)

---

Глава 3. Завет мужчины с женщиной

---

Оси и плоскости тела человека — Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.

---

Отёска стен и прирубка косяков — Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

---

Дифференциальные уравнения второго порядка (модель рынка с прогнозируемыми ценами) — В простых моделях рынка спрос и предложение обычно полагают зависящими только от текущей цены на товар.

b)Структура Тестовых Случаев (Test Case Structure).

Каждый тест кейс должен состоять из трех частей. В таблице показаны эти части.

Таблица. Структура Test case.

Pre conditions	Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test case description	Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
Post conditions	Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

 

Примечание: Post Conditions не является обязательной частью. Эта часть актуальна при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

Пример тест-кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3.

В приведенном примере конечная проверка — В3. Это значит, что именно она является ключевой. Значит, A1 и А2 — это действия приводящие систему в тестопригодное состояние. А В1 и В2 — условия того, что система находится в состоянии пригодном для тестирования. Таким образом, в таблице ниже показано условие тест-кейса.

Таблица. Условие тест-кейса.

Action	Expected Result	Test Result (passed/failed/blocked)
Preconditions
do A1	verify B1
do A2	verify B2
Test Case Description
do A3	verify B3
Postconditions

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

Нужно ответить на вопрос: "Почему данное разбиение удобно использовать?"

Ответ в таблице ниже: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.

Таблица. Один из вариантов результата.

Action	Expected Result	Test Result (passed/failed/blocked)
Preconditions
do A1	verify B1	passed
do A2	verify B2	failed
Test Case Description
do A3	verify B3	blocked
Postconditions

c)Детализация описания тест кейсов. Уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов. В таблице ниже можно увидеть пример детализации тест-кейса:

Таблица. Пример тест-кейса 1.

Проверка отображения страницы
Действие	Ожидаемый результат	Результат теста
Открыть страницу "Вход в систему"	— окно "Вход в систему" открыто; — название окна — Вход в систему; — логотип компании отображается в правом верхнем углу; — на форме 2 поля — Имя и Пароль; — кнопка Вход доступна; — ссылка "забыл пароль" — доступна.	…

 

Пример тест кейса 2:

Название: Проверка отображения страницы

Действие: Открыть страницу "Вход в систему"

Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем изображение страницы "Вход в систему").

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

D)Атрибуты тест-кейса.

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

Таблица. Атрибуты тест кейса.

Атрибут тест кейса	Описание
Test Case ID	Уникальное значение в пределах не только документа, но и всей фирмы
Test Case Priority	Приоритет. Измеряется от 1 до n 1 – самый высокий n – самый низкий (для не очень больших проектов рационально выбирать n=4)
IDEA	Описание идеи, проверяемой тест-кейсом
SETUP and ADDITIONAL INFO	Входные параметры
Revision History	История редактирования. Пример формата: Created on <date> by<name> Modified on<date>by<name> Change – какие изменения и зачем они
Execution Part	Выполнимая часть тест кейса. Пример формата: Action – список команд EXPECTED RESULT – ожидаемый результат TEST RESULT – (passed, failed, blocked)

 

Пример тест кейса: пусть для тестирования возможности оплаты услуги на сайте необходимо выполнить следующий алгоритм:

1) открыть vk.com;

2) ввести в поле “Имя пользователя” значение “user”;

3) ввести в поле “Пароль” значение “password”;

4) нажать кнопку “Войти”;

5) ввести в поле “Искать людей” значение “Петр Петров”;

6) нажать кнопку “Поиск”;

7) нажать на страницу с Петр Петров;

8) в открывшейся странице нажать на ссылку “Отправить подарок”;

9) в открывшейся странице нажать на любую ссылку с подарком;

10) в открывшейся странице нажать на кнопку “Подарить”;

11) в открывшейся странице нажать на ссылку “Банковские карты”;

12) ввести в поле “Номер карты” значение карты VISA “1111-1111-1111-1111”;

13) ввести в поле “Действительно до” значение “07/15”;

14) ввести в поле “CVC” значение “111”;

15) нажать кнопку “Оплатить”;

16) записать номер заказа;

17) запросить базу данных “select res from payment where id = <номер заказа>”.

Ожидаемый результат: “10”

В таблице ниже можно увидеть как для данного примера будет выглядеть тест-кейс. Преимущество такой структуры тест кейса в отличии от первоначального списка заключается в том, что есть возможность протестировать по тому же сценарию другие данные (например: user2, password2, Джулия Робертс, 2222-2222-2222-2222).

Для выполнения одного и того же сценария на N наборах тестовых данных создается N тестов.

Этому правилу необходимо следовать. Таким образом, чтобы сделать подарок Ивану Иванову, нужно скопировать содержимое тест кейса VV12345, например, в тест кейс VV12346 и переписать только входные параметры.

Такой вид тест кейса называется управляемый данными (data-driven).

Проблемы сценария в примере:

– пункты 1-4 могут меняться в связи с миграцией сайта на новый домен, изменением интерфейса и т.д.;

– поиск друга в пунктах 5-7 “Петр Петров” может привести в никуда при удалении страницы;

– пункты 8-15 могут быть легко изменены за счет нового дизайна сайта.

Следовательно, при любом таком изменении придется переписывать весь тест кейс, чтобы заново протестировать первоначальную задачу.

Таблица. Тест-кейс для примера.

Test Case ID/Priority	VV12345
IDEA: Оплата картой VISA “подарка другу” SETUP and ADDITIONAL INFO: Аккаунт: user/password Имя друга: Петр Петров Номер карты: 1111-1111-1111-1111 Срок действия: 07/15 CVC: 111 Запрос SQL: select res from payment where id = <номер заказа>
Revision History
Created on 23/01/2014 by Иван Иванов	Новый тест кейс
Execution Part
ACTION	EXPECTED RESULT	TEST RESULT
1) открыть vk.com; 2) ввести в поле “Имя пользователя” значение “user”; 3) ввести в поле “Пароль” значение “password”; 4) нажать кнопку “Войти”; 5) ввести в поле “Искать людей” значение “Петр Петров”; 6) нажать кнопку “Поиск”; 7) нажать на страницу с Петр Петров; 8) в открывшейся странице нажать на ссылку “Отправить подарок”; 9) в открывшейся странице нажать на любую ссылку с подарком; 10) в открывшейся странице нажать на кнопку “Подарить”; 11) в открывшейся странице нажать на ссылку “Банковские карты”; 12) ввести в поле “Номер карты” значение карты VISA “11111111-1111-1111”; 13) ввести в поле “Действительно до” значение “07/15”; 14) ввести в поле “CVC” значение “111”; 15) нажать кнопку “Оплатить”; 16) записать номер заказа; 17) запросить базу данных “select res from payment where id = <номер заказа>”.

Если же разбить задачу на несколько тест-кейсов, например, за пункты 1-4 будет отвечать тест-кейс “Вход в систему”, за пункты 5-7 “Поиск друга”, 8-15 – “Оплата подарка” (на внутреннем уровне каждого из них возможно еще более детальное разделение), то можно переписать тест-кейс так, как указано в таблице ниже.

Таблица. Упрощение тест-кейса.

Test Case ID/Priority	VV12347
IDEA: Оплата картой VISA “подарка другу” SETUP and ADDITIONAL INFO: Аккаунт: user/password Имя друга: Петр Петров Номер карты: 1111-1111-1111-1111 Срок действия: 07/15 CVC: 111 Запрос SQL: select res from payment where id = <номер заказа>
Revision History
Created on 23/01/2014 by Марина Гончарова	Новый тест кейс
Modified on 23/01/2014 by Иванов Евгений	Упрощение шагов
Execution Part
ACTION	EXPECTED RESULT	TEST RESULT
1) войти в систему; 2) найти друга; 3) платить подарок; 4) записать номер заказа; 5) запросить базу данных “select res from payment where id = <номер заказа>”

Возможен вариант, когда все, что нужно – это выполнение команды номер 5, при условии что другие команды выполнены заранее. В таблице ниже указан упрощенный вариант тест-кейса.

Таблица. Упрощение тест-кейса.

Test Case ID/Priority	VV12348
IDEA: Подтверждение оплаты SETUP and ADDITIONAL INFO: Номер заказа: параметр
Revision History
Created on 23/01/2014 by Марина Гончарова	Новый тест кейс
Modified on 23/01/2014 by Иванов Евгений	Упрощение шагов
Modified on 24/01/2014 by Сергей Галкин	Изменение структуры
Execution Part
ACTION	EXPECTED RESULT	TEST RESULT
Запросить базу данных “select res from payment where id = <номер заказа>”

Неизвестным параметр <Номер заказа> после завершения выполнения теста получит свое значение, которое будет задокументировано.

---

В любой команде, которая уделает должное время тестированию, приходит тот момент, когда задается вопрос об автоматизации этого процесса. Как это происходит? Есть несколько путей для развития: либо сами тестировщики начинают автоматизировать, либо нанимается специально обученный человек, который, как панацея, должен решить все проблемы. В независимости от того, как это происходит, в конечном итоге мы все сталкиваемся с тем, что нужно как-то показать, что происходит, какова реальность — что же было сделано.

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

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

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

Немножко структурных данных

В нашей компании существует отдел ручного тестирования и автоматизаторы. Как система для организации тестов используется довольно популярный инструмент — TestRail. С моей точки зрения удобный и довольно функциональный.
Автоматизация построена тоже на довольно стандартном наборе Ruby + Cucumber + Watir/Selenium (можно упомянуть паттерн Page Object) + TeamCity.

Что происходит, когда на тестирование дается новый билд, (в нашем случае каждый раз мы имеем дело с регрешшеном)? Тестировщик создает новый тест ран, в который включаются все тест-кейсы с определенного тест-сьюта и — пошло поехало веселье. Уверен, всем знакомо то чувство, когда ты в 4-й раз прогоняешь вручную регрешшн или смоук на автомате, кликая/тапая на все элементы и проставляя статус для очередного теста. В этот момент пред красными глазами наверняка все плывет и картинка в голове повторяет знаменитое:

А порой и:

Именно сейчас приходим на помощь мы. Так уж получилось, что возникла идея. Если у нас есть автоматизация, то почему мы все еще не используем результаты нашей работы, чтобы жить стало проще? Мысль заключается в том, чтобы использовать отчет с TestRail вместо громоздких и непонятных отчетов с Cucumber. Довольно интересная задач — сделать так, чтобы тесты в TestRail сами меняли свой статус, в зависимости от того, как прошел автотест.

С помощью поиска всемогущего гугла была найдена документация по TestRail API для реализации сией благой цели. Мы решили для начала сделать так, чтобы запуская наши автотесты вся информация о текущем состоянии тестов отображалась в TestRail. Собственно, цель была достигнута — по нажатии на кнопку запуска тестов в RubyMine мы автоматически создавали новый тестран и отсылали результаты на сервер. Довольно просто, учитывая существующую информацию на сайте TestRail.

Как оказалось, это было всего лишь начало.

В конечном итоге удалось сделать довольно неплохую функциональность, а именно — мы настроили интеграцию TestRail + TeamCity + Automation Framework.

Теперь же подробности, уважаемые дамы и господа.

TestRail

Первая остановка у нас буде TestRail.

TestRail является программным обеспечением для управления данными полученными в результате тестирования. Данный инструмент помогает отслеживать процессы, управлять программным обеспечением и организовывать команду.

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

Начнем мы с того, что первое, что должен сделать наш юзер/мануал тестировщик — это создать собственно тестран, который в последствии мы и будем использовать для апдейтов.

Требования:
Фича: Запуск автотестов.
Для того, чтобы использовать автоматизации в реальной жизни.
Как пользователь я хочу, чтобы была волшебная кнопка «запустить ран с автотестами».

Сказано — сделано. Благо функционал TestRail позволяет нам интегрировать свой собственный код.

Как результат, мы имеем вот такую вот кнопочку:

Да, да — Start Tests.

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

Дабы юзер не кликал слишком часто на кнопочку, у нас организована защита от дурака — после клика на кнопку мы добавляем ключевое «in progress» к имени тестрана, это блокирует волшебную кнопку, пока наши автотесты не закончат свое дело.

Automation Framework

На конечной стадии был создан гем/библиотека, которая при разворачивании дает нам интеграцию с TestRail на любом нашем под-проекте.

Создание гема — совсем другая история, достойная отдельной статьи.

Если вкратце, то наша библиотека test_rail_integration имеет небольшой функционал, который мы используем у себя, но мне кажется, что кому-то тоже может быть полезной.

Для начала нужно его установить:

Далее добавить:

В after |scenario| hooks. И в env.rb файл:

Вот команды для запуска:

В нашем случае тесты запускались для 6 различных локализаций и все результаты отображались в 1 тестране. Иногда возникала ситуация, когда два апдейта приходили в одно время. Получалось так, что они не видели друг друга и после фейла приходил пасс статус. Такой вариант менял общую картину статуса теста.

В общем, эта команда проходит все тесты и проверяет в ней соответствие, что в зеленых тестах нет красных результатов. Если же есть — то меняет статус теста на красный.

Тут все просто, данной командой мы создаем тестран с указанным именем в проекте-сьюте, который мы записали в конфиг файле. Команда возвращает номер созданного тесана:

Нужно написать при первом запуске, так как данная команда генерирует конфигурационный файл, к котором нужно указать необходимую информацию о TestRail:

Это и есть core фунционал c флагами:

Тут и так все понятно, нужно указать номер тест рана:

и

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

Этот флаг тоже специфический и думаю никому больше не пригодится:

Здесь можно указать новую команду для текущего запуска:

Так как у нас используется вся интеграция для 6 локализаций, то по номеру тестрана мы ищем имя и парсим его на параметры так, что тестран должен иметь имя, допустим, DT SG staging. Здесь мы и находим необходимую информацию для запуска.

Запуск без поиска и проверки на наличие каких либо параметров, это наиболее полезная команда для Вас уважаемый читатель.

Можно определить так же номер типа тестов, которые буду запущены.

Полная команда для запуска тестов с существующим тестраном будет выглядеть так:

Либо же:

TeamCity

Тут, собственно говоря, все просто. Просто записываем команду так же, как мы бы ее запускали локально, разве только можно добавить несколько переменных для удобства и скомбинировать порядок запуска команд (в случае, если мы запускаем билд автоматически, сначала нужно указать команду на создание тестрана, потом на запуск тестов с номером, который пришел нам ранее).

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

Ссылка на репозиторий: github.com/Kirikami/test_rail_integration
Ссылка на библиотеку: rubygems.org/gems/test_rail_integration

ссылка на оригинал статьи http://habrahabr.ru/post/259359/

Тест-кейсы необходимо писать по требованиям

1234Следующая ⇒

Требования

Требования необходимо тестировать

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

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

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

Последствиями либо отсутствия тестирования требований вообще, либо откладывания тестирования требований до лучших времен или тезиса «все их недостатки выявятся в процессе разработки и тестирования» являются:

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

  Наверное, многие сталкивались с позицией программистов, аналогичной этим: «Не было написано, поэтому и не сделал», «Как написано, так и сделал», «Писать надо лучше» и т.п.

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

В заключении заметки о тестировании требований еще раз осмелюсь повторить критерии качества требований к программному обеспечению:

• Корректность
• Недвусмысленность (однозначность)
• Полнота
• Непротиворечивость (совместимость)
• Упорядоченность (ранжированность по важности и стабильности)
• Проверяемость (тестируемость или тестопригодность)
• Модифицируемость
• Трассируемость (прослеживаемость)
• Понятность

Тест- кейсы

Для лучшего понимания раздела, посвященного тест-кейсам, приведу здесь определение этих самых тест-кейсов, которое предлагает энциклопедия Wikipedia (прошу прощения за мой вольный перевод).

Тест-кейс (тестовый случай, test case) — это набор условий и/или переменных, с помощью которых тестировщик будет определять насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию. Для того, чтобы убедиться, что требование полностью удовлетворяется, может понадобиться несколько тест-кейсов. Для полного тестирования всех требований, предъявляемых к приложению, должен быть создан/выполнен по меньшей мере один тест-кейс для каждого требования. Если требование имеет дочерние требования, то для каждого такого дочернего требования должен быть создан/выполнен также по крайней мере один тест-кейс. Некоторые методологии (например, RUP) рекомендуют создавать по меньшей мере два тест-кейса для каждого требования. Один из них должен выполнять позитивное тестирование, другой — негативное.

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

Что формально характеризует написанный тест-кейс? Наличие известного ввода (входные данные) и ожидаемого результата, который достигается после выполнения теста. Входные данные называются предусловиями теста, а ожидаемый результат — постусловиями теста.

Написанные тест-кейсы часто объединяются в тестовые наборы (test suite).

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

b)Структура Тестовых Случаев (Test Case Structure).

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

Тест-кейсы необходимо писать по требованиям

Начну здесь, пожалуй, с того, что же такое тестирование и какой программный продукт (систему) мы можем назвать качественным. Надеюсь, что дальше станет понятно, почему я начинаю с определения очевидных вещей.

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

Данное определение ни в коем случае не претендует на полноту и описывает процесс тестирования только с одной стороны. С той стороны, которая повернута к требованиям. Именно поэтому не стоит расценивать все, что будет написано дальше, как исчерпывающую инструкцию по написанию тест-кейсов.

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

Что же делают наиболее изобретательные тестировщики? При написании тест-кейсов они пытаются заручиться поддержкой программистов, а если еще точнее, то они пытаются как можно быстрей получить готовую реализацию продукта и писать все тест-кейсы, опираясь на реализованный продукт, т.к. это по их мнению объективно проще и понятней. Это крайне неправильно!

В этом случае получается, что в процессе тестирования проверяется соответствие разработанного продукта разработанному продукту (вот такой каламбурчик). Сами можете представить себе, что из этого получается.

Поэтому, резюмирую все описанное выше — базисом для подготовки тест-кейсов должны быть требования (в том или ином виде), а ни в коем случае не готовый продукт.

---

1234Следующая ⇒

---

Дата добавления: 2016-10-23; просмотров: 600 | Нарушение авторских прав

---

Похожая информация:

Поиск на сайте:

Тест-кейсы необходимо писать по требованиям

1234Следующая ⇒

Требования

Требования необходимо тестировать

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

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

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

Последствиями либо отсутствия тестирования требований вообще, либо откладывания тестирования требований до лучших времен или тезиса «все их недостатки выявятся в процессе разработки и тестирования» являются:

• выявление серьезных ошибок проектирования непосредственно перед выпуском релиза, что приводит к необходимости серьезных доработок, как требований, так и кода (я уже не говорю о доработке тест-кейсов, тестовых данных и повторном тестировании). Естественно, все это приводит к срыву сроков, авральной работе (по ночам и/или выходным) и прочим негативным вещам, которых можно было бы избежать своевременным тестированием требований;
• перекладывание всей ответственности и вины за случившееся на создателей требований, что по меньшей мере, не оздоровляет отношения между участниками разработки. Наверное, многие сталкивались с позицией программистов, аналогичной этим: «Не было написано, поэтому и не сделал», «Как написано, так и сделал», «Писать надо лучше» и т.п.

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

Детализация описания тест кейсов (Test Case Specification)

Честь бы и хвала была такому тестировщику, если бы кричал он об этом не за день до выкладки релиза, а в первый день работы над данной функциональностью.

В заключении заметки о тестировании требований еще раз осмелюсь повторить критерии качества требований к программному обеспечению:

• Корректность
• Недвусмысленность (однозначность)
• Полнота
• Непротиворечивость (совместимость)
• Упорядоченность (ранжированность по важности и стабильности)
• Проверяемость (тестируемость или тестопригодность)
• Модифицируемость
• Трассируемость (прослеживаемость)
• Понятность

Тест- кейсы

Для лучшего понимания раздела, посвященного тест-кейсам, приведу здесь определение этих самых тест-кейсов, которое предлагает энциклопедия Wikipedia (прошу прощения за мой вольный перевод).

Тест-кейс (тестовый случай, test case) — это набор условий и/или переменных, с помощью которых тестировщик будет определять насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию. Для того, чтобы убедиться, что требование полностью удовлетворяется, может понадобиться несколько тест-кейсов. Для полного тестирования всех требований, предъявляемых к приложению, должен быть создан/выполнен по меньшей мере один тест-кейс для каждого требования. Если требование имеет дочерние требования, то для каждого такого дочернего требования должен быть создан/выполнен также по крайней мере один тест-кейс. Некоторые методологии (например, RUP) рекомендуют создавать по меньшей мере два тест-кейса для каждого требования. Один из них должен выполнять позитивное тестирование, другой — негативное.

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

Что формально характеризует написанный тест-кейс? Наличие известного ввода (входные данные) и ожидаемого результата, который достигается после выполнения теста. Входные данные называются предусловиями теста, а ожидаемый результат — постусловиями теста.

Написанные тест-кейсы часто объединяются в тестовые наборы (test suite).

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

Тест-кейсы необходимо писать по требованиям

Начну здесь, пожалуй, с того, что же такое тестирование и какой программный продукт (систему) мы можем назвать качественным. Надеюсь, что дальше станет понятно, почему я начинаю с определения очевидных вещей.

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

Данное определение ни в коем случае не претендует на полноту и описывает процесс тестирования только с одной стороны. С той стороны, которая повернута к требованиям. Именно поэтому не стоит расценивать все, что будет написано дальше, как исчерпывающую инструкцию по написанию тест-кейсов.

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

Что же делают наиболее изобретательные тестировщики? При написании тест-кейсов они пытаются заручиться поддержкой программистов, а если еще точнее, то они пытаются как можно быстрей получить готовую реализацию продукта и писать все тест-кейсы, опираясь на реализованный продукт, т.к. это по их мнению объективно проще и понятней. Это крайне неправильно!

В этом случае получается, что в процессе тестирования проверяется соответствие разработанного продукта разработанному продукту (вот такой каламбурчик). Сами можете представить себе, что из этого получается.

Поэтому, резюмирую все описанное выше — базисом для подготовки тест-кейсов должны быть требования (в том или ином виде), а ни в коем случае не готовый продукт.

---

1234Следующая ⇒

---

Дата добавления: 2016-10-23; просмотров: 601 | Нарушение авторских прав

---

Похожая информация:

Поиск на сайте:

Определение понятия

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

Актуальность метода

Привлекательность метода состоит в том, что он объединяет в себе оперативность тестирования и глубину оценки ассессмент-центра.

Практики системного использования метода на Западе и в России пока нет. Согласно статистике, этим методом испытания, не связанным с общей системой оценки персонала, пользуются не более 10% руководителей.

Сфера применения

Метод можно применять при приеме на работу, аттестации персонала и формировании кадрового резерва.

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

Процедура проведения кейс-тестинга и оценка результатов

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

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

Плюсы и минусы метода

Оценка персонала при помощи кейс-тестинга имеет ряд несомненных достоинств:

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

Главным недостатком кейс-тестинга является узость оцениваемого направления деятельности.

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

Создание кейс-тестингов

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

Для проведения кейс-тестинга можно использовать уже готовые примеры, разработанные по материалам отечественного рынка. Другим вариантом может послужить деятельность компании, сотрудниками которой являются испытуемые. Материал можно получить, анализируя научные статьи, монографии и научные отчеты, посвященные той или иной проблеме. Обширный материал можно также найти в Интернете, причем размещенная там информация как правило отличается актуальностью, масштабностью и оперативностью.

Ссылки

Иван Канардов. «Кейс с секретом»

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

YuriY » 23 мар 2008, 01:11

Traceability matrix (полное название Requirement Traceability Matrix — RTM) — это матрица покрытия функциональных требований тест-кейсами.
Есть даже такое понятие как Requirement based testing, которое имеет место быть, когда есть требования к продукту, на их основе составляются тест-сценарии и выполняется тестирование.
Зачем нужна эта матрица?

Например, для того чтобы:
— при разработке тестов четко ориентироваться какие из требований уже покрыты тестами, а какие еще нет;
— при выполнении тестирования ориентироваться какие из требований прошли все написанные для них тесты успешно, а какие — еще нет.

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

Если кто-то имеет что дополнить, прошу).