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

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

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

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

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

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

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

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

В сознании произошел неожиданный сдвиг — мне уже сложно рассматривать конференцию как «там я узнаю что-нибудь новое о тестировании». Это уже место для тусовки.

Видишь, кто сейчас находится в профессиональной тусовке.

Налаживаются рабочие контакты.

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

Движение, там то, что «витает в воздухе», и в блогах явным образом не отображается.

Узнавание чего-то практического и нового все так же происходит, но уже местами, и больше в фоне.

Уже не столько «узнаешь новое», сколько сравниваешь услышанное с собственными знаниями или убеждениями.

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

Метаморфоза произошла незаметно, но сейчас я ощутил ее полностью.

Поэтому сейчас я не смогу сделать какое-либо описание того, что было, на манер отчета. На sqagroup.spb.ru собраны, наверное, все линки на отчеты о прошедшем, и по ним можно составить какое-то своё мнение, даже если это мнение сложится сквозь призму других мнений, и то, что «в воздухе витало», посредством отчетов сложно адекватно передать.

Я попробую рассказать о прошедшем отвлечённо. «Каждый пишет как он дышит» ©

День первый

Сообщили, что я выгляжу очень суровым. Наверное…

Я был очень уставшим после поездки, а также занервничал ввиду отсутствия вайфая в залах — айтишная конференция не может проходить без файвая, this is a must! Без вайфая рушится вся моя замысля с реалтаймной публикацией докладов, и вообще…

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

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

Петр Великий, Петр Великий!

Ты один виновней всех:

Для чего на север дикий

Понесло тебя на грех?

Восемь месяцев зима, вместо фиников — морошка.

Холод, слизь, дожди и тьма — так и тянет из окошка

Брякнуть вниз о мостовую одичалой головой…

Негодую, негодую… Что же дальше, боже мой?!

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

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

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

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

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

Так давайте пройдем в этот вечер прекрасный

Старым Невским моим, да по той стороне,

Что в обстреле была так темна и опасна.

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

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

А напротив гостей всех мастей полон Двор —

Вожделенная цель интуристовских сумок.

Но как предки мудры, и Казанский собор

от сует отлучен Государственной Думой.

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

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

По приказу царя так жестоко взнуздали.

Я хотел бы спросить этих сильных людей —

Вы свободу держать под уздцы не устали?

Обязательно! Всенепременно! Вперед!

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

Фигасе, вот и дом Зингера! Да, тот самый, йоу!

Вау!

Дальше, дальше! По поребрикам!

В наушниках бурлят Здоб ши Здуб. На чужой земле они особенно хорошо воспринимаются. А в сознании бурлит другое:

Повторяется шепот,

Повторяем следы.

Никого еще опыт

Не спасал от беды!

О, доколе, доколе,

И не здесь, а везде

Будут Клодтовы кони

Подчиняться узде?!

Вот и они, коняжки…

Было нескончаемое ощущение того, что я попал на цеховой бал по случаю очередной годовщины тезоименитства. К балу, как известно, долго готовятся. Я долго готовился. Я долго ехал. И вот — приехал.

И вот оно, нарядное, на праздник к нам пришло…

Совершенно не было скучно. Количество людей (over 300) внушало, и внушало качество разговоров, которые я слышал краями ушей. Да и если бы все молча молчали бы в тишине, я все равно получил то, за чем приехал из такого издалёка.

Я думал о том, что нужно сделать, чтобы это ощущение не прекращалось, и проявлялось бы в том же моем блоге, или на форуме s-t.ru; хотя на форуме — вряд ли; еще многое нужно продумать, чтобы форум не прогнулся под хиханьками постояльцев. Уже, однако, появляется «молодежь» с вопросами о вечном, и надо этому соответствовать.

С другой стороны, не хочется молодежь с простыми вопросами отсылать «читать литературу», но с одной стороны — как же не послать-то?

На аничковом мосту постоянное движение.

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

Двое стоят на мосту — один, похоже, местный, второй вроде меня, издалёкий. И объясняет местный неместному: «Вот, это тот самый мост шестнадцати яиц…«

Надо корректировать ожидания.

Я вовремя не смог, и вот, нарвался.

Местный придурок со своим неместным спутником уходят, я смотрю на «след от одного из снарядов, которыми обстреливали город во время блокады«. Очень холодно. Я понимаю, что жить в Санкт-Петербурге не захочу ни в коем случае — климат зверский, я от него уже страдаю. И мне совсем не хочется ходить по мостам с яйцами. Это ж надо такое придумать…

Дело в том, что я оказался прекрасно знаком с литературным Санкт-Петербургом (тот же эффект наблюдается при посещении Одессы). Одно время я фанател от поэтов Серебрянного века, и искал любую информацию об их окружении. Доискался. Я знаком с очень большим массивом текстов как сугубо литературных, так и газетных, а также мемуарных — от Чуковского и Маршака до всяких дневников придворных деятелей последних лет Российской империи.

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

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

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

С культурным наследием всё очень сложно.

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

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

По пути ощущение отторжения усиливается. Город контрастов. То кругом дворцы, дворцы, статуи с памятниками — плюнуть некуда. То вдруг старые дома — какие-то толстостенные трущобы.

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

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

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

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

И все так же, не проще,

Век наш пробует нас —

Можешь выйти на площадь,

Смеешь выйти на площадь,

В тот назначенный час?!

Где стоят по квадрату

В ожиданьи полки —

От Синода к Сенату,

Как четыре строки?!

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

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

Хозяйка коллекции работает в киноиндустрии, и фильмы подобраны очень грамотно. Нашел фильм Лени Рифеншталь «Триумф воли»… Надо же!

Включил.

Бляха-муха! Вот же какое кино! Как много можно выразить посредством чистого кино-языка! Как много отвлеченных вопросов возникает в процессе просмотра.

И немедленно отключился.

День второй

На выходе из метро афиша: «20-го числа в Ледовом дворце группа Ария!«

Ыыыыыы!

Нипопаду!

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

В голове, конечно, крутилось только неуместное «Васильевский остров прекрасен, как жаба в манжетах» — какой нафиг остров в этот момент, я там даже не был, я еще не полностью готов к докладу!

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

Время обеденное, в зале-галерее, заполненном странными скульптурками современного неолита, в котором мне выпало выступать, еще вообще никого нет. Вообще. «Сижу один, как тать в ночи, с одной мольбой неистовой — поговори, поклевещи, родной ты мой, транзисторный… Молчит товарищ Гольдберг, не слышно Би-би-си, и только песня Сольвейг гремит по всей Руси…«

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

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

Пришлось импровизировать.

«Вот моргает мне, гляжу, председатель:

Мол, скажи свое рабочее слово!

Выхожу я,

И не дробно, как дятел,

А неспешно говорю и сурово:

«Израильская,- говорю,— военщина

Известна всему свету!

Как мать, — говорю,— и как женщина

Требую их к ответу!

Который год я вдовая,

Все счастье — мимо,

Но я стоять готовая

За дело мира!

Как мать вам заявляю и как женщина!..«

Тут отвисла у меня, прямо, челюсть,

Ведь бывают же такие промашки! —

Этот сучий сын, пижон-порученец

Перепутал в суматохе бумажки!

И не знаю — продолжать или кончить,

В зале, вроде, ни смешочков, ни вою…

Первый тоже, вижу, рожи не корчит,

А кивает мне своей головою!

Ну, и дал я тут галопом — по фразам,

(Слава Богу, завсегда всё и то же!)

А как кончил —

Все захлопали разом,

Первый тоже — лично — сдвинул ладоши.»

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

Дело резво шло к финалу. Я подустал ходить, устал общаться, устал сидеть. Хотелось неподвижно лежать сто лет. Оккупировал походный стол software-testing.ru и медленно смотрел в монитор ноута.

День третий

В Кишинев возвращался на поезде.

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

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

Вопрос к видео-копирастам: не пробовали ездить в поездах?

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

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

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

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

Неужели мне снова придется отдавать мои пятки на растерзание шатающимся по вагону?

В общем, такой была конференция SQA Days 8 вот что я пережил и передумал на конференции SQA Days 8.

Хотя нет, не всё.

Снова день второй

Санкт-Петербург — это большой город, в котором не за кого выходить замуж, ведь кругом одни только геи, которые ширяются страшной смесью скуки и алкоголя…

Еще я познакомился с небольшим пёсиком по имени «Сид Вишес» (он умеет брать доминант-септаккорд в си бемоль голосом, жалкие вы людишки!), и пообщался с одной «питерской богемой».

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

— А где тут у вас Розенбаум живет?

— Ой, а Розенбаума у нас не любят.

— Фигасе! За что?

— А он в каких-то делах с недвижимостью замешан…

— Какое это имеет отношение к его песням?

— Не знаю, но замешан.

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

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

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

— Хорошо. А почему ты не звезда экрана?

Напомню, что покорение происходит уже десятый год.

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

— Ммм… А как же… То есть, все известные артисты с кем-то спали, чтобы стать известными?

— Конечно!

— Ммм… Алиса Фрейндлих?

— О, Алиса Бруновна! Можем ей в любой момент позвонить! У меня ее телефон есть.

— Да ладно! А ну, позвони! Я ей скажу, что я ее обожаю.

— Ээээ… Нет, уже поздно звонить. Завтра, может быть.

— Ладно. Итак, с кем ей пришлось…

— Ты не сравнивай то время с нашим временем. Тогда же все по-другому было.

Мда?

– Уй, мадам! – подтвердил Фагот, – натурально, вы не понимаете. Насчет же заседания вы в полном заблуждении. Выехав на упомянутое заседание, каковое, к слову говоря, и назначено-то вчера не было, Аркадий Аполлонович отпустил своего шофера у здания акустической комиссии на Чистых прудах (весь театр затих), а сам на автобусе поехал на Елоховскую улицу в гости к артистке разъездного районного театра Милице Андреевне Покобатько и провел у нее в гостях около четырех часов.

– Ой! – страдальчески воскликнул кто-то в полной тишине.

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

– Все понятно! – воскликнула она, – и я давно уже подозревала это. Теперь мне ясно, почему эта бездарность получила роль Луизы!

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

Подлый же Фагот, и он же Коровьев, прокричал:

– Вот, почтенные граждане, один из случаев разоблачения, которого так назойливо добивался Аркадий Аполлонович!

– Как смела ты, негодяйка, коснуться Аркадия Аполлоновича? – грозно спросила супруга Аркадия Аполлоновича, поднимаясь в ложе во весь свой гигантский рост.

Второй короткий прилив сатанинского смеха овладел молодой родственницей.

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

– Милиция! Взять ее! – таким страшным голосом прокричала супруга Семплеярова, что у многих похолодели сердца.

А тут еще кот выскочил к рампе и вдруг рявкнул на весь театр человеческим голосом:

– Сеанс окончен! Маэстро! Урежьте марш!

— Мда? Тогда… Лиза Боярская?

— У нее папа известный — он ее и протолкнул. Знаю я эту Лизку прекрасно…

— Мда? А вот Владимир Миронов — он что, с кем-то «спал»?…

— А Миронов у нас гей.

— В каком смысле?

— В прямом, видно же по лицу.

— Блин. А я не вижу. Он же артист! Я об искусстве говорил!

— Ну да! Он гей, и чтобы сниматься в фильмах на первых ролях…

— Погоди, погоди! А…

— И Киркоров гей. И Олег Меньшиков гей.

— Блин, что, все геи?

— А то!

Мне с глубинным ужасом подумалось о том, с кем пришлось спать Дмитрию Медведеву, чтобы получить роль президента Российской федерации…

— А Безруков? Тоже гей?

— А что Безруков? Он вообще бездарный. У него только внешность подходящая, чтобы Пушкина играть. Главное, вообще-то, попасть в Голливуд. Но в Голливуд не попасть — там все заняли евреи.

— Какие евреи?

— Обычные. Когда-то русские могли завоевать Голливуд, но Сталин приказал Эйзенштейну создавать кино в Одессе, поэтому время прошло.

— Ну слушай… Ну не могут же все быть геями. Вот, например, Машков?

— А что Машков?

— Ну, офигенный актер, дарование. Он что, тоже с кем-то спал?

— А что такого он сделал, чтобы быть офигенным актером?

— Он, кстати, в Голливуде снимался. Там, где евреи все оккупировали.

— Да? В каком фильме?

— В этом, как его… «В тылу врага»! Он там играл серба или боснийца, что ли, который хотел замочить Оуэна Уилсона…

— А, это тот самый фильм, который провалился во всех прокатах, да?

Вообще-то, бюджет 40 млн, сборы 91 млн длр США. Разве это провал?

В общем… «Богема» оказалась со сложной внутренней структурой, я так не могу.

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

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

Уж лучше бы пил.

(пилилим-пилилим)

И курил.

———————————————

В тексте органично использованы песни-стихи четырех Александров: Розенбаума, Галича, Васильева и Гликберга, в быту известного как «Саша Черный».

Всi ихние права на ихние стихи захищены.

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

Студент

Многие студенты, мечтающие работать IT разработчиками, но не имеющие достаточного опыта, могут попасть только в тестирование, т.е. туда, где входной порог существенно ниже. Большинство студентов, начинающих свою карьеру в тестировании, рассматривают тестирование как стартовую точку.

Случайность

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

Было интересно

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

Вас «попросили»

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

С чего начинается работа

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

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

Другой более эффективный, но в тоже время и более дорогой способ вовлечения новых сотрудников в проекты, — это проведение для них специализированных тренингов, на которых присутствует постоянный контакт между сотрудниками и тренерами. В рамках тренингов новые сотрудники знакомятся с продуктами, методиками и процессами. При таком подходе обучение сфокусировано на важных аспектах работы, а сам процесс обучения выглядит динамичным и интересным.

Однако, наличие подобных тренингов должно быть экономически оправданным, а эффективность тренингов возможна только в том случае, если в компании есть грамотные тренеры и отработанные тренинговые программы.

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

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

Эволюция тестера или почему тестеры не хотят быть тестерами

Надоело верифицировать баги

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

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

Надоело исполнять тест кейсы

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

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

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

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

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

Надоело писать тест кейсы

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

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

Не придумываю фичи

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

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

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

Тестеры, которые никогда не мечтали быть разработчками оседают имменно на этом этапе.

Хочу писать код

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

Разработка автотестов – это мощный мотиватор в решении данной проблемы. Как правило, это приводит к появлению конструкций вида:

public class TestClass1{

public static void main (String[] args){

//some code

}

}

Если автоматизация тестирования не выглядит как хаотичный процесс, где каждый тестер делает что хочет и как хочет, а наоборот, имеет четкую стратегию с применением лучших практик, таких как ревью кода, использование сторонних фреймфорков (например, для PHP это может быть Zend framework) и нестандарных решений в тестировании продукта, то автоматизация является серьезным аргументом в решении вопросов «хочу писать код».

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

Хочу писать другой код

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

Как с этим бороться?

Менеджер vs. эволюция

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

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

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

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

Как искать «правильных» тестеров

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

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

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

Основная цель тестирования – это поиск багов в продукте. Следовательно, каждый тестер должен фокусироваться на поиске различий и несоотвествий. В то время как разработчик должен ориентироваться на обобщение фактов при создании новых фичей. Таким образом, контролирующим вопросом при собеседовании кандидата будет: «Сравните, пожалуйста, объект А с объектом Б». А дальше внимательно слушайте ответы: чего в них больше — обобщений или различий.

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

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

Заключение

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

1. Нужно искать «правильных» тестеров — для того, чтобы обеспечить плавность в карьерном росте и эффектиность работы на разных этапах.

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

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

4. Всегда сохранять сотрудника в отделе или компании.

Источник описания: http://soleynikov.livejournal.com/20857.html

но по причине скудности эфирного времени не успел.

Вместо картинок слайдов использую заголовки.

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

Для прояснения антуража уточняю, что я — тестировщик из Кишинева.

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

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

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

У нас нет огромных компаний, как это бывает в Москве или Киеве, в которых можно прожить всю свою карьерную и биологическую жизнь.

Обычный кишиневский айтишник большую часть жизни:

1. мечтает стать программистом,
2. проводит время в маленьких компаниях,
3. поддерживает зарубежные долгосрочные проекты,
4. работает в окружении малочисленного коллектива, большую часть которого составляют вечно приходящие и уходящие «студенты».

Затем обычный кишиневский айтишник как следует учит Java, английский вперемешку с французским и навсегда уезжает в Канаду.

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

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

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

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

В общем, понятно, почему стать тестировщиков в Кишиневе весьма просто.

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

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

Главный вопрос: Кто ты? QC дрожащее, или QA?

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

Был такой случай: меня назначили начальником отдела тестирования.

Круто.

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

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

Работаем мы, спорим, доказываем, что-то решаем, но вот по итогам решения всё принимаются «не те»…

Позже, случайно во внутренней wiki я увидел список участников этой группы, и меня там не было. Я пошел спрашивать. Мне ответили, что «тебя изначально и не думали туда включать, ты же просто тестировщик… Иди, сиди, тестируй…»

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

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

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

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

Начинаются проблемы с уверенностью в результатах работы (действительно ли всё протестировано?).

В том числе и проблемы со временем — народ искренне не понимает, почему тестирование занимает так много времени.

В будущем пришедший тестировщик будет не работать, а «расхлебывать» то, что ему досталось.

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

Когда начинаете работать, думайте о тех, кто придут после вас, и делайте все красиво и чисто :).

Как обустраивать тестирование — никто не подскажет

Большая проблема тестировщика в маленькой компании — одиночество. Прекрасно, что не с кем меряться, но и не с кем советоваться.

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

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

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

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

Позже возникает необходимость в документации, а документировать то, что УЖЕ существует — то еще удовольствие…

Также если нет под рукой опытного работника, «студенты» организуются самостоятельно, по уму и разуму, как удобно.

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

Удобно ли ставить баг-трекер, если ты сам заведуешь всеми багами, и проект, в принципе, небольшой? Нет, неудобно. Да и что такое — баг-трекер?

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

К чему это приводит в итоге? Понятно, да…

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

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

Еще надо учесть то, что «принять ответственность» означает «стать командиром». Обустраивание тестирования в какой-то момент приведет к необходимости как-то подправить и процесс разработки. А там будут нужны и баг-трекер, и wiki, и svn, и воля на то, чтобы давить «бунт на корабле»…

Тестировщик должен медленно «подсадить» народ на свои инструменты, отчеты и документы

Грамотный тестировщик приходит в компанию со своими инструментами.

Баг-трекер, вики, svn – это основные.

Можно также приносить свои кресло и наушники — я так делаю.

Они могут уже быть, но нужно выяснить, пользуются ли ими.

У меня были случаи, когда я спрашивал, есть ли svn в компании, но забывал спросить, пользуются ли им кто-нибудь. Реальные случаи: есть svn, но пользуются им только менеджеры, и то — для сохранения своих ворд-файликов с названиями типа «требования к системе, ver. 152.0». Программисты про svn знают, но не используют. А нафига оно нужно?

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

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

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

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

К тому же, во многих кишиневских компаниях разработчики сидят под Убунту, а от Убунту до прочих благ опен-соурса — одно безалкогольное пиво под синтетической елочкой в обнимку с…

Шучу.

Убунту рулит.

Срок «подсаживания» – полгода. Это ориентировочный срок. Упоминаю его для того, чтобы еще раз подчеркнуть — подсаживание надо делать мягко. Резкий переход вызовет только отторжение.

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

Китайское предупреждение человечеству:

«Мягко ступающий продвинется далеко».

Человек-тестировщик, который намеревается менять существующий процесс, должен «далеко глядеть», «мягко подстилать», «нежно направлять» и всячески «выравнивать процессы» в нужную сторону.

По ночам ему будет сильно икаться. Будет проблема с пониманием: «Пришел невесть откуда, и чего-то хочет…»

По-молодости и неопытности я как-то начинал требовать от разработчиков и от менеджеров изменений в процессе разработки. У меня был большой и обоснованный список требований с доводами 🙂

И всё разбилось об один, но веский довод: «Мы так уже давно работаем, все идет хорошо, иди и не задалбывай».

Я ушел и понял, что они правы.

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

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

Да к тому же, не может толком объяснить, что и как надо делать:

— Ладно, будем писать юнит-тесты. А как это делать?

— А я знаю? Это же ваша зона ответственности.

— Ррррыыыы!

В компании, в которой я сейчас работаю, я начал делать изменения мягко. Я не стал говорить, что «мне не нравится то и это, плохо то и сё, никуда не годится так и эдак».

Я сказал, что всё отлично.

Только, сказал я, давайте-ка я поставлю сам себе на наш сервер шняжку, под названием ‘Mantis’ — я сам себе ее поставлю, сам себе ее настрою, вам это вообще ни к чему. Вики в компании есть, репозиторий кода есть, ну и отлично, а вот лично мне не хватает одной мелкой штучки.

Поставил и настроил.

И все баги записывал только в Mantis.

И когда приходило письмо с сообщение о баге (обычная была практика — сообщать о найденных дефектах письмами), я его заносил в Mantis.

И каждый раз, когда я сообщал кому-нибудь о баге, я давал ссылку на Mantis.

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

Мы его под свои нужды поднастроили — вообще улёт.

Разумеется, баг-трекер — только один аспект всей картинки.

Тестировщик не должен полностью «проседать» под быт программистов

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

Идти все-таки надо.

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

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

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

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

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

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

Требования, отчеты, описание изменений, планирование релизов и багфиксов — это круто, или это необходимо?

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

Но без основательной бюрократии процесс роста компании будет невозможен. Если не писать требования (хоть какие-нибудь), если не работать над их постоянным обновлением и отслеживанием изменений, то чуть позже, может быть, уже через год, появятся вопросы типа «Что это софт делает, и почему именно так? А кто написал этот идиотский код, гыгы? Стоп, неужели это мой код?»

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

Требований не будет

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

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

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

Как это сделать:

1. надо беседовать с программистами. Задачи приходят от менеджеров, но изменения, которые происходят в ходе переписывания абстрактных требований в рабочий код, лучше всего выяснять у программиста, который эти требования только что воплотил. Это пульс, это настоящий источник знаний.
2. любая информация, которая попадает к тестировщику, должна быть где-то и как-то записана. В любых формулировках и в любом виде. Секрет в том, что если ты напишешь требования в виде хотя бы одной строчки, то потом эту строчку можно будет дописать и доуточнять до размера большого документа. Если же пытаешься сразу написать большой документ, с разделами, титулами и колонтитулами, то вероятнее всего, получится какая-то фигня, с которой никто не захочет возиться.
3. всем обычным людям проще что-то уточнить и подправить, чем писать с нуля на голом экране. Поэтому, вместо того, чтобы требовать у программиста «Напиши для меня в вики список ситуаций, при срабатывании которых генерируется отправка емайла с уведомлением!», надо самому подумать и записать хотя бы пару таких мест, а затем подойти к программисту с вопросом «Я вот тут записал несколько ситуаций, при которых происходит отправка емайла юзеру, но не знаю, полный ли это список. Не затруднит ли тебя глянуть и сказать, все ли там учтено». Спорю на $100 (принимаю наличными), что «не затруднит», и список он дополнит. Ибо кому еще знать про обсуждаемую тему, как не программисту?
4. создать свой Disaster Recovery Plan.

«Disaster Recovery Plan»

Про эту штуку мне рассказал начальник группы системного администрирования компании Moldcell – frumich.

Обычно такой документ создают сисадмины.

Смысл ‘Disaster Recovery Plan’ в том, чтобы собрать (очень тщательно и детально), записать (еще тщательнее и детальнее) и сделать доступной для всех инструкцию действий в случае катастрофы.

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

На написание, тестирование и принятие такого документа у frumich’a ушел не один год. Но когда получилось! Собрал он в одну кучу и инструкции, и описания всех железок на предприятии, и фотографии всех мест, где эти железки находятся, и ежедневную автоматическую проверку наличия определенного железа на рабочих местах наладил — полный план, хоть ложись и умирай, народ подхватит твое знамя и резво двинется дальше 🙂

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

Надо написать собственный ‘Disaster Recovery Plan’. Или его точное подобие.

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

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

После того, как я стал воспринимать каждый тест-план и каждый тест-кейс как часть большого ‘Disaster Recovery’ плана, мне стало очень ясно и понятно, куда какой кирпичик информации надо положить, и главное — зачем его надо туда класть.

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

Основная проблема при создании документации — найти грань между действительно нужной информацией и «всем прочим». Изначально ведь кажется, что нужно сохранить абсолютно всё, но это не так.

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

А если это нужно кому-нибудь еще больше одного раза — непременно надо записывать.

Сила любой системы — в накоплении и структурировании информации и запасов

В Полинезии живут папуасы.

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

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

Получается, что сила — в самостоятельности и личностных умениях выживать?

Вроде бы, да.

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

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

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

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

Основная проблема внедрения всех этих средств накопления информации кроется в основном отличии маленькой компании от большой — формализация взаимодействий.

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

Например:

• проблемы с отчетностью о работе.
• проблемы с фиксацией и передачей знаний.
• проблемы с разделением задач и зон ответственности.

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

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

Но если право есть, то «ставить на рельсы» довольно просто — последовательно хвалишь одно поведение и не хвалишь другое. Народ гибкий — подтянется под начальника…

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

Знать путь и пройти его — это две большие разницы

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

Всю работу по проекту надо воспринимать сквозь призму дальних целей роста компании.

Просто представь себе, что вы в будущем именно ты будешь главой отдела тестирования с филиалами в Киеве, Лондоне и на Лиговке — вот и готовь себе почву.

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

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

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

Тестировщик может и должен взять на себя всю работу по подготовке документации — как аналитик.

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

Даже более того, тестировщик может стать источником информации для всех участников проекта. Если именно он будет ее постоянно собирать и структурировать, то все привыкнут к тому, что «она сама по себе появляется в вики, вот сегодня к семи часам появится описание того, о чем мы вчера говорили…» Это идеал.

Роль аналитика в маленькой компании, как правило, не занята никем. Бери и пользуйся.

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

Нередко тестировщиков СПРАВЕДЛИВО воспринимают как «трату денег»

Причем трату, которая «нужно в принципе», то есть, непонятно зачем. Так, мол, полагается.

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

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

Когда это выражение относится непосредственно к тебе — становится несмешно.

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

Сам не сможешь — кооперируйся с мелким менеджментом, а затем с высшим.

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

Теперь важный вопрос: как осуществить все вышесказанное? Как копить информационные ценности?

Ничего не забывать, всё записывать

Без пощады к себе.

Без «это само собой подразумевается, и все об этом знают».

Без «это слишком долго расписывать».

Одна строчка документации потянет за собой всё остальное…

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

Я для себя решил эту проблему посредством сбора всего в одном текстовом файле в EditPlus, когда работаю в Windows — в этой софтинке можно сдвигать абзацы разных уровней вложенности. Быстрое «свертывание» помогает ориентироваться по разделам, почти как в вики. При работе в Ubuntu адекватного аналога свертывания разных уровней я не нашел, поэтому пользуюсь обычным GEdit.

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

Задачи, которые следует выполнить позже, я сохраняю в rememberthemilk.com

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

А RTM позволяет выносить список задач на экран GMail и GCalendar, и я постоянно вижу задачи. Также к ним можно обращаться с мобильного телефона, что опять же, важно для «записал и забыл», в любом месте и в любом окружении.

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

Еще раз повторю — надо пользоваться «своими» инструментами, что в офисе, что вне офиса. Свой календарь, своя почта, свое кресло, свои часы…

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

Да и — я еще не знаю, как однозначно решить эту проблему.

Спасибо.

.

Обсуждение доклада

.

Александр Александров, эксперт учебного центра Luxoft по управлению качеством ПО, управлению тестированием, анализу и совершенствованию инженерных процессов.

Несколько комментариев.

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

То, что вы сделали, существенно больше той области, которую вы обозначили.

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

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

Вот наш с Мишей (Михаил Павлов) опыт: когда мы пришли в компанию Auriga в начале 2006 года — нас встретили очень жестко. Ногами не били, но все остальное было. Через какое-то время начали уважать, но огрызаться: «Вам надо, вы и делайте». Эти слова нам говорили до августа 2007 года, когда компания получила сертификат CMMI 4-го уровня.

В начале 2008 года, когда я из компании уже ушел, должны были приехать крупные заказчики, которые интересовались процессами. Миша там еще работал, он пригласил меня, и я с большим удовольствием автору слов «Вам надо, вы и делайте» эти слова вернул при достаточно большом сборище. Жесткость, а иногда бескомпромиссность — это качество, которое вытекает из первого вашего тезиса, и противоречит третьему и четвертому тезисам, — я призываю всех присутствующих им пользоваться умело, и не сомневаться в том, что если нужно совершить какое-то воздействие — то нужно это воздействие совершить.

(аплодисменты)

Да мне аплодировать не надо…

Алексей Лупан:

Да, спасибо.

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

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

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

Юля Нечаева, мама и омега тестирования в компании Innova Systems (Москва)

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

Мне очень нравится подход к тому, что надо смотреть на свою работу как владелец компании. Это круто и помогает. Но как быть в тестировании с тем, что бюджеты решаем не мы, сроки решаем не мы, и мы не выбираем область работы. Есть жесткие ограничения, которые мы не решаем.

Как ты это противоречие решил для себя?

Алексей Лупан:

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

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

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

Александр Александров:

Это надо сделать во-первых, а во-вторых, после того, как все закончилось, надо придти к начальнику еще раз и сказать любимую фразу капитана Зеленого из мультфильма «Тайна третьей планеты»: «Я так и знал!»

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

Юля Нечаева:

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

Алексей Лупан:

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

Вопрос (Симферополь):

Маленькая компания — это по-вашему сколько?

Алексей Лупан:

До 30-ти человек. Но дело не в объемах, а в менталитете и психологии.

Вопрос:

Хотелось пару слов сказать о роли тестировщиков.

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

Алексей Лупан:

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

Эвелина Тананаева (Минск):

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

Алексей Лупан:

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

Вопрос:

Практический вопрос: при изменении процесса все равно находится какой-нибудь непробивной человек, который упрётся и скажет, что «я 20 лет работал и буду так дальше работать, мне всего полгода до пенсии осталось…» Как вы таких пробивали?

Алексей Лупан:

А никак.

Я таких не пробивал, мы их мягко обходили, и все было хорошо.

Человек, который действительно знает что-либо, потенциально полезен, и не должен слышать «Мы будем делать иначе, ибо вы не знаете или просто не хотите».

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

Пошли в лесок и сели в тень.

Степаныч сунул в рот былинку,

Надвинул шляпу набекрень

И затянул свою волынку:

«Интеллигентный блудный сын,

К сосцам земли припал я снова…

Как жук, взобравшийся на тын,

Душа в лазурь лететь готова!

Старик Руссо вполне был прав:

Рок горожан ужасно тяжек…

Как славно средь коров и трав

Дня три прошляться без подтяжек!

Поесть, поспать, пойти в поля,

Присесть с пастушкой возле ели…

Земля! Да здравствует земля!..

Какого черта, в самом деле!..»

«Какой, вздохнул я, там Руссо!

Здесь — хутор, в городе — клиенты.

Лицо, как круглое серсо…

Бывают, брат, милей моменты:

Пиджак редеет, как вуаль,

В желудке — совестно поведать…»

Племянник, пасть уставив вдаль,

Орет нам издали: «О-бе-дать!»

Опять едим! О, суп с лапшой,

Весь в жирных глазках, желтый, пылкий.

На стул трехногий сев пашой,

Степаныч ест, как молотилка…

«Что слышно в городе?» — «Угу».

Напрасно тетушка спросила:

Кто примостился к пирогу,

Тот лаконичен, как могила…

Внезапно

Почему последнее время мы только и слышим «аутсорсинг»?

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

Как бы не так! Кто из Вас не приглашал водопроводчика из ЖЭКа для устранения засора? И как? Хорошо, хоть балкон не уронили!

Почему-то мы думаем, что пригласив специально обученного человела, мы решим поставленную задачу.

И еще. Кто, обычно, рассуждает, с важным видим закатив глаза, о пользе аутсорсинга? Правильно. Те, кого мы, заказчики, называем аутсорсерами.

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

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

Итак, ЗАЧЕМ НАМ НУЖЕН АУТСОРСИНГ ?

Вот не полный список:

1. Переложить ответственность на другого (
2. Нужно сделать что-то, что мы сами не можем и/или не понимаем (водопроводчик (). Не свойственная нашему бизнесу работа.
3. Нет своих ресурсов
4. Есть лень и есть деньги
5. Мода
6. Есть работа, но не постоянная
7. Есть проблемы в собственном бизнесе. Например, ОК не может найти сотрудников, а работу надо начинать вчера.
8. Политические игры
9. Надо своровать
10. Надо прекратить воровство
11. И еще 100 пунктов…

Обсуждать варианты воровства, моды и др. опций, не относящихся к ИТ, я не буду.

Когда аутсорсинг точно не поможет?

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

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

Еще раз! За работу по вверенному направлению отвечает руководитель. И это правильно.

Принятие решения о начале подбора подрядчика

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

У нас нет своих ресурсов и нет руководителя.

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

Всегда должен быть ответственный руководитель. Да, он может быть аутсорсером.

Но, еще раз:

1. Обязательно должна быть вертикаль принятия решений.
2. Должны быть оговорены правила. Как то:
3. Выделение / сокращение бюджета
4. Выделение / сокращение ресурсов (люди)
5. Контрактная сторона вопроса. Т.е. каким образом мы взаимодействуем с подрядчиком. Подробнее об этом ниже.
6. Сроки
7. Планы
8. Отчетность
9. Закупки
10. Тендерные аспекты

Построение отношений

Контрактные

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

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

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

Заказчики, в данном случае тестировщики. Надо предусмотретъ:

1. Порядок работ, т.е. кто кому, что и когда передает. Время реакции той и другой стороны. Что делаем в случае несоответствий, как исправляем ПРОЦЕСС.
2. Как осуществляем приемку, по каким критериям, сколько ошибок допускается, что делаем, если ошибок слишком много. Собственно, что такое ошибка? Как их классифицировать (ошибки)
3. Штрафные санкции и как их проводить.
4. Официальная переписка

Не контрактные

Это построение нормального коллектива единомышленников. М.б. команды, если таковая нужна. Понятно, что команда нужна не всегда. Отсутствие понимания и нормальной рабочей обстановки способно завалить любое начинание. Тут могут помочь тимбилдинги, другие СОВМЕСТНЫЕ активности. Если речь идет о проекте, к тому же срочном проекте, проектную команду надо посадить или в одну комнату, или в помещения в шаговой доступности. Мы, во многом, страна устных договоренностей. Этим ни в коем случае нельзя пренебрегать.

Когда выгоден аутсорсинг?

А давайте просто считать затраты? Не следовать моде, а следовать здравому смыслу.

Сколько стОит собственный отдел тестирования (мы договорились, что рассматриваем аутсорсинговый контракт на примере тестирования)?

ЦЕНА1 (стоимость сотрудника) + ЦЕНА2 + ЦЕНАn + НАКЛАДНЫЕ РАСХОДЫ

А сколько стоит сотрудник?

З/п сотрудника * 1.9 + премии * 1,9 + обучение + соцпакет

Итого получаем, при з/п 60 000 руб. Gross отдел из 5 чел. будет стоить примерно 1 100 000 руб. / мес

А сколько стоит сотрудник — аутсорсер? Вам виднее. С учетом цен на такие услуги, инсорс и аутсорс, при прочих равных, по цене примерно одинаковы. Следовательно, выбирая между инсорсом и аутсорсом, надо руководствоваться не денежными соображениями.

А именно:

Профессионализм.

А он требует подтверждения. Это не просто бумажки, а вполне себе конкретная работа. Частично это можно проверить в рамках пробного периода. Или надо очень пристально проверить. ИТ-ишникам тут немного проще, ИТ мир очень тесен. Можно поинтересоваться у друзей / коллег. Правда, это будет только ИТ взгляд на конкретного подрядчика. Но это лучше, чем ничего.

Демпинговая цена

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

Заманчивые обещания

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

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

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

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

Оплата

Оплата услуг м.б. только постфактум, т.к. после выполнения сторонами обязательств по контракту. Иначе потом будет проблематично договариваться о штрафных санкциях (если понадобится) и др. выплатах.

Штрафные санкции

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

Резюме

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

1. Знаете ли вы, когда и как начинать отношения с внешним поставщиком
2. Вы знаете, как и когда заканчивать эти отношения
3. У вас есть структура принятий решений (вертикаль власти)
4. У вас есть положительный опыт общения с компанией подрядчиком
5. Собственно, наличие у компании подтвержденного опыта по теме

Чего делать не стОит!

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

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

Оснастился «розой» — фанатским шарфом «Зенита». Могу теперь орать на стадионе  «Зимбру сосеште, Зенитул рулеште!«

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

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

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

Что такое качество

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

Тестировщик не отвечает за качество программного продукта

Дочь попросила меня проверить ее домашнюю работу по алгебре. Проверив работу, я обнаружил несколько ошибок, причем достаточно определенно указал, где и почему они допущены. Дочь забрала свою работу, а на следующий день сообщила: «Папа, я из-за тебя получила тройку». Оказалось, что накануне дочь поленилась и не исправила ошибки, на которые я ей вчера вечером указал. А сегодня она попыталась переложить ответственность на человека, указавшего на ошибки, за то, что она их не исправила.

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

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

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

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

За что отвечает тестировщик

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

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

•       Какова качественная и количественная оценка текущего состояния продукта с точки зрения его соответствия требованиям?

•       Сможет ли проектная команда поставить продукт в срок и в надлежащем качестве, если сохранятся существующие тенденции обнаружения и исправления дефектов?

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

Хороший тестировщик в любой момент может дать заинтересованным лицам проекта ответ, по крайней мере, на первые два вопроса.

Причины заблуждений

Причина первая – сложившаяся практика смешивать понятия тестирования программного обеспечения (software testing) и обеспечения его качества (quality assurance). Такое наблюдается сплошь и рядом не только в России, более того, вся эта путаница пришла к нам из-за рубежа вместе с термином quality assurance («обеспечение качества»).

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

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

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

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

Кроме того, как отмечает в заметке с говорящим названием “Testers: Get Out of the Quality Assurance Business” — в своем блоге [1] Майкл Болтон (Michael Bolton), тестировщики не занимаются программированием и не могут вносить в код изменений, непосредственно улучшая качество программного кода. Комментируя деятельность тестировщиков, М.Болтон пишет, что это не обеспечение качества (quality assurance), а содействие качеству (quality assistance).

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

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

Вместо заключения

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

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

Тезисы доклада

«Тестировщики — валите из Quality assurance business».

Что такое качество? Не соответствие ожиданиями пользователя 🙂 «Я ожидаю, что Windows sucks — и она sucks!»

Мы не можем гарантировать качество, это даже не наша работа. Мы можем тестировать.

Код не товар — это инструмент для решения задач закащщика.

Качество — это больше, чем отсутствие ошибок.

Тестирование — не просто написание тест-кейсов.

Тестирование ПО — это исследование систем, созданных людьми, ПО и всех прилагающихся продуктов и услуг.

Тестирование — это исследование кода, системы, работы людей и взаимосвязей между всем этим добром.

Тестирование — больше чем Checking. Ибо это просто процесс сверки «работает — не работает», а это можно проверять шайтан-машиной, этот процесс не «sapient».

Тестировать надо не только для достижения повторяемого результата, но и для adaptability, value, and threats to value — все то, что компьютер не могут. Такое тестирование фиг заскриптуешь.

Хороший тестировщик не спрашивает «Pass or fail?» Хороший тестировщик спрашивает «Тут есть какая-либо проблема?»

Одно из ошибочных мнений про agile — что это помогает делать софт быстрее. В действительности, это помогает быстрее делать ХОРОШИЙ софт 🙂

Шайтан-машина не может тестировать вместо двуногого шайтан-айтишника — она может только помочь.

Тестировщики — это skilled investigators. Мы измерительные приборы типа градусники, телескопы, бокалы с вином.

Черт побери, я понимаю Болтона без переводчика!

Тестирование — как работа следователей, которые раскрывают преступления (без откатов).

Рассматривать тестирование как услугу — к решению многих проблем.

Если тебе сначала нужна документация — это не тестирование, это checking. Тестирование решает проблемы в ПО.

Проблема не в том, что тестирование — бутылочное горлышко. Проблема в том, что никто не знает, что находится в этой бутылке.

Тестировщики — исследователи, как журналисты, историки, антропологи, ботаники, философы.

We must build knowledge and skills.

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

Повторяемость и надежность тестирования как обеспечивается? Хз. Журналистика — повторяемый процесс?

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

Это творческий процесс, настолько, насколько творчество доступно в области технологий. Следите за работой пилотов и врачей — наиболее близкие нам по духу профессии.

Видео этого выступления — http://vimeo.com/19518317

Дополнительная информация на сайте Болтона.

1. AgileTestingDays-TestersOutOfTheQABusiness.pdf
2. TwoFuturesOfSoftwareTesting.pdf