QA (rus)

Тестирование. Книга первая. Тест-кейсы и QA

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

Моя первая книга – “test dot com” Романа Савина.

Как всегда – делаю себе пометки, попутно отмечая что следует читать.

Начну с терминологии:

Баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result). То есть у нас есть баг при наличии любого фактического результата, отличного от ожидаемого (после их поиска и сравнения).  Логично, что источником ожидаемого результата является спецификация. Например, мы (аналитики) это пишем в сценариях использования: результатом будет бла-бла-бла. Оказывается, что это очень помогает тестировщикам. На всякий случай:

Спецификация (или spec — читается “спек”. Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. То есть баг – отклонение от спецификации. Следует помнить, что в спецификациях уже могут быть заложены ошибки. У нас самих, впрочем, есть  такое понятие, как тестирование требований (в виде ревью спецификаций).

Кстати, вот некоторые рекомендации:

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

Цель тестирования — это нахождение багов до того, как их найдут пользователи. Кстати,один из критериев качества кода — это количество багов на 1000 строк кода. Количество багов, найденных до релиза, ничего не говорит об эффективности тестирования. Баги, найденные после релиза, — вот чего не должно быть. Кстати, вы никогда не сможете протестировать систему на 100%, вам просто не дадут на это времени.

Хорошая практика: после каждого релиза данные о багах классифицируются по заданным критериям и анализируются на предмет нахождения слабого звена в процессе разработки ПО. Критериями могут быть приоритет, функциональность, имя тестировщика и др. Если вы сможете улучшить ситуацию, то вы можете брать на себя функции QA.

QA — это забота о качестве в виде превентирования появления багов, тестирование — это забота о качестве в виде обнаружения багов до того, как их найдут пользователи. QA призвано улучшить ПО через улучшение процесса разработки ПО.

Тест-кейсы

Тест-кейсы похожи на наши, аналитиков, сценарии использования, определения и особенности я приведу ниже. Набор тест-кейсов (test caseы) является тест-комплектом (test suite).Процесс придумывания и написания тест-кейса называется созданием тест-кейса (test case generation). Процесс проверки тест кейса — исполнением тест-кейса (test case execution).

Тест кейс состоит из его ID, приоритета, Идеи (это описание конкретной вещи, проверяемой тест-кейсом),  подготовительная часть, история редактирования, можно ещё указать приоритет. Ну и сам тест кейс выглядит так:

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

Если результатов несколько, то фиксируйте, на каком шаге проверять результат. Напоминаю, что если требуется узнать о чем-то более подробно, то придется смотреть это в книге.

Теперь снова по определениям.

Совокупность тест-кейсов (находящихся, как правило, в одном документе), которые проверяют

• какую-то определенную часть нашего интернет-проекта(например, “Оплату”) и/или

• определенный спек (например, спек номер 1455 “Рассылкапользователям е-мейлов на основании истории заказов”),

называют тест-комплектом (test case suite).

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

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

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

Исполнение тест-кейса завершается либо положительным(pass), либо отрицательным (fail или баг!!!) результатом. Причем именно отрицательный результат является желанным, так как мы нашли баг. Исполнение тест-кейса не является завершенным, если исполнитель не смог “пройти” все шаги.

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

К плохому стилю относятся: а) зависимость тест-кейсов друг от друга; б) нечеткая формулировка шагов; в) нечеткая формулировка идеи тест-кейса и/или ожидаемого результата.

Хорошим стилем является создание нового тест-комплекта для новых тест-кейсов.

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

Состояние тест-кейса: “Новый”, “Измененный”, “Болеенедействителен”. Хорошая практика — не удалять (remove) отжившие свой век тест-кейсы (или целые тест-комплекты), а переносить их (move) в отдельную директорию, специальносозданную для таких пенсионеров.

Стоимость бага — это

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

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

Объективная оценка убытков в большинстве случаев невозможна.

Примечание. Часто ли при вводе адреса есть проверка, чтобы символ @ не был указан 2 раза?

Вывод

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

Advertisements
Standard

2 thoughts on “Тестирование. Книга первая. Тест-кейсы и QA

  1. Pingback: Тестирование. Книга первая. Юнит-тестирование, виды тестирования « Блог Алексея Киселева

  2. гоша says:

    Там нет противоречия, все ясно: мощь ,демонстрируемая одной стороной, мощь до тех пор, пока, другая сторона не показала несостоятельность этой мощи – все ясно, ))

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s