Вернулся с трофеями:

1)

бита реального тестировщика:

• Длина биты – 54 см.
• Диаметр ~ 7см.
• Вес ~ 600г.
• Ценность ~ ващще офигеть!

2)

Чашка с логотипом «SQA Days» + Innova + мерки уровня Junior, Senior, Guru.

3)

Настольная штука-приз с номинированием «Главный тестировщик Молдовы».

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

Притащил в Киев, поставил на стол. Роата, мэй!

Рядом установил фляжку с десятилетним молдавским коньяком (это и есть мое оружие).

4)

Сделал традиционный шот с Ромой Твердохлебовым

Сравниваем с предыдущим:

5)

Схохмил маркером на стенде тестировщицких коммьюнити 🙂

6)

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

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

7)

Запас новых визиток не пополнился. Своих раздал много.

Напоминать всем: на конференции надо ходить с визитками.

8 )

Попал в кадры многих фотоаппаратов, просил мне их заслать.

Сидю и надеюсь, что пришлют.

9)

Ни фига не попал в очередь на рисование карикатур с натуры.

10)

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

11)

Самолет приволок меня в Москву позже необходимого, поэтому мой стендовый доклад был перенесен на неопределенное время (потом уточнилось — второй день, 17-40). Меня эта неопределенность не взволновала, но разволновало отвечать на вопрос «А когда вы там, это, а?«

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

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

Не знаю, ощущалось ли, но слайды я рисовал строго под звучание «Сектор Газа» 🙂

12)

Мегаполис Москва все так же ужасает.

Иногда в дороге между точкой отбытия и точкой прибытия не засыпал, а просто терял сознание — конференция прошла в состоянии сильного недосыпа, глаза у меня были дъявольские, с резями и слезами. Это я пытался не уснуть 🙂 Даже поездка в аэропорт на обратный рейс прошла в бессознательном состоянии.

13)

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

14)

Спасибо организаторам, спасибо участникам, спасибо официантам, спасибо, спасибо, спасибо за то, что SQA Days 11 пройдет в апреле в Киеве!

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

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

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

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

Кишинев — это маленькое государство аутсорсеров в 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 лет работал и буду так дальше работать, мне всего полгода до пенсии осталось…» Как вы таких пробивали?

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

А никак.

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

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

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

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

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

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

В действительности, как всегда…

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

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

Вообще, дилемма «или слушать доклады, или искать общения» передо мной не вставала. Она лежала, придавленная аргументом «разговаривать интереснее», поэтому «краткий отчет о прослушанных докладах» здесь неуместен. Не пересказывать мне краткое содержание или ощущение от докладов, на которые уже не сходить… Зато я смог узнать не только то, что входило в некоторые доклады, но и причины их появления, тот background, который почти всегда скрыт и не очевиден, и наиболее интересен.

Попадайте под наш маховик!

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

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

А вот в Кишиневе, и всех его клонах на территории СНГ, компании любого калибра, в первую очередь, вынуждены искать тех, кто уже УМЕЕТ работать.

Идея «а вот когда я наконец-то уеду в Канаду (Россию, Румынию, Кипр, Албанию)…» у нас всё ещё бытует на очень подспудном уровне, и бытовое окружение эту идею только подпитывает. Работать с настолько идейной молодежью сложно. Вон, французы из Pentalog даже проводили общественные слушания на тему «Да сделайте же вы что-нибудь, чтобы ваша молодежь не разбегалась, а то мы не знаем, как пережить сложности с наймом нужного количества людей под наши проекты…»

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

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

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

Вы на каком языке говорите?

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

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

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

Но поддержать мысль и развить…

Сергей Архипенков (справа) рассуждает «за тестировщиков»

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

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

С Ларсом Баком, разработчиком браузера Chrome, контакт наладился очень быстро — я спросил его только об аспектах тестирования в его работе. Кажется, он понял мой английский. Во-всяком случае, я понял ЕГО английский.

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

Асхат Уразбаев оказался почти высоким. Ну, почти как я. Но оба мы не так крупны и основательны и в поведении, и в речах, как Владислав Орликов.

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

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

Александр Орлов, таки да, действительно «лысый». И хотя пребывал он в очень усталом виде (увлекается многочасовыми перелетами и переездами из Лондонов по Финляндиям, Питерам и Москвам), все равно было заметна натура цельная и планомерная.

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

Хочется верить, что в докладах SQA Days 2010 все известные темы уже будут рассматриваться на уровне «максимум практичности и минимум толковательных теорий из разряда «как надо поставить процесс». Как надо — каждый знает. У нас с воплощением постоянные сложности.

У программистов постоянно есть о чем поговорить в очень утилитарном плане именно потому, что общие темы у них уже давно устаканены. На том же Хабре в епархии программистов постоянно появляются новые материалы из разряда «How To» применительно к определенным инструментам и сервисам.

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

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

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

По верхам

Еда — приличная. Не съезд дегустаторов имени Эскоффье.

Организация — знаю, из каких мелочей складываются подобные мероприятия, и понимаю, что иногда в погоне за чем-то важным некоторые мелочи остаются неохваченными. Но, все-таки, очень был удивлен, когда открыл диск с надписью «Разработка ПО 2009». Ожидал найти там все презентации конференции, а нашел только два крупных pdf-файла с перечнем докладов и их краткими анонсами — те же материалы, что и на сайте конференции, на русском и на английском языках. Свободного места на диске осталось очень много.

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

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

Организаторы!

Большое спасибо!!!

Послевкусие от участия

Чем-то конференции подобного рода сравнимы с Олимпиадами.

Вранье, что в Олимпиаде главное — участие. В спорте вообще не бывает второго и третьего почетного еста, есть только первое. Или ты на коне, или иди домой пешком.

Но участие в Олимпиаде действительно ценный опыт для любого портсмена. Можно быть чемпионом двора… но надо сравнивать себя с другими чемпионами. Поставить рекорд дома — это круто. Поставить рекорд на Олимпиаде — круто вдвойне.

Ценность Олимпиады в том, что все ее участники находятся в одинаковых условиях — одно поле, один ветер, один судья.

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

То есть, да, конференция в чем-то — соревнование.

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