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

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

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

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

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

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

А никак.

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

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

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

Я начинающий тестировщик. Сейчас устраиваюсь на работу. В ответ на резюме, отправленное в одну из компаний, мне пришло предложение выполнить тестовое задание, которое заключается в том, чтобы найти как можно больше issues на бета-версии сайта. В ответ от меня ожидается issue document. Погуглив, я обнаружил несколько template’ов issue document, однако мне не совсем понятно, что с ними делать (а точнее, практически, совсем не понятно) 🙂

Пожалуйста, подскажите, как лучше составить этот самый issue document(я имею в виду в основном оформление, есть ли какие-то стандарты?), чтобы произвести хорошее впечатление на HR отдел компании. Да, чуть не забыл. На все про все у меня всего пару дней. Очень прошу, не медлите с ответами.

Ну, прям, не медлить…

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

Налейте мне еще коньяку «Chisinau», бо я сегодня разочаровался в Johnny Walker Red Label, и мне нужна реабилитация.

Если нет «Chisinau» — достаньте его где угодно, не грузите меня подобными мелочами.

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

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

Уважаемый сэр молодой тестировщик,

ежели вы так хотите произвести впечатление на HR (она после этого потребует взять ее замуж, вы к этому готовы?), тогда вам следует знать, что слово «Issue» на языке Вильяма сукина сына Шекспира означает «вопрос, который надо обсудить«. Односложно на русский язык это слово перевести сложно, поэтому большинство произносит его как «ишшу».

Например, в рулезнейшем баг-трекере Mantis каждая запись называется issue. Баг там записан, или задача, или вопрос — это все issues.

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

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

Шаблон такой:

1. Сделать это.

2. Сделать то.

3. Сделать то-то.

[…] сделать то-то и это-то.

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ

Такой-то.

ПРОБЛЕМА

Происходит то-то и сё-то.

Скриншот прилагается.

Запомните как гамму до минор на контрабасе: баг без скриншота — что фильм «Кавказская пленница» без спортсменки, комсомолки, и как ее там звали (уже забыл).

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

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

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

Если вы нашли баг в предыдущей фразе — позвоните нам по телефону 555 28 16 88, спросите Джонни из ФБР.

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

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

2)

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

Понимаете, мне кажется, что «домашнее задание» должно показать, как вы ВООБЩЕ умеете думать в области «поиска багов», а не требовать список багов.

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

* Да, я знаю, что в русском языке нет слова «ихней».

Зато есть химический элемент «ихний» — его скоро должны открыть, это принесет в казну много элементов типа argentum.

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

А если и скажут, что подходите, то работа у вас будет такая же унылая, как подъезд дома номер 5 по улице Кантемир в городе Костюжены, ибо оценивать ваши качества будут по количеству находимых вами багов. Это я вам, почему-то, гарантирую.

А почему?

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

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

Просто В ОБЩЕМ самым заметным результатом работы тестировщика является сборник багов, поэтому нормально, если окружающие так считают.

Пусть считают, делов-то.

Хуже, когда дело доходит до «Я тут нашел баг, а ведь это твоя работа, баги находить…«

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

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

Конечно, певца при приеме на работу попросят спеть, кулинара — приготовить, путану — мгм, дизайнера — нарисовать, программиста — написать код. Если всё это правильно, тогда и тестировщика надо попросить при приеме на работу найти баги 🙂 Логика просто нерушимая, как СССР, который, как вы помните, разрушился ко всем чертям.

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

Вам же предложили не решить пример, а сделать работу. «Найти как можно больше issues на бета-версии сайта» — я это воспринимаю именно так.

Если у вас есть возможность еще поискать работу — поискайте её ещё.

3)

Искренне рекомендую следующее:

1. Все-таки протестировать предложенное приложение и постараться найти там как можно больше багов. Просто для самоуважения. Список этот можете себе на стену повесить — он ваша интеллектуальнейшея собственность.
2. Забить на мечту о работе в той крутейшей компании.
3. Продолжать искать работу.
4. Найти работу, на которой работают правильные люди.

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

1. Вот приложение. Вот в нем есть такая-то функциональность.
2. Вот какие к этой функциональности предъявляются требования (вам кладут на стол список требований, или, может быть, краткое описание задач, которые выполняет этот функционал).
3. Пожалуйста, расскажи, как ты это дело будешь тестировать. Какие есть идеи, на какие аспекты ты обратишь внимание в первую очередь, а на какие забьешь болт, с чего начнешь и когда намереваешься завершить тестирование, где и как будешь искать информацию о тестируемой теме, и где ты возьмешь болт, чтобы им забить, если надо будет забить, как уже говорилось…
4. Не нервничай и не сучи ножками — тут все когда-то сидели точно так же, как и ты, и думали, думали, думали. Ты тоже думай.

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

Вдруг это ваша судьба?

Вот что я сказал бы, но проблема в том, что меня об этом не спрашивают.

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

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

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

Перед прочтением надо запастить мартини (я взял коньяк, тирасполь, восемь лет, подогнали на мой прошедший «ДР!») и наушниками.

Много букв. Текст из разряда «неспешных», быстро прочитать его вряд ли получится.

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

Рассказываю

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

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

1. иной программист может обоснованно получать ЗП больше, чем его непосредственный менеджер проекта;
2. иной тестировщик может обоснованно получать больше программиста, который получает больше чем ПМ;
3. иной менеджер тестировщиков может вообще перестать тестировать, бо от него это и не требуется;
4. стать менеджером может не каждый технарь, даже самый старательный и умный;
5. стремление стать начальником ничего не гарантирует.

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

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

Не стихийно, конечно, но очень резво.

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

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

Да, есть вики.

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

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

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

А еще сложнее было оценить масштабы тестирования. Практически те же траблы, что и тестировщика игр:

1. Проекту много лет.
2. В проекте уже много-много функционала, и большинство работающих над ним фокусируются только на его отдельных аспектах.
3. Тест дизайн или что-то подобное никогда не делалось, бо нафига оно надо? (ничуть не иронизирую).
4. Документация в вики есть, конечно… но…
5. Отсутствие тестового покрытия, а значит и невозможность сказать что «такая-то функциональность» работает на 100% от предполагаемого.
6. Бешенные сложности с регрессионным тестированием.

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

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

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

Теперь у нас даже задачи раздаются и отслеживаются через Mantis 🙂

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

Я всё ещё помню, как мне работалось в Глобале.

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

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

Менеджеры уже всё продумали. Всё обеспечили. Приняли наилучшие стратегические и тактические решения, коим надо было следовать. А я солдат рядовой с небольшой головой, мне-то что…

«В двадцати шагах чужие каски с той же целью — защитить мозги«.

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

Скорее, если у тебя есть задатки и способности менеджера, тебя, вероятно, ВЫДЕРНУТ из общей толпы и посадят на определенный электростульчик ответственности, нежели тебя БУДУТ УЧИТЬ тому, что должен знать и уметь настоящий менеджер.

Это не означает, что надо только расслабиться и наблюдать за своей судьбой, мол, сама, родимая, пойдет. Активное движение должно происходить, в первую очередь, изнутри.

Без внутреннего «Лёха, двигай попой!» ожидать своего выдергивания наверх можно долго, тупо и глупо.

А вот в маленькой компании это перетекание вполне естественно. Народу всегда мало. Кто-то же должен быть начальником? Вот и становись…

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

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

И поле зрения менеджеру нужно иное, нежели рядовому, а невозможность поле зрения поменять — тоже чревато.

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

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

Но двигаться надо всегда самостоятельно.

Мне жаль того, что пришлось покинуть Украину в очень сложный для меня момент — я очень хотел понять, являюсь ли я кандидатом на ВЫДЕРГИВАНИЕ. Важный вопрос, не так ли?

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

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

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

После возвращения в Кишинев я снова стал управленцем тестирования (делов-то!), но тут тестировщик-управленец также и тестировщик-технарь, бо больше кликать некому.

Прошел год, а меня всё ещё свербит желание разгадать загадки «больших» тест-менеджеров, за повадками которых я наблюдал в Киеве в вольере ГлобалЛоджика.

А кого тут спросить?

Поэтому, когда я случайно* узнал про «Школу тест-менеджеров«, я всячески стал сучить ножками в поисках возможностей попадоса на этот тренинг.

* Ну, как случайно…

Это такая случайность, на которую натыкаешься только потому, что ищешь, хотя и сам точно не знаешь, что именно ищешь.

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

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

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

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

Цена за московский тренинги для молдаванского тестировщика очень суровая — почти $800 за живое выступление (отпадает сразу), и «всего» $350 за он-лайн версию.

Мне ныло и свербило попасть хотя бы на он-лайн версию, но, ёпрст, даже такая цена по нашим меркам всё равно неудобная, жабодавительная и сложно подъемная.

Варианты вроде «пусть заплатит компания» в наших шпинатах не уместны. Мне надо — я и плачу.

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

И бодро пошёл на тренинг.

Внимание интересующимся тестированием компатриотам.

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

Обращайтесь.

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

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

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

Чёрт с ним, с этим свидетельством, согласен.

Я положил его под оргстекло на своем столе, рядом с сертификатом об участии в прошедшем SQA Days и дипломом о занятии второго места в международном турнире по игре в «Морской бой» в каком-то заштатном кишиневском ресторане.

На тренинге я очень хотел узнать то, чего не знал. В итоге научился тому, чего не умел, хотя почти знал.

Разница понятна?

Неужели?!

Вообще, тренинг этот ударил по моему самолюбию, как Катерина Зеленко по немецкому Мессершмитту.

Мне казалось, что я кое-чего ЗНАЮ.

И умею.

А оказалось — только знаю, а уметь еще надо научиться. И кое-чего попутно узнал и прояснил (собственно, ради этого и рвался на тренинг).

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

Это уравновесило мою психику, и я, собственно, от раздумий тупо перешел к делу, и таки написал свой грамотный тест-план — за 15 дней. Уже хорошо. Раньше в подобное не верил.

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

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

Минусом я посчитал только собственную тормозливость — я не успевал вовремя делать домашние задания, и некоторые до сих пор лежат в каталоге «___СуперСрочноВсёСделатьДоЗавтра!!!!!!!».

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

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

И таки сработало.

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

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

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

Тестирование ничуть не хуже управления танками — надо пробовать сделать, а не останавливаться на уровне «Конечно, читал я ваших Блэков и Канеров, да… Я профессионал, да…»

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

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

Да, я занимаюсь управлением тестирования.

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

Но сейчас, после тренинга, я чувствую себя тестировщиком-технарём, а не манагером.

Наверное, это нормально, и просто моя психика таким образом защищается от само-изнасилования, но всё-таки…

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

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

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

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

Выводы вынести легко.

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

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

Драконам задницы надо всегда надирать, а не подтирать.

** намек на сказку Евгения Шварца.

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

Между прочим

Вот нечто, над чем можно зависнуть на пару добрых часов рассуждений — видео с открытой лекции Алексея Баранцева “Почему тестирование занимает так много времени?”

Звук у видео глуховатый, поэтому берем наушники.

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

Хотя там есть даже язык «волапюк»…

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

Залогинившись под административным аккаунтом, переходим на страницу «manage > Manage Configuration > Workflow Transitions«

По-русски: «управление > Управление конфигурацией > Переходы состояний процесса«.

По-простому: http://вашMantis/manage_config_workflow_page.php

По-умолчанию в Mantis присутствуют следующие статусы:

• new
• feedback
• acknowledged
• confirmed
• assigned
• resolved
• closed

Есть еще связанный статус ‘reopened’, но рассматривать его пока незачем.

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

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

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

Но добавить новый статус и дальновиднее, и интереснее 🙂

По причинам удобства, хотелось, чтобы статус ‘active’ можно было устанавливать наиболее быстро и просто, без постоянного развертывания выпадающего списка статусов…

Блин, это сделать даже быстрее, чем разъяснить.

Также встал вопрос про статусы ‘acknowledged’ и ‘confirmed’. Вопрос встал такой — нафига нам эти статусы? Мы ими не пользуемся. Надо бы их прибить.

Понеслось!

Как добавить новый статус

Документацией задокументироваться (чем больше, тем лучше):

• http://www.mantisbt.org/forums/viewtopic.php?f=11&t=11873
• http://linuxsysadminblog.com/2009/03/adding-custom-mantis-bug-status/
• http://wiki.colar.net/adding_custom_bug_status_in_mantis
• http://www.mantisbt.org/forums/viewtopic.php?f=3&t=6351
• http://manual.mantisbt.org/manual.customizing.mantis.customizing.status.values.php

В файле ‘config_inc.php‘ указать (там все в одну строку, я тут перенес после запятых, чтобы верстку не ломать):

/*************************
* MantisBT Enum Strings *
 *************************/
$g_status_enum_string =
     '5:active,
     10:new,
     20:feedback,
     30:acknowledged,
     40:confirmed,
     50:assigned,
     80:resolved,
     90:closed';

В файле ‘custom_constant_inc.php‘ указать

<?php
 define ( 'ACTIVE', 5 );
 ?>

В файле ‘custom_strings_inc.php‘ указать

<?php
 if ( lang_get_current() == 'english' )
 {
 $s_status_enum_string =
     '5:active,
     10:new,
     20:feedback,
     30:acknowledged,
     40:confirmed,
     50:assigned,
     80:resolved,
     90:closed';
 $s_active_bug_button = "active";
 $s_active_bug_title = "Set Issue active";
 $s_email_notification_title_for_status_bug_active = "The following issue is active.";
 }
 ?>

Теперь давайте настраивать очередность переходов issue между статусами. Это можно сделать и руками в конфигурационном файле, но проще и нагляднее (а значит, более предсказуемо) сделать это через веб-интерфейс, на странице Workflow Transitions.

Картинка для привлечения нашего наипристальнейшего внимания:

Таблица читается следующим образом:

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

Итак, судя по галочкам из моей таблицы, если какое-нибудь issue будет лениво пребывать в статусе ‘active’, тогда:

• по-умолчанию в выпадающем списке следующий статус будет ‘resolved’. Это указано в крайней правой колонке.

• а возможные пееходы из статуса ‘active’ будут:
  • feedback,
  • assigned,
  • resolved,
  • closed.

Перепрыгнем ниже.

Если issue будет пребывать в статусе ‘assigned’, то:

• по-умолчанию в выпадающем списке следующий статус будет ‘active’.
• а следующими переходами будут
  • active,
  • feedback,
  • assigned,
  • resolved,
  • closed.

Логика понятна?

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

Судя по галочкам в моей таблице, отсутствие галочек в колонках ‘acknowledged’ и ‘confirmed’ означает, что переходов в эти статусы не будет нигде и никогда.

Поэтому на той же странице настройки в разделе «Workflow Validation» будет указано малиновым цветом, что для статусов ‘acknowledged’ и ‘confirmed’

You cannot move an issue into this status.

You cannot move an issue out of this status.

Это нормальное явление. Пусть висит.

Когда-то случалось работать с Mantis с добавленными статусами ‘In testing’ и ‘Tested’, но в нынешнем офисе считается, что задача готова к тестированию в моменту перехода в статус ‘Resolved’. Тоже нормальное явление.

Мелкая мелочь — как в Mantis версии 1.2.2 удалить перечёркнутость с номера issue со статусом ‘resolved’:

скопировать default.css в свой файл mycss.css (находится в каталоге /css/), и заменить в этом файле line 20

a.resolved { text-decoration: line-through underline; 

на

a.resolved { text-decoration:  underline; }

и в файле config_inc.php указать:

$g_css_include_file = 'css/mycss.css'; 

Дорогой разработчик,

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

Для этого используются системы управления дефектами вроде «Mantis».

• Да, можно называть дефекты багами. Главное не в названии, главное в том, что их надо чинить.

Принципиальная схема работы с Mantis

1. Если ты видишь баг — сделай об этом запись в Mantis. Не емайлом, не в скайпе, и не лично, и не молча, если на его починку нужно больше, чем десять секунд. Просто запиши это в Mantis.
2. Заполнить там надо всего лишь четыре поля:
   1. Category — это выпадающий список категорий в отдельно взятом проекте.
   2. Summary — заголовок репорта о проблеме. Опиши свой «wtf?» кратко и без подробностей.
      • Пример неправильного заголовка: «Не могу сохранить пароль».
      • Пример правильного заголовка: «Не могу сохранить пароль если использую заглавные буквы».
   3. Description — а вот тут пиши подробности.
   4. Steps To Reproduce — пожалуй, самая важная часть репорта. Ведь программист, который получает сообщение о баге, но не понимает, что и как ты сделал и почему появился баг — это очень рассерженный программист…
      1. Пример шагов для воспроизведения:

         1. Залогиниться на сайте (tester101/tester101)

         2. Создать тикет в суппорт.

         3. На третьем экране в поле Label вписать слово с двоеточием - 'doc:doc'.

      2. Конечно, записать это требует чуть больше времени, чем сказать «Слушай, это, там чего-то не работает, вот...» Зато потом в ответ не получишь «Я там чо-та пофиксил, я хз, если оно то, о чем ты говорил ваще-та…«
3. Приложи скриншот найдненного тобою бага. Иногда это важнее слов.
4. В Mantis появляется новая задача со статусом New.

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

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

Что такое issue?

Все записи в Mantis называются issue.

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

Фишка в том, что каждое отдельно взятое issue может быть или в любой момент стать как «СООБЩЕНИЕМ О БАГЕ», и «ЗАДАЧЕЙ НА РАЗРАБОТКУ».

Если я сделал запись с сообщением о дефекте — это сообщение о баге.

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

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

Общие правила работы с Mantis

1. Созданная задача получает уникальный номер в системе, и статус New.
2. Если при создании задачи был выбран человек, который будет за нее отвечать, статус задачи становится Assigned.
3. Конечный статус задачи closed. До тех пор, пока задача не получила статус closed — она все еще находится в работе.
4. За каждую отдельную задачу отвечает тот, на чье имя она записана. Для этого используется поле Assigned To. Если ты уверен, что твое участие больше не требуется — переведи задачу в статус Resolved и укажи имя того, кому ты ее передаешь.
5. Прекрасен принцип «One Bug — One Issue». Например, существует задача, которая была источником разработки. А мы нашли баг, который касается непосредственно этой задачи.
6. Не надо вписывать баг как комментарий к задаче — надо сделать новое issue. Иначе потом будет очень сложно «управлять багами», и будет сложно понять, сколько багов было найдено, и сложно объяснять, что «это задача, и она сделана, но в комментариях есть баг, и он не починен». Все задачи, которые связаны между собой, можно слегко «линковать» посредством поля Relationships.
7. Не стесняйся адекватно и вовремя менять статус задачи, с которой работаешь.
8. Будь внимателен с типом задачи (Issue type). Каждый тип («Feature Request», «Change Request», «Bug», «Information») обрабатывается по-разному в процессе разработки. Простейший пример: тестировщик написал Change Request, а программист, не разобравшись, принялся воплощать изменения, считая их задачей…
9. Прежде чем описывать баг или задачу, попытайся написать ее так, чтобы она была понятна всем, в том числе и твоей маме, которая опасается компьютера. Представь себе, что эту задачу назначут твоему коллеге. Представь себе, что он будет ее читать в конце рабочего дня, сильной уставшим. В кого полетит первый камень с вопросом «Ты тут вообще о чем пишешь?»
10. Если возможно, указывай не только то, что надо сделать, но и причину по которой это надо сделать. Это поможет понять приоритетность задачи. Иногда это не очевидно, или очевидно, но не всем.
11. Не используй Mantis как personal task list. Он не для того предназначен.
12. Указывай версию софта, в которой была обнаружена проблема, и указывай версию, в которой это проблема была/будет решена.
13. Есть глубокий смысл в том, чтобы акаунты уровня Developer и Tester (по-умолчанию роли тестировщика в Mantis нет) были лишены возможности ставить статус Closed. Принципиально это должен делать менеджер проекта. Менеджер должен получать прошедшую весь девелоперский цикл задачу только в статусе Tested.
14. Администратор должен всячески связать Mantis с существующей в компании subversion-системой, как бы она ни называлась. В крайнем случае, следует добавить новый цифровой Custom Field, который будет являться обязательным для заполнени при переводе issue в статус Resolved.

Подробная схема работы с Mantis

Разруливание багов через Mantis

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

Подобные схемы разнятся от конторы к конторе, но это именно «принципиальный подход».

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

Управление проектом через Mantis

Это фантастика. Дело в том, что Mantis сделан для разработчиков, и вовсе не предназначался для раздачи задач и составления графиков успеваемости.

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

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

Второе и последнее обращение к нации

Итак, Mantis это инструмент для разработчиков.

Записи в подобной системе помогают основательно сказать «Эта проблема была решена еще в пятницу, 13-го числа — смотри логи, я там оставил комментарий о том, что изменения в коде зачекинены в ревизии 1478…»

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

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

Дефолтный пароль администратора при первой установке Mantis:

Username: administrator

Password: root

Все вышесказанное относится к работе с баг-трекеров В ПРИНЦИПЕ, а не только к Mantis в частности.