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

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

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

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

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

268

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

7. Объем тестирования – виды тестирования, которые мы бу-

дем проводить, и разъяснения к ним.

Например

"Системное тестирование будет исполняться для проверки всего флоу

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

веркой значений базы данных и подтверждением от тест-машины

вендора".

8. Тест-документация – перечисление тест-документации, ко-

торая должна быть создана для данного проекта

Например

"Тест-комплект по тестированию опека #1288.

Тест-комплект по тестированию спека #3411".

9. Тест-тулы – функциональности тест-тулов, которые должны

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

10. Критерий начала/завершения – те самые критерии, о кото

рых мы говорили минуту назад:

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

• критерий завершения подготовки к тестированию;

• критерий начала исполнения тестирования;

• критерий завершения исполнения тестирования.

11. Допущения – список допущений, которые мы сделали при

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

вании.

Например,

мы допускаем (предполагаем), что код будет заморожен в срок, без

задержки.

12. Зависимости – список вещей (с пояснениями), от которых

зависит та или иная часть тестирования.

Например,

покупка новых тест-машин,

лицензия на осуществление платежных операций на территории Вели-

кобритании.

13. "Железо" и ПО – список и конфигурации «железа» и ПО,

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

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

269

14. Условия приостановки/возобновления тестирования – это

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

продолжено.

Например,

к условию приостановки можно отнести количество П1 багов, при ко-

тором (и/или после которого), по мнению автора (-ров) тест-плана,

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

7 П1). Соответственно условием возобновления должно быть количе-

ство оставшихся П1 багов (после ремонта и регрессивного тестирова-

ния), которое позволяет возобновить тестирование (например, 2 П1).

15. Ответственные лица – подробный список товарищей (про-

дюсеров, программистов, тестировщиков и пр.), контактная ин-

формация и обязанности каждого из них. Такой список может

включать лиц со стороны вендора.

16. Тренинг – тренинг, необходимый для данного проекта.

Например,

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

кейсов тестировщику необходимо прослушать семинар "Банковская

система США".

17. Расписание – сроки, имеющие отношение к тестированию

данного проекта:

• дата замораживания спеков;

• дата начала подготовки к тестированию;

• дата завершения подготовки к тестированию;

• дата интеграции и замораживания кода;

• дата начала тестирования новых фича;

• дата завершения тестирования новых фича;

• дата начала регрессивного тестирования;

• дата завершения регрессивного тестирования.

18. Оценка риска – предположение о том, как и что может пой

ти по неправильному пути и что мы в этом случае предпримем.

Например,

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

ние «Условия завершения», например, «все тест-кейсы исполнены») в

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

ходные и праздники.

Кстати, если народ приходит в выходные и праздники, то компания

должна, по крайней мере, кормить его обедом.

270

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

19. Прочие положения – вещи, не вошедшие в тест-план, о ко-

торых неплохо было бы упомянуть.

20. Утверждения – это подписи лиц, которые утвердили тест-

план. Чем больше будет таких подписей, тем лучше. По крайней

мере, нужны подписи менеджера тестировщика, составившего

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

21. Приложения – например, расшифровка терминов и аббре-

виатур, используемых в тест-плане.

Это все о тест-планах и о первой стадии исполнения тестирова-

ния.

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

СТАДИЯ 2:

РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ

• ВЫБОР ТЕСТ-КОМПЛЕКТОВ ДЛЯ РЕГРЕССИВНОГО

ТЕСТИРОВАНИЯ

• РЕШЕНИЕ ПРОБЛЕМЫ ПРОТИВОРЕЧИЯ

егрессивное тестирование как второй этап исполнения тес-

Ртирования – это проверка того, что изменения, сделан-

ные в ПО (для того, чтобы мир увидел новые фича), не поло-

мали старые фича.

Допустим, у нас есть 5 тест-комплектов с тест-кейсами для новых

фича, а также 21 тест-комплект с тест-кейсами для старых фича.

Ситуация эта рождает как минимум два вопроса:

1. Какие из этих 21 тест-комплекта выбрать, чтобы:

• проверить именно те части ПО, которые могли быть по-

ломаны?

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

рования (например, 5 рабочих дней + два выходных дня,

которые вполне могут стать рабочими)?

2. Что делать с регрессивным тестированием дальше, ко

гда после релиза к 21 тест-комплекту прибавятся еще 5

(тест-комплекты, которые проверяли новые фича, прим

кнут к остальным тест-комплектам и станут кандидатами

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

следующего релиза и т.д. (постоянно нарастающий снеж

ный ком)?

271

Исполнение тестирования. Стадия 2: регрессивное тестирование

273

Итак, две темы:

1. Выбор тест-комплектов для регрессивного тестирования.

2. Решение проблемы противоречия между ограничен-

ными ресурсами (например, время на регрессивное тес-

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

вом тест-комплектов.

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

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

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

альности компании, в которой будете работать.

Выбор тест-комплектов

для регрессивного тестирования

Первый вопрос: "Как узнать, какие части ПО могут быть поломаны?"

С одной стороны, как мы уже не раз говорили, в сложной системе,

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

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

ние кода, с другой – мы все-таки можем предполагать:

• к какой части ПО принадлежат новые фича (например,

фича из спека #5419 "Новые функциональности для Кор-

зины" принадлежат к "Корзине") и

• какие старые фича напрямую зависят от части ПО с

новыми фича (например, компонент «Оплата» использует

данные (по ценам книг), которые передаются ей компонен-

том "Корзины").

Решение следующее:

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

нас будут тест-комплекты, проверяющие часть ПО, к которой

принадлежат новые фича.

Например,

при новых фича для «Корзины» в первую группу идут все тест-комплек-

ты, непосредственно тестирующие «Корзину».

Рациональное объяснение:

если программист напортачил с кодом, то фича, тестируемые тест-

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

как являются частью ПО с измененным кодом.

274

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

Второй группой кандидатов для регрессивного тестирования у

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

зависят от части ПО с новыми фича.

Например,

при новых фича для «Корзины» во вторую группу мы можем отнести

тест-комплекты, проверяющие «Оплату».

Рациональное объяснение:

если даже программист НЕ сломал ничего, есть большая вероят-

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

части ПО, также нуждается в модификации (о необходимости ко-

торой и продюсер, и программист могли просто... забыть).

Например, при изменениях в коде «Корзины» был легитимно (согласно

спеку) изменен формат куки (cookie – файл с информацией о вашем

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

вером). Часть же ПО, которая заведует «Оплатой», не была модифи-

цирована (или была модифицирована неверно), и она (эта часть ПО)

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

не представляется возможным.

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

Пока же допустим, что группы только две.

Проиллюстрируем:

Группа

Номер тест-комплекта

1

#XS1111

#TS1222

#TS1333

2

#TS2444

#TS2555

#TS2777

#TS2888

#TS2999

Теперь вопрос второй: "Как уложиться в срок, выделенный для

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

Допустим, что у нас есть два тестировщика и неделя времени, т.е.

80 человеко-часов (112 – с выходными, 336 – без сна и отдыха).

Вопрос: Сможем ли мы исполнить все 8 тест-комплектов за эти

80 часов?

Исполнение тестирования. Стадия 2: регрессивное тестирование

275

Ответ: Очевидно, что для этого нужно знать, сколько времени

занимает исполнение каждого из этих тест-комплектов.

Вопрос: Как это узнать?

Ответ: Каждая компания делает по-своему. В одних компаниях

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

исполнение каждого из тест-комплектов (иногда даже считается

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

го исполнения тестировщик указывает время исполнения в шапке

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

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

мает исполнение каждого тест-комплекта.

«Примерно» – потому что исполнение тест-комплекта может

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

няет (хотя есть и другие факторы). На практике, особенно в слу-

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

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

конкретный тест-комплект.

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

каждого тест-комплекта.

Оговорка: в реальной жизни исполнение тест-комплектов, как

правило, занимает гораздо меньше времени, чем в примере ниже,

но нам нужна наглядность.

Группа

Номер тест-комплекта

Время на исполнение

(в часах)

1

#TS1111

10

#TS1222

15

#TS1333

17

2

#TS2444

18

#TS2555

12

#TS2777

14

#TS2888

26

#TS2999

19

Итого, 131 час, что больше запланированных 80, и даже если мы

будем работать в выходные, то не хватает 19 часов (131 – 112).

Эти 19 часов могут быть, например, распределены на работу в

сверхурочное время: примерно 2 часа 40 минут плюс к нашим

276

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

восьми часам семь раз в неделю (19 : 7). Кстати, так и поступают

во многих стартапах.

Но допустим, что наш www.testshop.rs не относится к этим мно-

гим и славится человечным отношением к своим работникам.

Итак, нам, гуманистам, не хватает 51 часа (131– 80) для исполне-

ния регрессивного тестирования. Что можно сделать? Среди прочих

вещей, таких, как заимствование сотрудников из других отделов,

можно сделать следующее: у нас есть приоритет каждого из тест-

комплектов. Так давайте же исполним самые приоритетные из них!

Группа

Номер тест-комплекта

Время на исполнение

Приоритет

(в часах)

1

#TS1111

10

1

#TS1222

15

3

#TS1333

17

4

2

#TS2444

18

4

#TS2555

12

2

#TS2777

14

1

#TS2888

26

3

#TS2999

19

2

Если мы исполним тест-комплекты

• только 1-го приоритета, то регрессивное тестирование возь-

мет 24 часа (10+ 14);

• только 1-го и 2-го, то – 55 часов (24 + 12 + 19);

• только 1, 2 и 3-го, то – 96 часов (55 + +5 + 26), это нам не

подходит.

Итак, мы исполняем тест-комплекты 1-го и 2-го приоритетов.

Оставшиеся 25 часов (80 – 55) можно отдать на исполнение, на-

пример:

• спека #1222 (15 часов), либо

• спека #2888 (26 часов), либо

• исполнить наиболее приоритетные тест-кейсы из обоих этих

тест-комплектов (самая лучшая идея).

Концепция, думаю, понятна.

Кстати,

определение списка тест-комплектов для регрессивного тестирования –

это, как правило, прерогатива менеджмента.

Исполнение тестирования. Стадия 2: регрессивное тестирование

277

Теперь о третьей группе.

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

вую, ни во вторую группы. Но они тоже нуждаются в регрессив-

ном тестировании, так как изменение ПО может каким-то обра-

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

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

регрессивного тестирования каждого релиза в порядке очереди

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

существующие тест-комплекты были исполнены хотя бы один

раз в определенный период, например в полгода. При недостат-

ке времени для исполнения тест-комплектов из группы 3 ре-

комендую исполнять лишь самые приоритетные тест-кейсы

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

сивном тестировании данного релиза.

Например, если у нас есть 45 тест-комплектов и один релиз в месяц,

то, если исполнять по 15 тест-комплектов каждый релиз, за 3 месяца

можно исполнить их все.

Решение проблемы противоречия

Проблема противоречия между ограниченными ресурсами (напри-

мер, время на регрессивное тестирование) и постоянно растущим

количеством тест-комплектов решается следующими способами:

а. Приоритезация тест-комплектов и тест-кейсов.

б. Оптимизация тест-комплектов.

в. Наем новых тестировщиков.

г. Автоматизация регрессивного тестирования.

а. О пользе приоритезации мы уже говорили. Странно, но во мно

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

чтобы приоритезировать тест-комплекты и тест-кейсы и испол

нять лишь те из них, которые реально важны.

б. Оптимизация тест-комплектов. Многие старые тест-комплекты

могут быть оптимизированы в смысле

• уменьшения количества тест-кейсов и/или

• упрощения исполнения тест-кейсов.

Часто имеет смысл пересмотреть, КАК происходит тестирование

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

уже устарели и/или были написаны тулы для упрощения работы

некоторых из них и пр.

278

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

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

найму новых тестировщиков, что, конечно, лишь отодвинет реше

ние проблемы, но не решит ее, так как нельзя бесконечно нани

мать людей. Я против массированного найма (иногда нанимаются

десятки!!! тестировщиков в год) и считаю, что интернет-компании

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

группы профессиональных высокооплачиваемых специалистов,

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

подходами а, б и г.

г. Автоматизации регрессивного тестирования посвящено мно

жество монографий. Я же просто введу вас в курс дела.

Итак, в проекте www.testshop.rs скопилось, например, 78 тест-

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

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

ся. Так как у нас нет спеца по автоматизации тестирования, то

мы такого спеца нанимаем. Например, это будет г-н Говорков.

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

ляет г-на Говоркова в роли, примерно, мессии, который решит

все наши проблемы с регрессивным тестированием. Когда слово

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

следующему: «Ща я вам тут все заавтоматизирую!» Тратится

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

программы для автоматизации тестирования Silk Test (произво-

дитель – компания Segue), и автоматизация начинается.

Через неделю происходит первая демонстрация: запускается

автоматический скрипт и начинается магия:

подпрограмма силк-теста – агент открывает окно браузера,

вводит имя пользователя и пароль, нажимает на кнопку "Вход ",

совершает покупку и оплату и сравнивает фактический резуль-

тат с ожидаемым. Все в полном восторге, ведь очевидно, что

через пару месяцев все тест-комплекты будут автоматизиро-

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

мы просто запускаем в пятницу автоматический скрипт силк-

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

автоматизированного тест-кейса. Одним словом – лепота!

Однако когда во время регрессивного тестирования следующего ре-

лиза мы просим г-на Говоркова запустить автоматические скрип-

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

выясняется, что его автоскрипты не работают из-за того, что ин-

терфейс веб-сайта был в нескольких местах незначительно изменен.

Исполнение тестирования. Стадия 2: регрессивное тестирование

279

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

кнопки "Вход " на такой-то странице, и если агент, исполняющий

автоскрипт, не «видит» кнопки с именно таким названием, то

генерируется ошибка и исполнение тест-кейса прерывается.

Г-н Говорков, говорит "фигня вопрос ", тратит на починку скрип-

тов пару недель и в последний день регрессивного тестирования

его автоскрипты все-таки исполняют пару из 10 автоматизи-

рованных им тест-комплектов. В следующий релиз все повторя-

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

и взять на его место обыкновенного черноящичного тестиров-

щика – будет дешевле и эффективнее.

Я ничуть не утрирую. Подобные ситуации происходят в боль-

шинстве случаев после принятия компанией решения об автома-

тизации регрессивного тестирования.

Почему так происходит?

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

дании целой тестировочной инфраструктуры с библиотеками

кода, базами данных, системами отчетности и прочими вещами.

Создание такой инфраструктуры – дело очень и очень непростое.

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

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

совестно создает инфраструктуру для автоматизации, то он это дело

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

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

стоящим менеджментом: "За первый квартач 2005 года было авто-

матизировано 12 тест-комплектов, содержащих 174 тест-кейса".

Конечно, все эти автоскрипты не будут вскоре функционировать

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

вольно, и, значит, все "Хоккей".

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

на создание Инфраструктуры с большой буквы "Ай".

ПО – это живое существо. Оно постоянно меняется, и авто-

матизация, связанная с ПО, должна соответственно меняться

одновременно с ним. Таким образом, только поддержание (main-

tenance) существующих автоскриптов – задача, требующая боль-

ших профессиональных усилий, не говоря уже о написании но-

вых автоскриптов.

280

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

Я предлагаю очень простой подход к определению эффективно-

сти автоматизированного регрессивного тестирования. Посмот-

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

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

общие затраты на автоматизацию на количество багов – резуль-

татом будет стоимость нахождения одного бага. Сделайте то же

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

рования и сравните. В 90% случаев стоимость бага, найденного

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

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

а зачем вообще нужна ТАКАЯ автоматизация?..

Кстати,

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

больше багов, чем при исполнении автоматизации.

Советую также сравнить время, потраченное на автоматизацию

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

ние этого же тест-комплекта вручную. Гарантирую, что результаты

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

Таким образом, наиважнейшее значение приобретает профессио-

нализм специалиста по автоматизации.

Профессионализм такого спеца заключается не только в его про-

граммистских навыках, но и в том, как четко он представляет:

• ЧТО автоматизировать и

• КАК автоматизировать.

ЧТО:

Лучший кандидат для автоматизации – это тест-кейс для тести-

рования старой, устоявшейся фича. Автоматизируя его, мы, по

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

будет переписывать из-за изменения фича и соответственно из-

менения тест-кейса к ней.

Нет более бессмысленной идеи, чем автоматизировать регрес-

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

щены на машину для пользователей.

Один мой друг сравнивает фича с человеком: если это ребенок, то

он постоянно меняется; если же он взрослый, то изменений в нем

намного меньше и сами изменения менее радикальны – сравните

Исполнение тестирования. Стадия 2: регрессивное тестирование

281

того же ребенка, когда ему 6 и 12 лет; и теперь взрослого, когда

ему 42 и 48 лет. Идея, я думаю, понятна.

Чем меньше будет изменений в фича, тестирование которой ав-

томатизировано, тем меньше времени будет затрачено на под-

держку. Поддержка же порой превращается в кошмар

• с чередой красноглазых бессонных ночей перед монитором,

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

вильно, и

• со сладостным искушением все бросить и поехать с Лелей

в Ялту.

КАК:

Это создание инфраструктуры, позволяющей с легкостью и про-

стотой

• поддерживать существующие автоскрипты;

• создавать новые автоскрипты.

Инфраструктура автоматизации регрессивного тестирования должна

• с одной стороны, быть образцом программистского мас-

терства;

• с другой – воплощать наиболее эффективные подходы

к автоматизации, возможные при данном ПО для автома-

тизации (например, силк-тесте);

• с третьей – учитывать нюансы технологий именно этой

интернет-компании.

В заключение нашего краткого разговора об автоматизации рег-

рессивного тестирования я хочу открыть вам одну истину:

Суровая правда жизни заключается в том, что 100%-я авто-

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

езного веб-проекта – это миф.

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

убедиться, что это миф.

Если ваша компания решила заняться автоматизацией рег-

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

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

найдя его, дать ему дышать и не ожидать, что 100% тест-ком-

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

Это все о решении основной проблемы регрессивного тестирования.

282

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

Хорошая идея – это предусмотреть окончание регрессивного

тестирования за 2—3 дня до релиза:

• с одной стороны, у нас будет в запасе 2—3 дня, которые мы

можем использовать для завершения регрессивного тести-

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

была неверна.

• с другой – эти 2—3 дня можно потратить на тест-сдачи,

распределив между тестировщиками части ПО.

А дальше идет релиз...

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

1. Тест-смета необходима для приведения к одному знаменателю

потребностей компании и возможностей тестировщиков.

2. Каждый этап тестирования начинается/заканчивается при на-

ступлении условия начала/завершения.

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

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

4. Приоритезация тест-комплектов и тест-кейсов имеет наиважней-

шее значение, так как в условиях постоянного дефицита ресурсов

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

5. Из всех способов решения проблемы асинхронизации ресурсов и

объема регрессивного тестирования наем новых людей самый

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

6. Лучше хороший черноящичный тестировщик, чем один или боль-

ше плохих инженеров по автоматизации регрессивного тести-

рования.

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

1. Какие факторы стоит принять в расчет при создании тест-сметы?

2. Приведите пример условия начала и условия завершения для

исполнения тестирования.

3. Каково концептуальное отличие тест-плана от тест-кейса и тест-

комплекта?

4. На основании чего мы выбираем тест-комплекты первой группы?

Почему?

5. На основании чего мы выбираем тест-комплекты второй группы?

Почему?

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

или второй группы?

7. Какие последствия для компании влечет неграмотная автомати-

зация регрессивного тестирования?

ЧАСТЬ 4

• КАК УСТРОИТЬСЯ

НА ПЕРВУЮ РАБОТУ?

КАК УСТРОИТЬСЯ НА

ПЕРВУЮ РАБОТУ

• МЕНТАЛЬНЫЙ НАСТРОЙ

• ЭТАПЫ ПОИСКА ПЕРВОЙ РАБОТЫ ТЕСТИРОВЩИКОМ

СОСТАВЛЕНИЕ РЕЗЮМЕ

РАБОТА С АГЕНТСТВОМ ПО ТРУДОУСТРОЙСТВУ

КОМПАНИЯ ПО РЕКЛАМЕ СЕБЯ

ИНТЕРВЬЮ

• ИСТОРИЯ ОБ ОЛЕ И ДЖОРДЖЕ

очему устроиться на первую работу так сложно? Ответ прост —

Пинтернет-компании нужен человек, который в минимальное

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

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

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

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

Перед тем как описать стандартный букет, состоящий из писем рабо-

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

Ментальный настрой

Главным является ваше отношение к потенциальной первой

работе.

Итак, без прелюдий:

Вы должны искренне хотеть работать.

Вы должны быть готовы работать нелимитированные часы.

Вы должны быть готовы работать в выходные и праздники.

Вы должны быть готовы работать... бесплатно.

285

286

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

Если вы сможете принять эти советы как истину, то я на 90% га-

рантирую, что в течение 3 месяцев вы найдете себе первую работу

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

бы одна интернет-компания. 10% я оставил себе в качестве

аргумента для защиты от обвинений.

Отвлечемся от всего вышесказанного.

Допустим, вам нужен домашний работник, чтобы подметать,

готовить, стирать, гладить и выгуливать. Как бы вы отреаги-

ровали на предложение, чтобы все эти услуги предоставлялись

вам за ЛЮБУЮ сумму, которую вы сами назначите, работник

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

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

дня и ночи, работа была бы сделана добросовестно, и все это за

то, чтобы дать ему... небольшой кредит на ошибку, так как он

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

теории? Добавьте к этому, что вы сделаете доброе и

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

опыт работы, который сможет его кормить всю жизнь. Я

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

пекински.

Далее.

Представьте себе, что он проработан у вас какое-то время,

всему научился и стал конкурентоспособен на жестоком рынке

услуг. Если вы им бесконечно довольны, станете ли вы полноцен-

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

или же будете искать равноценного профессионала на стороне?

Я ничего не понимаю в домашнем хозяйстве, если кто-то смо-

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

На худой конец, даже если бы моя ситуация изменилась и

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

изумительно трудолюбивому и бескорыстному человеку лучшие

рекомендации.

Вы скажете, что так не бывает, чтобы кто-то на самом деле рабо-

тал на совесть и при этом не получал высокую заработную плату.

Могу вас заверить, что так же думают менеджеры, которые и на-

нимают нашего брата-тестировщика. Дело в том, что им, так же

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

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

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

287

И они, так же как и вы, откликнутся на то, чтобы помочь и вам, и

в первую очередь себе. Так возьмите и предложите им такой

вариант. Как это сделать, мы обсудим через минуту.

Этапы поиска первой работы

тестировщиком

Итак, теперь поговорим о поиске первой работы тестировщиком

поэтапно.

0. Настройте себя в соответствии с принципами, о которых мы

только что говорили. Люди, принимающие решения, почувствуют

ваш настрой, ваше желание и ваше отношение.

Основная задача данного этапа – настроиться на боевой лад.

1. Обзвоните своих знакомых и расскажите о своем желании

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

когда угодно и на любых условиях по оплате. Может быть,

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

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

Основная задача данного этапа – забросить удочку.

2. Займитесь составлением резюме. Резюме – это реклама. Ре

ципиентами этой рекламы являются рекрутеры и работодатели. В

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

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

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

заставить позвонить вам или прислать е-мейл с приглашением на

интервью. Если резюме не использует этот шанс, то в лучшем

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

лучших времен", а в худшем – в реальной или виртуальной кор

зине для мусора.

Резюме – это презентация ваших знаний и добродетелей. По-

нятие "презентация" играет здесь главную роль. Именно от эф-

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

ся вами или нет.

Искусство эффективной презентации заключается в том, чтобы

представить нужную информацию в максимально выгодном

для себя свете и максимально понятной для реципиента форме.

288

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

Итак, у вас есть совокупность вещей, некоторые из них можно и

нужно презентовать в резюме.

Например, это опыт работы, который, как мы уже говорили,

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

Задача в том, чтобы повернуть вещи под углом, ярко демонстри-

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

Например, Алла М. работает инженером полиграфического обо-

рудования.

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

стальных машин фирмы Н. для ее резюме на должность тести-

ровщика? Ответ: почему бы и нет, если мы это дело грамотно

преподнесем.

Пример грамотной презентации

"Составила план по тестированию установки и отладки верстальных

машин фирмы Н. Обнаружила критические заводские дефекты до на-

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

роной".

В общем думаю, что идея понятна. Учтите, что специальности

«тестировщик» не учат ни в одном университете мира. Про-

фессиональные тестировщики – это, как правило, профессионалы

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

Например

Прошлые специальности некоторых моих знакомых – блестящих тес-

тировщиков: архитектор, учитель, инженер, бухгалтер, биолог, метео-

ролог, юрист, программист.

Очень часто тестировщиками нанимают специалистов из той области,

в которой работает компания (например, компания, выпускающая ПО

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

тестировщика человека с дипломом врача).

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

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

писывайте каждую хорошую вещь, которую вы сделали.

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

зоваться неким тест-тулом, что вы и сделали. Знаете, как это называ-