Мыслетрекер

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

Для начала, определимся с терминами: что такое стартап?
Если верить Гаю Кавасаки, автору культовой книги «Стартап», к их числу можно отнести любой новый продукт. К примеру, если компания Microsoft надумает выпустить новый софт, которого раньше не делала (профессиональный графический редактор, например), выделит на его создание миллионы долларов и сотни разработчиков, это тоже будет стартап. Однако на постсоветском пространстве стартапами обычно называют то, что на западе зовут «бутстрэппингом» — то есть создание продукта с нуля и даже без привлечения сторонних инвестиций.

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

• Новизна продукта. То есть мы говорим о создании нового продукта, а не поддержке/доработке старых версий, уже «прижившихся» на рынке.
• Небольшая команда. Несмотря на то, что формальное определение стартапа ни капельки не лимитирует команду, чаще всего стартапами называют проекты небольшие, с командами от 5 до 20 человек.

А теперь главный вопрос: каким должно быть тестирование в стартапах?

Я постараюсь не просто на него ответить, но и объяснить «а почему так?», в чём корень того или иного требования. Поэтому, ниже — список «стартаперских» требований к тестированию с обоснованием «а нахуа?» Read more

На этих выходных я проводила тренинг «Планирование и проектирование тестов» в Москве. Один из участников на вопрос «зачем ты пришёл на тренинг?» ответил «точить топор!«. А позже рассказал притчу:

2 дровосека поспорили, кто больше деревьев может срубить за день. Один непрерывно рубил, кромсал, ужасно устал, но очень гордился собой и был уверен, что победит. При этом он видел, что второй часто отвлекается, слоняется, и это добавляло первому дровосеку уверенности в победе. Но когда пришло время подсчёта, оказалось, что с большим перевесом выиграл второй. На вопрос «как так?» второй дровосек ответил: «я не просто непрерывно рубил, я ещё и топор регулярно затачивал».

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

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

Классные примеры? Да! Но «первых дровосеков» я встречаю не реже! Эти люди приходят в отрасль, стараются, работают, стараются, работают, рубят, пилят, рубят, пилят… Годами, на одинаковых позициях, с одинаковыми результатами. Часть из них трудоголят по 60 часов в неделю, но результаты их работы от этого лучше не становятся! Они занимаются одними и теми же задачами, и с учётом инфляции их зарплаты даже не меняются.

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

Perche? И что делать? Read more

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

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

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

Зачастую нам надо проверить, что продукт работает с «правильными» е-мейлами и не работает с неправильными. Правила корректности е-мейлов можно посмотреть в RFC: допустимые символы, максимальная длина имени и доменной части… Но оказывается, можно не париться и воспользоваться прекрасным сервисом, который определяет корректность е-мейла на соответствие стандартам: http://isemail.info/_system/is_email/test/ Он не просто скажет, корректный адрес или нет, но ещё и расскажет где ошибка. Там же можно подсмотреть различные тесты на валидные и невалидные адреса, которые удобно использовать в тестировании: http://isemail.info/_system/is_email/test/?all

Вот такой удобный сервис

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

Read more

Пусть ярость благородная
Вскипает, как волна, -
Идет война народная,
Священная война!

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

Т: Он ничего полезного не делает, только важничает
М: Он не понимает целей бизнеса, думает, его задачи самые важные, что ли?
Т: Он ничего не знает, чтобы отчёты писать и письма туда-сюда пересылать, много ума не надо
М: Он не знает что такое facilitation skills, а я их непрерывно применяю, и у меня из-за этого стресс и выгорание!
Т: Он зарабатывает больше меня, ну на за что??
М: Он зарабатывает как я, ну за что???
Т: Отчёты, таблички, планы… Что это всё за фигня, он мешает мне работать!
М: Он не понимает наш процесс, он не командный игрок!
Т: Он сказал «сделай это до завтра», он что, вообще ненормальный? Это задача на две недели, он засиделся на менеджерском кресле настолько, что уже ничего не понимает в деле.
М: Он всё время срывает сроки и не понимает, как нам важно это сделать вовремя!

Продолжать можно до бесконечности, уверена, что разные проявления этой войны вы сами неоднократно встречали. Почему она началась, к чему приводит и что с ней делать?
Read more

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

Почему так происходит? Read more

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

Итак, что должен сделать тест-менеджер, чтобы всё было хорошо? Read more

Это должно было произойти давно. Очень давно. Но не будем о грустном, лучше о хорошем: ЭТО ПРОИЗОШЛО!

Появилась утилита для удобной совместной работы над чек-листами. Она ещё сырая, но она уже ждёт ваших оценок! Все подробности — здесь: http://sitechco.ru