Мыслетрекер

Всем привет-привет!

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

Эта книга рассчитана на действующих тест-менеджеров, руководящих как нано-командами, так и крупными департаментами. При этом мне кажется, что для ТМов с опытом меньше, чем 1-2 года, она может быть слишком сложной, а для ТМов с опытом over 10 лет она наоборот рискует оказаться слишком простой и скучной.

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

Я ищу ревьюеров, которые помогут мне сделать эту книжку лучше. Каждые 1-2 недели я бы высылала вам новую главу, чтобы вы:

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

Каждому ревьюеру я буду очень-очень признательна, а именно:

• я сделаю эту книгу для вас максимально полезной;
• я поделюсь с вами свеженапечатанным экземпляром книги с-пылу-с-жару;
• в процессе работы над книгой (которая по сути является книгой-тренингом и во многом похожа на Школу Тест-Менеджера) я помогу вам с ответами на вопросы, которые у вас стоят в регулярной рабочей деятельности.

Вы — мой идеальный рецензент, если вы входите в 1 из 2 следующих категорий:

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

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

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

Всем заранее спасибо!

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

Это был эксперимент, и эксперимент удачный!

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

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

«Материал изложен очень четко и понятно.
Интересное домашнее задание.
Хорошо то, что были сроки на выполнения ДЗ, любые вопросы можно было тут же задать и получить на них ответ.
Отличный фидбэк по ДЗ.
Получены новые знания, позволяющие эффективно планировать на практике.»

«Понравилось то, что необходимо было выполнить домашку, чтобы получить доступ к следующему заданию!
Хотелось бы еще поучавствовать в тренинге подобного формата»

«Формат понравился, минимум теории, максимум погружения.»

ОК, идея протестирована, так что надо расширять линейку

На текущий момент я подготовила аж три тренинга в новом формате:

• Интенсив по планированию тестирования
• Интенсив по организации тест-дизайна
• Интенсив по управлению командой тестировщиков

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

Кто не боится сложностей — присоединяйтесь!

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

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

Read more

Зимние каникулы — отличное время для саморазвития. Ну, и для отдыха немножко

В числе прочего, посмотрела видео Станислава Протасова о карьере в софтверных компаниях (чего и вам советую, т.к. говорит не теоретик, а опытный практик):

Карьера в софтверной компании (Станислав Протасов, Senior VP, Parallels) from stratoplan on Vimeo.

Read more

Я часто слышу слова «процесс», «строить процесс», «улучшать процесс» и т.д.

А что это такое? Зачем это нужно? Как это делать?

Давайте разбирать поэтапно. Read more

Жила-была компания, разрабатывавшая программные продукты. И были в ней тестировщики. И тестировали они денно и нощно, а продукт был отстойным. То они какое-то требование пропустят и не заметят, а пользователь жалуется, и тестировщики виноваты: надо внимательнее требования читать. То багу критичную, возникшую за 2 часа до релиза, не найдут, и снова это их вина: тестировать надо больше. Пользователь не доволен даже реализованными требованиями: а почему вы их не протестировали? Продукт работает медленно в окружении заказчика: а почему вы это не выявили? Выпущенные ошибки беспокоят пользователя: а почему вы не донесли достаточно внятно информацию об их критичности? Долго команда и тестировщики так и сосуществовали. И всем, даже тестировщикам, казалось такое положение вещей правильным. Они всё время работали над собой, ища, как они могут решить ту или иную проблему. Потому, что считали такие проблемы СВОИМИ. Но как-то раз древний мудрец по разработке ПО проходил мимо их офиса. Заглянул он к ним, увидел происходящее, и заявил: “Ребята, вы, конечно молодцы… Но вы решаете чужие проблемы!”. “Как так?”, – удивились тестировщики. “А вот так», – ответил мудрец, – “давайте я покажу, как это работает в более зрелых компаниях”. И вместе с ними нарисовал примерно следующую табличку:

Тестировщики смотрели на табличку, которая получилась у мудреца, и удивлялись. — Но если в нашем процессе всё будет, как ты предложил в колонке с “правильным” решением, то мы будем не нужны? — Будете, – ответил мудрец. – Но вы не будете выполнять мартышечий и бессмысленный, малоэффективный труд. Вы сможете больше внимания уделять исследовательскому тестированию нового функционала, разработке грамотных и стабильных автотестов, и внедрению метрик и практик качества. — Но ведь такого “хорошего” процесса не бывает! Это же миф! — Хи-хи, – улыбнулся мудрец. — Я видел такие компании. Я знаю, какой тяжёлый путь они прошли, и эти сложности были связаны в основном с кашей в головах участников процесса, а не с реальными проблемами. В этих компаниях работать приятно, а продукты вызывают гордость команды. — Но как нам найти такую компанию? — Не надо искать. Сделайте это в своей компании! Да, вы просто тестировщики. Но вы и так уже достаточно давно занимаетесь тем, что решаете ЧУЖИЕ проблемы. Так начните их решать правильно! Промойте мозги своему начальнику, покажите ему эту статью. Отправьте его на конференцию, пусть отвлечётся от своей псевдополезной деятельности. Выявите, какая проблема у вас самая сильная – и предложите её решения, познакомьтесь с правильными действиями в этой ситуации, и начните это внедрять сами. Иначе вы так навсегда и останетесь козлами отпущения, виноватыми за чужие проблемы – и ни капельки не влияющими на качество продукта!

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

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

Итак, давайте рассмотрим пример:

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

Если бы я гоняла тесты вручную и не автоматизировала, то у меня бы ушло 200 + 200 = 400 минут на 10-ти запусках. В таком случае, 1-й сценарий автоматизации НЕВЫГОДНЫЙ, а 2-й ВЫГОДНЫЙ.

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

На днях разговаривала с одним новоиспечённым тест-менеджером. Она очень старательная девушка, впервые руководит командой, и хочет всё сделать хорошо. У неё сразу вопросы:
* где вести вики, чтобы ничего не потерять?
* где вести чек-листы?
* где вести данные по сотрудникам?
* где заводить не-баги?
….

В моей религии, правильный ответ на начале всегда одинаковый: гуглодоки! У меня они есть для всего и вся. Таблички с чек-листами, таблички с сотрудниками, списки по собеседованиям, ЧАВО, и т.д.

Почему так? Потому что сразу очень сложно понять, какой инструмент нужен. Можно долго внедрять, делать, продумывать, потом понять, что инструмент не очень подходит, возиться с ним, допиливать, переделывать… ууфффф!

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

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

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

Доклад Насти Мусиной — бомба! Я хочу в её команду тестировщиком! Классно сделано!

Когда обсуждают тему планирования (тестирования и не только), часто начинают со сложного: тест-планы, стратегии, метрики для оценки трудозатрат… И начать планировать очень сложно.

Давайте пойдём поэтапно: как начать планировать и получать от этого удовольствие? Сегодня с меня инструкция по планированию первого уровня. Read more