Сегодня я хочу поделиться информацией, которая будет полезна тестировщикам в стартапах. Здесь не будет пустого бухтелова, потому что стартапами я занимаюсь много, и написанное ниже — квитэссенция полученного опыта.
Для начала, определимся с терминами: что такое стартап?
Если верить Гаю Кавасаки, автору культовой книги «Стартап», к их числу можно отнести любой новый продукт. К примеру, если компания Microsoft надумает выпустить новый софт, которого раньше не делала (профессиональный графический редактор, например), выделит на его создание миллионы долларов и сотни разработчиков, это тоже будет стартап. Однако на постсоветском пространстве стартапами обычно называют то, что на западе зовут «бутстрэппингом» — то есть создание продукта с нуля и даже без привлечения сторонних инвестиций.
В рамках этой статьи я выберу компромисс и к стартапам отнесу проекты, удовлетворяющие следующим критериям:
- Новизна продукта. То есть мы говорим о создании нового продукта, а не поддержке/доработке старых версий, уже «прижившихся» на рынке.
- Небольшая команда. Несмотря на то, что формальное определение стартапа ни капельки не лимитирует команду, чаще всего стартапами называют проекты небольшие, с командами от 5 до 20 человек.
А теперь главный вопрос: каким должно быть тестирование в стартапах?
Я постараюсь не просто на него ответить, но и объяснить «а почему так?», в чём корень того или иного требования. Поэтому, ниже — список «стартаперских» требований к тестированию с обоснованием «а нахуа?»
1. Тестирование в стартапе должно быть дешёвым.
Вообще, тестировщики редко задумываются о стоимости тестирования, потому что деньги-то платятся не из нашего кармана. Но давайте всё-таки не забывать: тестирование — это такая же часть бизнеса, как топ-менеджмент или продажи. А в стартапах экономия значительно важнее, чем в классических проектах.
Почему?
Давайте рассмотрим для сравнения классический проект. Есть продукт, который регулярно выпускает новые версии на рынок (если он тиражный) или делает согласованные доработки, если он заказной. В первом случае у нас есть статистика продаж предыдущих релизов и мы приблизительно представляем, сколько сможем заработать на новой версии. Во втором случае мы даже точно знаем сумму, прописанную в договоре. А что со стартапом? Неизвестно. Будет ли он продаваться? Не знаем. Окупятся ли наши затраты? Надеемся на лучшее… Получается, наши старания могут быть тщетными — и оттого их стоимость становится значительно важнее.
Как это обеспечить?
Работая в классических крупных компаниях я сталкивалась с тем, что в ответ на просьбу «дайте мне ещё 5 тестировщиков» топ-руководство говорит «да запросто», не вникая в причины таких просьб. Этот подход существенно снижает эффективность работы, потому что любые проблемы в процессе можно прикрыть расширением штата. В стартапах мы не можем себе этого позволить, даже если руководство соглашается на расширение — по крайней мере, если правда желаем своему проекту добра 
Каждая активность, выполняемая нами, должна тщательно анализироваться: нам это правда нужно? мы действительно выполняем её оптимальным способом? а как мы можем сделать это лучше, быстрее и выгоднее?
Для достижения этого критерия из нашего арсенала необходимо убрать (если возможно):
|
Для достижения этого критерия в наш арсенал необходимо добавить: |
2. Тестирование в стартапах должно быть Use-case ориентированным
Как вы думаете, в чём цель первых стартап-релизов? Быть качественными? Поработить мир и завоевать сердца? Заработать миллион долларов?
Как это ни странно, ни один из вышеперечисленных ответов не является корректным. Истинная цель первых релизов — показать себя миру и получить обратную связь:
- нужен ли кому-то наш продукт?
- как его будут использовать?
- в какую сторону его следует развивать?
А для достижения этих целей ваш продукт должен уметь выполнять основные функции. Он не обязан выполнять их идеально, в это сложно поверить (особенно тестировщику), но тем не менее это так.
Почему?
Потому что может быть такое, что ваш продукт просто никому не нужен. Его можно разрабатывать годами, а потом узнать об этом. Обидно, правда? Или (что чаще) может оказаться, что он нужен, но «с перламутровыми пуговицами». А вы как раз последние 4 месяца были заняты отладкой бирюзовых. Не менее обидно, правда? Поэтому, ваша главная задача — убедиться, что он выполняет основные функции — то есть, работают основные пользовательские сценарии (Use-cases).
Как это обеспечить?
- Базируйте свой тест-анализ и исследование продукта на сценариях использования — а не всех возможных окружениях, входных данных и т.д.
- Тщательно исследуйте сценарии пользователей: какие проблемы они будут решать использованием вашего ПО? Что оно должно делать, а не как!
3. Тестирование в стартапах должно быть гибким
И не только потому, что превалирующее большинство стартапов использует гибкие методологии. Если вы будете в динамичных условиях стартапов пытаться работать по «стандартной» или «правильной» схеме, то вы будете тормозить весь проект!
В то время, когда мы тестируем продукт, а разработчики пишут код, stakeholders и аналитики непрерывно исследуют требования рынка и налаживают процесс. Бюрократизированные тестировщики могут сказать, что смена требований — это признак низкокачественного планирования, или бардак, или ещё что-нибудь. Нет! Изменения в требованиях — это своевременная реакция на новую информацию. Зашоренные тестировщики могут сказать, что частые изменения в процессе — признак непродуманности или бардака, но нет! Это непрерывные попытки улучшить текущий порядок вещей.
Если вы умеете подстраиваться под изменения и проявлять гибкость, то вы гарантированно принесёте значительно больше пользы проекту, чем если будете бороться за стабильность.
Как это обеспечить?
- Проводите анализ проектных рисков, чтобы быть готовыми к изменениям и всегда иметь в кармане план «Б»
- Примите изменчивость как данность. Не пытайтесь бороться — старайтесь успевать!
- Сто раз подумайте перед любой формализацией. Точно ли она необходима? Вы правда думаете, что тест-кейсы нужны — или это просто вопрос привычки?
- Договоритесь с другими участниками проектной команды своевременно нотифицировать вас о новых решениях. Не всегда они начнут это делать сразу: продолжайте пинать, и всё получится!
В данный момент у меня есть ещё как минимум четыре критерия тестирования в стартапах, так что ждите продолжения