Subject:

Тестирование в стартапах, часть первая.

Issue ID #045 

Reported at 08.10.2011

Reported byNatalya Rukol

Project Тестирование

Severity Major 

Tags

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

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

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

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

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

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

1. Тестирование в стартапе должно быть дешёвым.
Вообще, тестировщики редко задумываются о стоимости тестирования, потому что деньги-то платятся не из нашего кармана. Но давайте всё-таки не забывать: тестирование — это такая же часть бизнеса, как топ-менеджмент или продажи. А в стартапах экономия значительно важнее, чем в классических проектах.
Почему?
Давайте рассмотрим для сравнения классический проект. Есть продукт, который регулярно выпускает новые версии на рынок (если он тиражный) или делает согласованные доработки, если он заказной. В первом случае у нас есть статистика продаж предыдущих релизов и мы приблизительно представляем, сколько сможем заработать на новой версии. Во втором случае мы даже точно знаем сумму, прописанную в договоре. А что со стартапом? Неизвестно. Будет ли он продаваться? Не знаем. Окупятся ли наши затраты? Надеемся на лучшее… Получается, наши старания могут быть тщетными — и оттого их стоимость становится значительно важнее.
Как это обеспечить?
Работая в классических крупных компаниях я сталкивалась с тем, что в ответ на просьбу «дайте мне ещё 5 тестировщиков» топ-руководство говорит «да запросто», не вникая в причины таких просьб. Этот подход существенно снижает эффективность работы, потому что любые проблемы в процессе можно прикрыть расширением штата. В стартапах мы не можем себе этого позволить, даже если руководство соглашается на расширение — по крайней мере, если правда желаем своему проекту добра :) Каждая активность, выполняемая нами, должна тщательно анализироваться: нам это правда нужно? мы действительно выполняем её оптимальным способом? а как мы можем сделать это лучше, быстрее и выгоднее?

Для достижения этого критерия из нашего арсенала необходимо убрать (если возможно):

  • тяжеловесные методики
  • отчёты (и любые другие действия) для галочки
  • улучшения «про запас», «на будущее» и «потому что так круче»
Для достижения этого критерия в наш арсенал необходимо добавить:

  • ежедневные (или хотя бы еженедельные) оценки эффективности
  • чёткие приоритеты
  • kaizen и lean

2. Тестирование в стартапах должно быть Use-case ориентированным
Как вы думаете, в чём цель первых стартап-релизов? Быть качественными? Поработить мир и завоевать сердца? Заработать миллион долларов?
Как это ни странно, ни один из вышеперечисленных ответов не является корректным. Истинная цель первых релизов — показать себя миру и получить обратную связь:

  • нужен ли кому-то наш продукт?
  • как его будут использовать?
  • в какую сторону его следует развивать?

А для достижения этих целей ваш продукт должен уметь выполнять основные функции. Он не обязан выполнять их идеально, в это сложно поверить (особенно тестировщику), но тем не менее это так.

Почему?
Потому что может быть такое, что ваш продукт просто никому не нужен. Его можно разрабатывать годами, а потом узнать об этом. Обидно, правда? Или (что чаще) может оказаться, что он нужен, но «с перламутровыми пуговицами». А вы как раз последние 4 месяца были заняты отладкой бирюзовых. Не менее обидно, правда? Поэтому, ваша главная задача — убедиться, что он выполняет основные функции — то есть, работают основные пользовательские сценарии (Use-cases).

Как это обеспечить?

  • Базируйте свой тест-анализ и исследование продукта на сценариях использования — а не всех возможных окружениях, входных данных и т.д.
  • Тщательно исследуйте сценарии пользователей: какие проблемы они будут решать использованием вашего ПО? Что оно должно делать, а не как!

3. Тестирование в стартапах должно быть гибким

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

В то время, когда мы тестируем продукт, а разработчики пишут код, stakeholders и аналитики непрерывно исследуют требования рынка и налаживают процесс. Бюрократизированные тестировщики могут сказать, что смена требований — это признак низкокачественного планирования, или бардак, или ещё что-нибудь. Нет! Изменения в требованиях — это своевременная реакция на новую информацию. Зашоренные тестировщики могут сказать, что частые изменения в процессе — признак непродуманности или бардака, но нет! Это непрерывные попытки улучшить текущий порядок вещей.

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

Как это обеспечить?

  • Проводите анализ проектных рисков, чтобы быть готовыми к изменениям и всегда иметь в кармане план «Б»
  • Примите изменчивость как данность. Не пытайтесь бороться — старайтесь успевать!
  • Сто раз подумайте перед любой формализацией. Точно ли она необходима? Вы правда думаете, что тест-кейсы нужны — или это просто вопрос привычки?
  • Договоритесь с другими участниками проектной команды своевременно нотифицировать вас о новых решениях. Не всегда они начнут это делать сразу: продолжайте пинать, и всё получится!

В данный момент у меня есть ещё как минимум четыре критерия тестирования в стартапах, так что ждите продолжения :)

  • Сирожа

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

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

    • http://natalyarukol.ru Natalya Rukol

      1. Давайте конкретнее, как ещё бывает и в чём противоречия с написанным?
      2. Не только тестирование, всё. Но мы вроде про тестирование говорим. По поводу cost-effective: любое тестирование должно таким быть и к этому всегда надо стремиться, стартап/не стартап — пофиг.

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

      • Сирожа

        Ок. Ваши же критерии — новый продукт и небольшая команда.

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

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

        Весь пункт 2 вообще сильно ориентирован на процесс. Будет ли бета тестирование? Будут ли закрытые релизы? Есть ли люди которые работают с потенциальными клиентами по ходу разработки?
        Мне как-то посчастливилось работать в проекте который получал качественную и очень эффективную обратную связь по ходу разработки. Фактически никаких релизов не было. Просто приходил менеджер и говорил «я собираюсь поехать туда-то и туда-то показать там что мы делаем, что я могу взять для демонстрации и о чем мне стоило бы знать?». А потом мы ему помогали приготовиться. После чего менеджер возвращался и сообщал над чем мы будем работать, над чем не будем и почему так. А иногда мы получали специалистов в нужной нам области от потенциальных клиентов, которые рассказывали нам что важно, а что нет.
        Фактически весь п2 это ненавязчивое описание менеджерского фейла. Так делать не надо.

        cost-effective должно быть все и всегда. По идее. Не всегда получается, но к этому надо стремиться.
        А термин «дешевый» он плохой. Он подразумевает много негативного. Cheap testing? Cheap management? Cheap office? Cheap food? Cheap… Не внушает оптимизма, правда?

        • http://natalyarukol.ru Natalya Rukol

          Сирожа, привет!

          Я на 110% согласна с главным посылом: «все случаи уникальны».

          По поводу денег:
          1) «Мы знаем, что можем себе позволить»: естественно, у руководства есть бюджет. Но бюджет не нужно распиливать, руководство не всегда может определить сколько бабла действительно нужно, и за счёт этого многие решения не являюся хотя бы капельку cost-effective. То, что денег дают много — это не повод все тратить, это как минимум непрофессионально.
          2) «Я бы не хотел работать в проекте, который не знает, какие затраты на тестирование окупятся» — в стартапе это НЕПРЕДСКАЗУЕМО. В заказном проекте — вполне. В стабильном тиражном — хотя бы приблизительно. Пока нет сформированной клиентской базы, это невозможно в принципе. Мы можем «рассчитывать», «ожидать» и «планировать». Но рассчитывать != знать.

          По поводу ориентации на кейсы: я в целом согласна с вышеперечисленным, только не нашла никакого противоречия с самой заметкой :) А про бета-тестирование, я сталкивалась с таким опытом: усиленно пилится продукт. Ищется фокус-группа, договариваемся с ней на бета-тестирование. Вроде бы полное соответствие ЦА, вроде бы они хотят потом купить наш продукт, вроде бы всё хорошо. Они какое-то время пользуют, дают обратную связь, она учитывается, продукт выводится на рынок. УПС!! Клиенты хотят всё строго наоборот, верните обратно, а участники бета-кампании покупать раздумали. То же самое и с презентациями, и с выставками софта. Фидбек получаем, а его ценность сомнительна.
          Я управляла бета-кампанией крупного продукта, который выпускает раз в год новые версии. Выдаём ПОСТОЯННЫМ клиентам продукт и собираем фидбек — это работает! Потому что они уже наш продукт покупали и в новой версии заинтересованы.
          ПОТЕНЦИАЛЬНЫЕ клиенты, УВЫ, ещё не равны будущим.

          В разработке софта очень важен time to market. Не «показать кому-то», а продать хоть за три копейки и собрать отзывы в БОЕВОМ ИСПОЛЬЗОВАНИИ.

          • Сирожа

            Опять 25. В стартапе это «не всегда предсказуемо». Наталья, ну не надо так категорично писать.
            Даже с устоявшейся клиентской базой у вас никогда нет 100% уверенности. Есть только ожидания и т.п. Но отсутствие хорошей картинки первоочередных ценностей (она может меняться, но должна быть) это пичалька и как правило факап со стороны тех кто должен был это сформулировать и поддерживать в актуальном состоянии.

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

            А так в заметке все хорошо, кроме категоричности и безальтернативности (не указано значит нет). Контекст в тестировании это почти всегда наше все. На этом надо акцент делать. Остальное это всего лишь частные случаи, которые могут работать, а могут не работать в разных проектах обзываемых стартапами.

            Как итог — я бы крайне не советовал брать все написанное выше и следовать ему от буквы до буквы. Это не silver bullet. Это просто частный случай (или не очень удачная попытка обобщения).

          • Сирожа

            Кстати, «показать кому-то» может быть очень разным. От презентации, до предложения обкатать на их боевой среде с эксклюзивной поддержкой со стороны разработки. Это не релиз. Это даже не бета. Это «первая доза бесплатно». Наш драгдиллер половину будущей клиентской базы именно так и сколотил (в общих чертах, детали я не видел). Подсаживает будь здоров. Правильный подбор тех кого подсаживать тоже решает (а тут очень много работы по части исследования ЦА).
            Правда работает далеко не всегда, т.к. для такой схемы продукт должен или стоить больше определенной суммы или уметь приносить определенные суммы другими путями, иначе просто не окупится.

    • https://www.google.com/accounts/o8/id?id=AItOawln3ZENiYLMA5QJ4FbXF8kF2V3arZBqonM Nick

      Сирожа +1. Похоже на обощение на все стартапы с какого-то конкретного опыта. А какой опыт был, что в нём было важно? Может лучше об этом опыте, как о кейсе?

      ИМХО в стартапах также как и везде: «Тестирование должно быть нужным».
      А дальше уже идёт некая специфика:
      - круг заинтересованных лиц в информации от тестирования
      - приоритеты
      - источники информации о том как должно быть
      -…

      о том что по этим пунктам особенного в стартапах было бы интересно почитать…

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

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

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

      Даже предыдущее моё замечание не имеет смысла без определения что такое «первый релиз» стратапа? У всех будет очень разная схема выхода на рынок. Где её смотреть? Как её узнать? Как узнать на каких этапах какие критические требовкания к продукту…

      • http://natalyarukol.ru Natalya Rukol

        Привет!

        Про обобщение — согласна, исключения неизбежны. Про «с одного опыта» — хех, с 20+ :) Про «узнать цель, узнать приоритеты, узнать требования» — да, да, да!

  • Сергей

    А если проект новый со всех сторон, но с ТЗ, сметой, договорами и уже просчитанными сроками, то он является стартапом или нет?

    • http://www.facebook.com/people/Владимир-Кочегаров/100002277050482 Владимир Кочегаров

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

      • Сергей

        Насчет «повезло» — верно лишь отчасти. Часто бывает так, что ТЗ написано полгода назад и многое поменялось или было реализовано чуть иначе. А тестировщик свято верит в ТЗ и тем самым мы получаем ораву пропущенных багов или затянутый этап полного тестирования.

        • Кочегаров Владимир

          На самом деле философская тема.
          Тут дело в подходе. Когда ты видишь первый раз проект и у тебя нет о нем никакой информации, то ТЗ очень пригодилось бы.
          Речь не идет о тестировании по ТЗ. Я тоже придерживаюсь мнения, что тестирование по ТЗ
          1) Может быть не актуально
          2) Чаще всего тестируя строго по ТЗ — можно пропустить кучу багов
          3) Тестировщик профессия более творческая, а тестирование по ТЗ превращает его в робота.

          • Сирожа

            ТЗ как средство с которого можно начинать — ок. Но можно обойтись без него. В конце-концов если у тестировщика голова из нужного места растет, то своей головы и продукта ему должно хватить. Код приложения, знание предметной области, аналогичные продукты на рынке…

          • Кочегаров Владимир

            Без ТЗ обойтись конечно же можно. Тут никто не спорит. Речь о том, что неплохо бы было, если бы оно было.
            А по поводу знания предметной области + своей головы должно хватить, тоже спорный вопрос. Да можно протестировать продукт на exeptions, js ошибки (если это web-проект), но можно занести кучу багов, которые на самом деле баги со стороны человека, который тестирует. И наоборот пропустить кучу ошибок, потому что тестер думает что результат программы верный.
            Я имею ввиду ситуацию, когда дается какой — то стартап, который необходимо протестировать, но об этом продукте знают только пм и программисты (и то зачастую каждый разрабатывает свой отдельный модуль). И каждый раз бегать и спрашивать как должно и что работать — это потеря времени.
            Но в целом я с тобой согласен. Голова и знания это сила. Но как говорится одна голова хорошо, а две лучше. (Тут имеется ввиду голова тестера и человека который составлял ТЗ).

          • Сирожа

            Неплохо было бы если бы у меня был свой собственный остров и огромная яхта. Наличие ТЗ тут просто меркнет в сравнении.

            Если нет понимания того что нужно и важно, то это или в голове что-то не так или с процессом пичалька. Наличие ТЗ это один из способов это непонимание устранить. Не лучший, а один из.

          • http://natalyarukol.ru Natalya Rukol

            Я с попкорном в первом ряду, весело у вас тут :)

            Начинайте новую ветку, а то текст полоской будет.

      • Сирожа

        Если вам нужно тестировать по ТЗ вам ОЧЕНЬ НЕ повезло.

    • http://natalyarukol.ru Natalya Rukol

      Я не знаю правильного определения слову «стартап», точнее, нашла массу источников с разными определениями :) Но в моей философии заказное ПО это НЕ стартап. Если у вас ТЗ, формальные подходы, и вы выпускаете новый тиражный софт — то это стартап, а если ПО ЗАКАЗНОЕ и вы точно знаете покупателя, то его новизна только в технологии.

  • Кочегаров Владимир

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

    • http://natalyarukol.ru Natalya Rukol

      От тестирования зависит :)

      Мне понравилась недавняя заметка: http://seljava.blogspot.com/2011/10/blog-post.html

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

      Тестировщики, особенно тяготеющие к quality school, хотят всё сделать ХОРОШО и ПРАВИЛЬНО. Я тоже хочу ;) Но это не всегда нужно!! Когда тестировщики понимают командные задачи, то естественно с ними лучше чем без них ;)

  • Валя В.

    Наташа, здравствуйте! Спасибо за пост, как всегда интересно. Но не могли бы вы более чётко объяснить разницу между «стартапом» и «бутстрэппингом»? Ведь по сути и то и другое это создание продукта с нуля.

    • http://natalyarukol.ru Natalya Rukol

      Бутстрэппинг — это разновидность стартапа, при которой внешних инвесторов нет, денег нет, на всём экономим :) В России полно таких стартапов. То есть стартап может быть с кучей денег: столы из красного дерева, самолёты бизнес-класса, делаем новый продукт. Чаще всего такие бывают в рамках уже существующей компании (к примеру, майкрософт решил сделать новый продукт — он ведь будет стартапом).

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

      • Валя В.

        Спасибо за разъяснение:)

Social Widgets powered by AB-WebLog.com.