Текст книги "tестирование dot com"

Автор книги: Роман Савин

сообщить о нарушении

Текущая страница: 14 (всего у книги 17 страниц)

и баги спека, которые заносятся против продюсера).

Давайте сделаем так:

• сначала рассмотрим процесс концептуально, затем

• привяжем к каждой его стадии наши атрибуты (детальное

рассмотрение процесса), затем

• приведем конкретный пример.

Концептуальное рассмотрение процесса трэкинга багов

Задача 1: После того как мы нашли проблему в ПО, заносим новый

баг.

Задача 2: Программист получает баг, старается понять, в чем про-

блема, и если это действительно баг, то

Задача 3: Программист начинает ремонт.

Задача 4: После того как ремонт закончен, программист

должен сделать checkin кода в CVS.

Задача 5: Релиз-инженер запускает новый билд, чтобы от-

ремонтированный код пришел из CVS на тест-ма-

шину.

Задача 6: Тестировщик проводит регрессивное тестирова-

ние, и если починка НЕ удалась, то

Задача 7: Баг возвращается программисту на но-

вый ремонт.

Если же починка удалась, то

Задача 8: Баг закрывается. Goodbye my love, Goodbye.

Идем обратно к развилке после задачи 2. Допустим, программист

не считает, что зарапортованная ситуация является багом. Тогда он:

Задача 9: Возвращает баг.

Задача 10: Тестировщик старается понять свою ошибку, и

если ошибка имела место и баг соответственно

места не имел, то

Задача 8: Баг закрывается.

Если же тестировщик считает, что это все-таки баг, то

баг отправляется обратно программисту.

Задача 2: Программист снова пытается понять, баг ли это. И т.д.

248

Тестирование Дот Ком. Часть 3

Детальное рассмотрение процесса

Давайте вольем в рассмотренную форму содержимое, состоящее

из атрибутов и их значений, как мы хотим это нашей компании

www.testshop.rs.

Задача 1:

Атрибут

Комментарий по заполнению либо

конкретное(ые) значение(я) атрибута

Summary

Краткое описание

Description and Steps

Описание и шаги...

to Reproduce

Attachment

Используем это поле, если нужна дополнительная

иллюстрация

Assigned to

Имя программиста

Component

Название компонента

Found on

Где был найден баг

Version Found

Номер версии

Build Found

Номер билда

Severity

Значение серьезности

Priority

Значение приоритета

Notify list

По минимуму – имя продюсера

Type

"Bug"

Resolution

"Assigned"

Задача 2:

Программист признает, что это баг:

Задача 3:

Resolution

"Fix in Progress"

Задача 4:

Resolution

"Fixed"

Version Fixed

Номер версии

Build Fixed

Номер билда

Assigned to

Имя релиз-инженера

Задача 5:

Resolution

"Build in Progress"

Жизнь замечательных багов

249

и после того, как новый билд появился на тест-машине:

Resolution

"Verify"

Assigned to

Имя лица из Verifier

Задача 6:

Баг НЕ починен:

Задача 7:

Resolution

"Verification Failed"

Assigned to

Имя программиста

Баг починен:

Задача 8:

Resolution

"Fix is Verified"

Status

"Closed"

Обратно к задаче 2:

Программист НЕ признает, что это баг:

Задача 9:

Resolution

"Can't Reproduce", либо

"Duplicate", либо "Not a

bug", либо "3rd party

bug", либо "No longer

applicable"

Assigned to

Имя тестировщика

Задача 10:

Баг:

Resolution

"Assigned"

Assigned to

Имя программиста

HE баг:

Status

"Closed"

Конкретный пример

Тестировщик Антон Никонов при исполнении тест-кейса #NBST0001

обнаружил новый баг. Он открывает СТБ и заносит в нее нового

жителя:

250

Тестирование Дот Ком. Часть 3

Атрибут: Summary.

Значение:

"Спек. 1211: неверное значение колонки result таблицы

cc_transaction для VISA ".

Атрибут: Description and steps to reproduce.

Значение:

"Description:

При оплате картой VISA в колонке result таблицы

cc_transaction в базе данных записывается неверное значение.

Используйте следующую информацию для воспроизведения

проблемы:

Эккаунт: testuser1/pa$$wOrd

Наименование товара: book117

Данные карты:

Номер: 9999-5148-2222-1277

Окончание действия: 12/07

CVV2: 778

SQL1: select result from cc_transaction where id – <номер

заказа>;

Steps to reproduce:

1. Открой www.main.testshop.rs.

2. Введи имя пользователя.

3. Введи пароль.

4. Нажми кнопку "Войти ".

5. Введи наименование товара в поле поиска.

6. Нажми кнопку "Найти ".

7. Кликни линк "Добавить в корзину ".

8. Кликни линк «Корзина».

9. Кликни линк «Оплатить».

10. Выбери вид карты.

11. Введи номер карты.

12. Введи срок окончания действия.

13. Введи CVV2.

14. Нажми кнопку «Завершить заказ».

15. Запиши номер заказа.

16. Запроси базу данных с SQL1.

Bug: 20.

Expected: 10".

Жизнь замечательных багов

251

Атрибут: Assigned to.

Мистер Никонофф идет на страничку в интранете "Кто ответст-

вен за что" и видит, что программистом Оплаты в настоящее

время является О. Столяров. Так и запишем. Значение:

"О. Столяров".

Атрибут: Component

Значение: "Оплата ".

Атрибут: Found on.

Баг был найден при тестировании на www.main.testshop.rs.

Значение:

«www.main.testshop.rs».

Атрибут: Version Found.

Антон знает, что номер версии и номер билда видны в коммента-

риях HTML-кода на всех страницах нашего веб-сайта. Поэтому он

открывает в окне браузера www.main.testshop.rs, делает клик пра-

вой кнопкой мышки и выбирает View Page Source (посмотреть

код страницы). Запускается текстовый редактор, например Note-

pad (Блокнот), в котором виден HTML-код страницы, и в коммен-

тариях Антон находит номер версии и номер билда, например

7.0-58. Значение: "7.0".

Атрибут: Build Found.

Значение:

"55".

Атрибут: Severity.

Это обычный функциональный баг, четко подходящий под СЗ.

Значение:

"С5 ".

Атрибут: Priority.

Мы должны понять, какие будут последствия в случае если зна-

чение колонки result таблицы cc_transaction не равно 10 при оп-

лате карточкой VISA. Мы задаем вопрос программисту, и выясня-

ется, что в этом случае на машине для пользователей транзакция

будет считаться недействительной, даже если деньги с карточ-

ку будут сняты и соответственно пользователь не получит своего

252

Тестирование Дот Ком. Часть 3

заказа. Довольно серьезный баг, если учесть, что VISA – это наи-

более широко используемая платежная система. Исходя из

вышесказанного, мы должны дать багу приоритет П1. Значение:

"Я7 ".

Атрибут: Notify list.

Согласно странице интранета "Кто ответствен за что", оплата ку-

рируется продюсером В. Новоселовым. Значение:

"5. Новоселов".

Атрибут: Туре.

Значение: «Bug».

Атрибут: Resolution.

Мы знаем имя программиста, который должен заняться багом, и

поэтому ставим резолюцию как «Assigned». Значение: «Assigned».

СТБ присвоила багу номер 3221.

После того как баг был занесен, е-мейлы летят к

• А. Никонову (Submitted by – автор бага),

• О. Столярову (Assigned to – держатель бага) и

• В.Новоселову (лицо из Notify list).

Поскольку держателем бага стал Олег Столяров, то за ним и сле-

дующее действие, а именно рассмотрение проблемы.

Проблема рассмотрена, и баг найден в коде Python файла

create_payment.py:

ifcredit card== «VISA»:

update _db(" update cc transaction set result = 20 where exter-

nal id = " + transaction id).

Этот код, переведенный на язык Пушкина и Булгакова, означает:

Если используется кредитная карта VISA,

сделай значение колонки result таблицы cc_transaction рав-

ным 20 в строке, где значение колонки externalid равно

значению переменной transactionid.

Жизнь замечательных багов

253

Как видим, это простой в починке баг, который исправляется из-

менением цифры 2 на цифру 1:

if credit card == "VISA ":

update_db("update cc transaction set result – 10 where exter-

nal id – " + trans action id).

Олежек входит в СТБ:

Атрибут: Resolution.

Значение:

"Fix in Progress ".

Олежек исправляет баг на своем плэйграунде, делает скоренький

юнит-тест и сохраняет баг в бранче CVS для релиза 7.0 и в стволе.

Затем он снова входит в СТБ и передает баг дальше:

Атрибут: Resolution.

Значение:

«Fixed».

Атрибут: Version Fixed.

Значение:

«7.0».

Атрибут: Build Fixed.

Значение:

«59».

Сегодня вторник, а значит, согласно страничке в интранете "Рас-

писание релиз-инженеров", новый билд может запустить для нас

релиз-инженер С. Щетинин, который сегодня находится на де-

журстве по всем вопросам, связанным с багами.

Атрибут: Assigned to.

Значение:

"С. Щетинин".

С. Щетинин, только что вернувшийся с обильного обеда, про-

шедшего в ресторане «Mayflower» в окружении институтских

дружков, таких же, как он, тунеядцев и игроков в покер, получает

от СТБ е-мейл о том, что он стал новым держателем бага #3221.

С. Щетинин является держателем и множества других багов,

ждущих своего регрессивного тестирования. Согласно распи-

санию билдов в компании www.testshop.rs, у нас есть 3 билда

254

Тестирование Дот Ком. Часть 3

в день: в 12:00, 15:00, 18:00 по московскому времени. Сейчас 14:45,

и через 15 минут Станислав должен запустить новый очередной

билд (59) для версии 7.0.

Запустив билд-скрипт для версии 7.0, он входит в СТБ и среди

прочих меняет и #3221:

Атрибут: Resolution.

Значение:

"Build in Progress ".

После того как билд-тест сайта www.main.testshop.rs завершен и не

было никаких ошибок (например, проблем с интеграцией кода одного

программиста с кодом другого), сеньор Щетинин снова идет в СТБ:

Атрибут: Resolution.

Значение:

«Verify».

Атрибут: Assigned to.

Значение:

"А. Никонов".

Если ошибки поломали билд, то начинается выяснение и устра-

нение. Ошибка может быть допущена как релиз-инженером, так

и программистом. В последнем случае срочно посылают е-мейлы

программистам с целью выяснить, чем код поломал билд, чтобы

те немедленно разобрались, в чем дело. Если проблема сломан-

ного билда (broken build) не решается в течение, скажем, 60 ми-

нут, то, согласно правилам нашей компании, С. Щетинин воз-

вращает на www.main.testshop.rs предыдущий билд, т.е. 58.

Тестировщик Антон Никонов получает радостное известие, что

баг #3221 был зафиксирован и отремонтированный код ждет его

на www.main.testshop.rs. Удостоверившись, что www.main.testshop.rs

имеет версию и билд 7.0-59, он исполняет шаги, указанные в

"Описании и шагах..." бага, и, удостоверившись, что значение

result стало равным 10, закрывает баг:

Атрибут: Resolution.

Значение:

«Fix is Verified».

Атрибут: Status.

Значение: «Closed».

Жизнь замечательных багов

255

А затем в качестве второй части регрессивного тестирования ис-

полняет, например, тест-кейс с картой MasterCard. Флоу с

MasterCard – это приоритетное флоу функциональности Оплата,

и неплохая идея проверить, что ремонт ситуации с VISA не сломал

флоу с MasterCard.

Краткое подведение итогов

1. СТБ —это

• с одной стороны, хранилище багов, а

• с другой – средство коммуникации.

2. Баг – это в зависимости от контекста

• расхождение между фактическим и ожидаемым результатами

и/или

• запись (виртуальная карточка) в СТБ.

3. Настройки СТБ определяются процессом, а не наоборот.

4. Настройками СТБ и созданием эккаунтов ведает администратор

СТБ.

5. Занести баг может любой, у кого есть счет в СТБ и соответст-

вующая привилегия.

6. У бага в СТБ есть атрибуты, значения которых позволяют судить

о состоянии и истории бага.

7. Значения некоторых атрибутов присваиваются автоматически

(номер бага).

8. Мы никогда не заносим баг с кратким описанием "Ничего не

работает".

9. Приложение (attachment) – это суперполезная вещь, так как

служит графической (как правило) иллюстрацией бага.

10. У каждого открытого бага всегда есть держатель.

11. На интранете обязательно должна быть страничка "Кто ответ-

ственен за что".

12. Серьезность бага —это техническая категория.

13. Приоритет бага – категория, связанная с бизнесом.

14. Нет ни одного изменения бага, которое бы не стало достоянием

гласности.

15. Функциональность – это только одно из значений емкого тер-

мина фича.

16. Значения резолюции – это этапы жизни бага.

Вопросы и задания для самопроверки

1. Могут ли простые бумажные карточки или текстовый файл слу-

жить в качестве СТБ?

2. Приведите пример формата значения атрибута "Шаги и ожи-

даемый результат".

256

Тестирование Дот Ком. Часть 3

3. Чем били по голове тех, кто заносил баг с кратким описанием

"Ничего не работает"?

4. Перечислите элементы веб-страницы и проблемы, с ними свя-

занные.

5. Как сделать графический файл с тем, что мы видим на экране

монитора?

6. Основная обязанность держателя бага.

7. Что должен проверить Verifier перед началом регрессивного

тестирования?

8. Приведите две части регрессивного тестирования. Нужно ли

проводить вторую часть, если первая не работает? Можно ли

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

9. В чем концептуальное различие серьезности и приоритета?

10. Кого мы обычно включаем в Notify list?

11. Дайте определение фича.

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

заново?

13. Что нужно делать для того, чтобы программисты не возвращали

вам баги как «Not Reproducible'»?

14. Почему возникают ситуации, когда баг возвращается с резо-

люцией «Not a bug»?

15. Нарисуйте блок-схему процесса трэкинга багов.

ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.

СТАДИЯ 1:

ТЕСТИРОВАНИЕ НОВЫХ ФИЧА

• TEST ESTIMATION (ТЕСТ-СМЕТА)

• ENTRY/EXIT CRITERIA (КРИТЕРИЙ НАЧАЛА/ЗАВЕРШЕНИЯ)

• TEST PLAN (ТЕСТ-ПЛАН)

отя при разговоре о процессе разработки ПО мы перевели

Х «New Feature Testing» как "Тестирование новых компонен-

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

Исполнение тестирования состоит из двух стадий, идущих в сле-

дующей очередности:

1. Тестирование новых фича (new feature testing);

2. Регрессивное тестирование (regression testing).

Сначала о стадии 1.

После того как код проинтегрирован, тест приемки пройден и код

заморожен, мы начинаем тестирование новых фича.

Кстати, тест приемки – это, как правило, эд хок-тестирование, при ко-

тором мы проверяем, работают ли самые базовые вещи, как, например,

создание нового эккаунта. Я рекомендую составить список с такими

базовыми вещами, например:

Создай новый эккаунт

Войди в систему

Добавь книгу в корзину... и во время теста приемки мы просто идем

от строчки к строчке и делаем проверку. Тест приемки считается

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

исход.

257

Исполнение тестирования. Стадия 1: тестирование новых фича

259

Кстати, хорошая традиция – это устроить в конце подготовки к тести-

рованию (или начале исполнения тестирования) совещание, на кото-

ром каждый тестировщик, у которого есть новая фича, сделал бы ее

короткую, например на две минуты, презентацию. Таким образом мы

быстро и эффективно распространяем информацию о новых фича, так,

чтобы все были в курсе.

Вопрос: Как мы тестируем новые фича?

Ответ: Все очень просто: берем в зубы тест-кейсы и исполняем

их. Попутно заносим баги. Спорим с программистами о приори-

тетах этих багов. Закрываем эти баги. Одним словом, обычная

суета сует.

Это в общем-то все насчет стадии 1 исполнения тестирования, но,

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

скольких нужных вещах:

• Test Estimation (тест-смета).

• Entry/Exit Criteria (критерий начала/завершения).

• Test Plan (тест-план).

Test Estimation (тест-смета)

Как правило, в интернет-компаниях существует расписание рели-

зов. К этому расписанию привязано расписание тестирования (QA

Schedule), которое определяет сроки каждой стадии процесса тес-

тирования.

«Как правило» было употреблено из-за того, что в некоторых

компаниях такого понятия, как «Расписание», не существует в

принципе.

Итак, допустим, что

• на подготовку к тестированию дается две недели (10 ра-

бочих дней (80 часов) + 4 выходных дня (32 часа), которые

элементарно могут стать рабочими);

• на исполнение тестирования также дается две недели

(10 рабочих дней (80 часов) + 4 дня выходных дня (32 часа),

которые также элементарно могут стать рабочими),

т.е. у нас есть

две недели на написание тест-кейсов (и прочие подготови-

тельные мероприятия) и

260

Тестирование Дот Ком. Часть 3

две недели, в которые нужно уместить:

• тестирование новых фича по созданным тест-кейсам;

• регрессивное тестирование.

Проблема в том, что, как бы ударно мы ни работали, мы можем

выполнить лишь определенный объем работы и возникает кон-

фликт между

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

неса компании, и

• физическими возможностями продюсера, программиста и

тестировщика.

Чтобы уравновесить желаемое и реальное, используют сметы

(estimation).

Тестировщик готовит тест-смету (Test Estimation), которая вклю-

чает:

• предварительную оценку времени, необходимого на под-

готовку к тестированию;

• предварительную оценку времени, необходимого на тести-

рование новых фича.

Как тестировщик готовит тест-смету? Очень просто:

после того как написан спек, менеджер тестировщика просит по-

следнего прочитать этот спек и оценить, сколько времени займут

написание тест-кейсов по этому спеку и прочие подготовитель-

ные мероприятия и исполнение этих тест-кейсов. Тестировщик

читает спек, предметно общается с продюсером и программистом

и на основе полученной информации и своего опыта предостав-

ляет менеджеру два числа, являющиеся тест-сметой для данного

спека.

Пример

Для создания тест-сметы тестировщику был дан спек #1299 "Новые

функциональности поиска".

Тестировщик предоставил своему менеджеру следующее:

• потребуется 50 часов на написание тест-кейсов и 20 часов на

написание тест-тулов;

• потребуется 60 часов на исполнение этих тест-кейсов.

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

подготовке к тестированию (80 – 50-20 >0). Оставшиеся 10 часов

можно будет использовать для помощи своим коллегам и/или как ре-

Исполнение тестирования. Стадия 1: тестирование новых фича

261

зерв на случай, если оценка тестировщика была неверной и на подго-

товку в реальности потребуется больше времени.

Сложнее обстоит дело с исполнением тестирования. На регрессивное

тестирование остается только 20 часов (80 – 60). Будет ли этих 20 ча-

сов достаточно, чтобы закончить регрессивное тестирование в срок?

Это зависит от нескольких факторов, основные из них:

• значительность релиза, например: имело ли место серьезное

изменение архитектуры ПО? На сколько процентов изменилось

количество строк кода? Были ли добавлены новые критические

функциональности, интегрированные со старым кодом? и пр.;

• трудоемкость тест-комплектов, которые нужно исполнить для

регрессивного тестирования (подробно поговорим о нюансах

регрессивного тестирования через полчаса).

Ответ на последний вопрос («будет ли достаточно 20 часов?»), как и

сам процесс уравновешивания потребностей бизнеса и возможностей

работников, – это епархия менеджмента, а мы люди простые, и наше

дело – дать предварительные оценки, по возможности приближенные

к недалекой реальности.

Итак, как создать тест-смету?

Сложность заключается в том, что тест-смета создается после

того, как прочитан спек, а между чтением спека и работой по не-

му такая же дистанция, как между теоретиком и практиком кун-

фу. Во время работы над спеком, т.е. создания по нему тест-

кейсов, открываются такие грани и нюансы, о существовании ко-

торых было трудно (если не невозможно) предположить во время

простого прочтения. Кроме того, всегда есть непредвиденные

обстоятельства, среди которых может быть, например, неприлич-

но большое количество блокирующих багов.

Кстати,

после того как тест-смета готова, рекомендую увеличить ее на 10%,

чтобы учесть такие непредвиденные обстоятельства.

Вот факторы, которые я рекомендую принять во внимание при

составлении сметы:

• предполагаемая сложность новых фича.

Чем они сложнее, тем больше нюансов всплывет при под-

готовке и исполнении и тем больше времени понадобится

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

• есть ли у вас опыт тестирования похожих фича.

Например, если вы эксперт в тестировании оплаты, то для

вас будет проще и быстрее протестировать добавление

262

Тестирование Дот Ком. Часть 3

еще одного вида кредитной карточки по сравнению с

тестировщиком, который никогда кредитных карточек не

касался;

• опыт работы на прошлых проектах с теми же продюсе

ром и программистом.

Например, одни программисты пишут удивительно чистый

код, всегда проводят юнит-тестирование и с охотой

кооперируются с тестировщиками. Другие же бросают

куски кода в проект, как грязь на стену, считают юнит-

тестирование вещью, не подобающей для компьютерного

гения, и не склонны кооперироваться ни с кем, кроме

виртуальных солдат игры Halo. Следовательно, во втором

случае мы должны заложить больше времени на наше тес-

тирование;

• будет ли интеграция нашего ПО с ПО наших бизнес-парт

неров – вендоров (vendor),

например интеграция с ПО платежной системы. Тест-кон-

фигурация выглядит так: наша тест-машина "разговари-

вает" с их тест-машиной. Соответственно если что-то не в

порядке с их тест-машиной, то проблема решается слож-

нее, чем при локальном тестировании, когда вы заносите

баг и наш программист его ремонтирует. В случае с их

тест-машиной

• тестировщик связывается с менеджером проекта (с на-

шей стороны);

• последний должен позвонить вендору;

• человек со стороны вендора должен найти ответст-

венного программиста;

• ответственный программист может быть занят

• и т.д. и т.п.

В общем целая петрушка из-за того, что это другая ком-

пания и наши тестировщики не указ "их" программистам.

В случае с интеграцией нашего ПО с не нашим ПО оценка

должна принимать в расчет подобные задержки в решении

проблем, которые при такой интеграции бывают всегда;

• нужны ли тулы для автоматизации тест-кейсов?

Тест-тулы, как правило, создаются во время написания тест-

кейсов как средство для облегчения исполнения тест-кейса,

например:

Исполнение тестирования. Стадия 1: тестирование новых фича

263

• генерация данных (например, генерация номера тес-

тировочной кредитной карты),

• автоматизация всех либо части шагов,

• помощь в сравнении фактического и ожидаемого ре-

зультатов.

В одних случаях тестировщик может сам написать такой

тул, например, на языках Java или Python. В других

случаях написание тула в помощь тестировщи-кам – это

дело программиста.

Кстати,

в некоторых компаниях внутри департамента качества существую!

специальные отделы по созданию тест-тулов.

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

шей оценки того:

• сколько времени у вас займет создание (включая тестиро-

вание) такого тула (если тул создается вами, а не програм-

мистом);

• сколько времени этот тул сможет реально сэкономить во

время тестирования новых фича.

Итак, при составлении тест-сметы используем вышеперечислен-

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

коллегами.

Упоминание о тест-тулах напомнило мне об одном предмете, который

особенно беспокоит сердца обучающихся тестированию, а именно

объеме компьютерных знаний.

Вот мое мнение: естественно, что наивно думать об устройстве тес-

тировщиком в интернет-компанию тому, кто не умеет пользоваться

е-мейлом и веб-браузером и не знает разницы между принтером и

модемом.

Хорошая новость: на первую работу тестировщиком можно устроить-

ся, имея базовые компьютерные знания, которые есть у каждого, кто

пользовался компьютером и Интернетом больше одного месяца.

Конечно, шансы трудоустройства существенно повышаются, если

у вас есть дополнительные к базовым знания (приведу конкретные

рекомендации через минуту).

Давайте скажем "Спасибо" океану информации под названием "Ин-

тернет" за

264

Тестирование Дот Ком. Часть 3

• гигабайты бесплатного ПО, например компайлеры для C++ и

интерпретаторы Python;

• тысячи бесплатных курсов по компьютерным дисциплинам, на-

пример пособия по изучению языка SOL;

• интернет-форумы на любую тематику, где любой оболтус (вклю-

чая меня) может задать самый идиотский вопрос и получить

на него ответ;

• веб-сайты, бродя по которым мы попутно становимся квалифи-

цированными пользователями Интернета;

• десятки других милых и полезных вещей.

Используйте ресурсы Интернета!!! В нем есть все, что вам нужно, что-

бы стать тестировщиком экстра-класса.

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

перед поиском первой работы. Потратьте по крайней мере по 10 ча-

сов на каждое "прикосновение", причем не просто читайте теорию,

а работайте с соответствующим ПО (или на соответствующем ПО),

например:

• в случае с UNIX исполняйте команды, например команду «mkdir»,

для создания директории или

• пишите код на Python.

1. HTML. Основной язык веб-страниц. Веб-учебник (web tutorial)

на английском языке и программа для симуляции может быть

найдена здесь: http://www.w3schools.com. Изучите базовые теги

(tag).

2. SQL. Язык баз данных. Веб-учебник на английском языке можно

найти здесь: http://www.w3schools.com. Разберитесь с синтакси-

сом следующих видов запросов (statements):

CREATE TABLE;

ALTER TABLE;

DROP TABLE;

INSERT INTO;

UPDATE;

DELETE;

SELECT.

Скачайте и установите на ваш компьютер базу данных MySQL

(http://www.mysql.com/).

3. Python. Веб-учебники на английском языке и установочную про-

грамму для интерпретатора можно найти на http://www.python.org.

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

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

4. UNIX. Вот наипростейший веб-учебник:

http://www.math.utah.edu/lab/unix/unix-tutorial.html. Симулятор UNIX

для Виндоуз-машин можно скачать здесь: http://www.cygwin.com.

Исполнение тестирования. Стадия I: тестирование новых фича

265

5. C++. Веб-учебник может быть найден здесь:

http://www.cplusplus.com/doc/tutorial. Напишите несколько про-

грамм, скомпилируйте их, откройте в текстовом редакторе файлы-

источники (source file), скомпилированные файлы (bytecode file)

и ощутите разницу. Компайлер дсс является частью симулятора

CygWin, которую вы установите при знакомстве с UNIX.

Естественно, что мои пояснения о том, ЧТО изучить для каждого из

вышеуказанных 5 предметов, – это минимум для того, чтобы иметь

элементарное представление, но даже такой минимум – это ваш ко-

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

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

терпение и приложить немного усилий.

После того как вы найдете работу, специфика ваших технических зна-

ний будет во многом определяться технологиями, используемыми в

вашей интернет-компании (например, операционная система маши-

ны для пользователей, языки программирования, вид базы данных).

Некоторые из тех, кто начал работать тестировщиком на черноящич-

ном тестировании, распробовали знания из смежных специальностей

(например, администрация баз данных) и переместились туда;

некоторые выбрали себе узкую специализацию внутри департамента

качества, например написание тест-тулов;

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

заниматься черноящичным тестированием или же перешли к серо-

ящичным или белоящичным делам – к чему лежит душа.

Но чтобы найти в итоге свою нишу, нужно искать, а лучший по-

иск – это изучение новых вещей.

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

тестировщик соприкасается с множеством вещей как техниче-

ского (язык программирования), так и нетехнического свойства

(менеджмент проекта), так что вам и карты в руки – разбери-

тесь на месте, что вам больше нравится, и приложите усилия,

чтобы в итоге заниматься именно этим. Шансы велики, что это

будет именно тестирование.

Entry/Exit Criteria

(критерий начала/завершения)

Все очень просто.

Entry Criteria (условие старта) – это условие для начала чего-

либо.

Exit Criteria (условие завершения) – это условие для завершения

чего-либо.

266

Тестирование Дот Ком. Часть 3

Каждый из двух этапов тестирования имеет свои условия старта и

условия завершения.

Например

Условие старта для подготовки к тестированию: все спеки должны быть

заморожены.

Условие завершения подготовки к тестированию: тест-кейсы и прочие

подготовительные мероприятия написаны и закончены.

Условие старта для исполнения тестирования: код заморожен.

Условие завершения исполнения тестирования: тестирование новых

функциональностей и регрессивное тестирование завершено, нет от-

крытых П1 и П2 багов.

Test Plan (тест-план)

Вопрос: Почему мы не поговорили о тест-планах при нашей бе-

седе о тест-кейсах и тест-комплектах? Ответ: Я не хотел

забивать вам головы.

Вопрос: Тогда почему вы их забиваете сейчас?

Ответ: Потому что с теми знаниями, которые у вас уже есть, вам

будет проще понять этот материал.

Итак, приступим.

Что такое тест-план? Если вы спросите тестировщиков разных

компаний о том, что идет под именем "тест-план" в их компа-

ниях, то ответ часто будет варьироваться:

• иногда тест-планом называют тест-комплект,

• в других случаях тест-планом называют пару мыслей о тес-

тировании, набросанных на полях журнала «Playboy»,

• в третьих случаях тест-планом называют текстовый доку-

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

проводится тестирование (такое тоже бывает сплошь и рядом),

• есть еще и четвертые, и пятые случаи.

Вот концептуальная вещь:

• тест-кейс нужен для сравнения фактического результа-

та с ожидаемым результатом;

• тест-комплект – это логическая оболочка для хране-

ния тест-кейсов;

• тест-план – это документ, обобщающий и координи-

рующий тестирование.

Исполнение тестирования. Стадия 1: тестирование новых фича

267

Я обычно ограничиваюсь тест-комплектами и создаю тест-план,

если возглавляю проект с участием других тестировщиков.

Давайте рассмотрим элементы, которые вы можете использовать

в тест-планах.

Кстати, вовсе не обязательно использовать все элементы:

1. Вы можете взять элементы (и/или идеи из них) и интегрировать их

в свои тест-комплекты;

2. Вы можете использовать тест-план в усеченном виде.

Итак...

ЭЛЕМЕНТЫ ТЕСТ-ПЛАНА

1. Название тест-плана, имя автора и номер версии.

Например

«Тест-план проекта „Новые алгоритмы для поиска“». Автор Т. Чере-

мушкин. Версия 2.

2. Оглавление с разделами тест-плана:

Например

Введение

стр. 2

Документация с требованиями к ПО стр. 3 и

т. д.

3. Введение, в котором мы приводим информацию о сути и исто-

рии тестируемого проекта.

4. Документация с требованиями к ПО – здесь мы перечис-

ляем имена, номера и приоритеты спеков и/или другой докумен-

тации, определяющей тестируемые фича.

5. Фича, которые будут тестироваться, перечисляем и, если

нужно, комментируем. Каждой фича назначается приоритет.

6. Фича, которые НЕ будут тестироваться, перечисляем и объ-

ясняем, почему НЕ будут тестироваться.

Например,

частью спека #9172 «Улучшение безопасности платежных транзакций»

являются требования к скорости работы веб-сайта (performance). До-

пустим, у нас нет ни специалиста, ни ПО для тестирования скорости

работы, и если мы не собираемся их нанять и приобрести, то указываем,