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

Текст слегка дополнен всем тем, о чем я хотел сказать,

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

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

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

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

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

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

А никак.

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

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

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

12 ответов на “Алексей Лупан: Мал, да удал — менеджмент тестирования в маленькой компании”

  1. Алексей, спасибо за слайды. Скажите, пожалуйста, а слайдкаста или аудио-записи или нет у Вас?

    • Есть запись, но нет никакого резона ее публиковать.
      Я сразу после старта забыл всё то, что хотел сказать, и импровизировал на ходу — получилось сложно, рвано, некоторые важные моменты я так и не сказал, а некоторые повторил, забыв, что уже говорил.
      Я делаю текст из сказанного, он скоро тут появится.

  2. Алексей, очень жаль, что ты не будешь делать слайдкаст.
    Слайдкасты рулят, даже если рвано и не все сказано.
    У меня тоже часть важных слов исчезло при выступлении…так наверное всегда бывает. Те, кто были на твоем докладе его хвалили. Вот хотелось послушать… Может передумаешь и выложишь?

    • Не рулят в моем случае.
      1) Слайды у меня простые, как заголовки. Текст выполняет те же информационные функции.
      2) Эффектов и картинок у меня нет. Сплошной текст.
      3) Я действительно излишне переволновался от почина, и весь подготовленный текст забыл, пришлось импровизировать на ходу. Потому доклад получился рваный и лишенный многих важных мелочей. И в последний момент я несколько слайдов поменял местами, бо сил на это не было смотреть…
      4) Текст удобнее для восприятия информации и для последующего к ней обращения. Собственно, потому я некоторые чужие доклады расшифровываю — мне самому потом будет комфортнее и быстрее воспринимать текст, а не прокручивать аудиозапись в поисках «хз, где это было, вообще…»
      5) Поскольку я лучше воспринимаю образы текста, нежели звуки или видео, текст дополнительно обработан и местами изменен — вставлены дополнения, какие-то абзацы переставлены местами, какие-то места переформулированы. Получилось уже что-то иное, нежели просто расшифровка аудиозаписи. Поэтому ставить их рядом бессмысленно — слайдкаст получился бы «ver.1.0».
      6) Я переслушивал аудио раз пять, все думал, где можно что-то скомбинировать, дописать, например, бо это технически просто, но в итоге понял, что получится какое-то двухчасовое чтение, что утомительно и проигрывает резвому и основательному тексту. Оставил запись в архиве как материал для сравнения с вероятными последующими публичными выступлениями — это мне будет полезно.
      Поэтому я принял решение о том, что текст предпочтительнее.

  3. Спасибо. Информативно. Некоторые моменты близки. 100% попадание.
    P.S. в первом комментарии от Александрова — «…Я надеюсь, что лешин опыт и опыт всех присутствующих…» за что себя с маленькой буквы-то?

  4. Спасибо. Очень близко то,о чем вы говорите! Жалею,что не попала на ваш доклад:)

  5. Спасибо, познавательная статья.
    Есть интересные мысли, хотя я сам с такими ситуациями и не сталкивался. Теперь буду понимать их более полно.

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

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

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

Добавить комментарий для Андрей Отменить ответ