Тестирование в стартапе: Worksection

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

Дигибу узнал, что и как приходится тестировать в Worksection — удобной и простой онлайн-системе для управления проектами.

Рассказывает Чингис Баринов, со-основатель проекта Worksection, г. Киев, Украина.

Worksection

Что именно вам приходится тестировать в Worskection?

Обычно мы тестируем обновления. Это или новый функционал, или переделка существующих сценариев работы. К примеру, сейчас переделываем и тестируем «Лёгкий старт» пользователя. Это такая пошаговая инструкция для того, кто первый раз попадает в свой аккаунт. Мы хотим помочь ему во всём разобраться по порядку — создать проект, задачу, пригласить человека и так далее. Сейчас у нас нет последовательного руководства, и новый пользователь может потеряться, не зная, что ему делать в самом начале.

Как выглядит процесс тестирования в вашей команде? Расскажите о нём подробнее.

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

Дальше идет брейнсторминг, который необходим для определения логики того, как пользователь будет работать с новым функционалом. Участие ведущего программиста и арт-директора здесь просто обязательно. Они помогают сразу отсечь фантастические сценарии.

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

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

И вот здесь мы проводим следующие тесты:

  • Тесты на логически пограничные ситуации.
  • Проверка реакции на ввод недопустимых данных.
  • Определение возможности взломать базу или получить доступ к закрытым данным.
  • Нагрузочные тесты, оптимизация запросов к базе.

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

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

Во время «беты» мы активно пользуемся новой фишкой внутри команды. Плюс у нас есть клиенты, которые по договорённости так же тестируют новый функционал и оставляют обратную связь. Приблизительно через неделю таких тестов апдейт уходит в релиз, и мы начинаем прислушиваться к обратной связи уже всех пользователей.

Вы отдаёте предпочтение профессиональным тестировщикам?

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

В нашей команде работает один профессиональный тестировщик и несколько непрофессиональных.

Как именно они тестируют функционал?

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

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

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

В чем уникальность тестирования в Worksection?

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