Тестирование сервиса без ругани с программистом

Денис Гордиенко, генеральный директор Bright Mobile, о том, как без лишней нервотрёпки и ругани проверить приложение

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

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

Часто забывается, что unit-тесты актуальны лишь в дорогом и премиум-сегменте. Если у вас приложение за 2 млн.+ рублей, то в сумму обычно автотест включается, но при разработке сервиса в низком или даже среднем ценовом сегменте, вам, скорее всего, будет слишком дорого заказывать unit-тесты. В среднем они стоят от 25 до 50% стоимости программирования и от 15 до 30% от цены всего приложения.

Если вы условный Сбербанк, что руками прогнать тест практически невозможно из-за объёма функционала, то переплатить за это 50% стоимости разработки — нормально. Если же стартап, где на MVP закладывается 500-700 тыс. рублей, то достать ещё 200, чтобы не проверять руками, кажется избыточной расточительностью — выгоднее эти деньги вложить в раскрутку.

Если вы идёте по второму варианту, то придётся столкнуться с ручным тестированием – процессом, в котором всю проверку осуществляет сам разработчик (и вы вместе с ним). Такое тестирование может затягиваться на долгий срок: сначала программист найдёт баги, потом вы обнаружите те, что он пропустил, затем он снова заметит другие, потом появятся новые, и так далее много, много раз.

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

Клиент может злиться на программиста: тот, мол, дурак, не видит явные ошибки. С другой стороны, он может посчитать багом тот факт, что программист не заложил в конечный продукт очевидные для него вещи, хотя в ТЗ их не было. По его мнению, это было «понятно и так», но разработчик этого не знал – и потому не добавил.

Тут ругаться начинает уже программист, который требует, чтобы клиент сначала отсортировал реальные ошибки от своих пожеланий, и только потом предъявлял претензии. Эмоции накаляются, заказчик злится – типовая история, которая нередко выливается во взаимную ругань и уход к новому разработчику с просьбой доделать 5% объёма, за которыми не редко скрываются все 30.

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

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

Первое, с чего нужно начинать, принимая работу – это открывать ТЗ. Если вам что-то хочется, но в ТЗ этого нет – это уже как раз «пожелания», которые к ошибкам не относятся. А вот если это прописано, но не работает или работает некорректно – это уже нужно исправлять.

Приведу пример одной ошибки. Перед вами описание экрана авторизации в приложении по продаже цветов.

Именно так он должен выглядеть в конечном варианте: поле ввода телефона, поле ввода кода, которое приходит смской. Стандартный сценарий, никаких подвохов. После авторизации должен осуществляться переход в каталог.

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

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

Заказчик злится: он просидел столько времени, а часть ошибок опятьне исправлено. Заказчик считает, что это наплевательски подход. Чтобы этого не было, лучше делать видео. Записывайте и диктуйте всё, что видите, объясните, почему это должно быть не так, а иначе – всегда ссылайтесь на ТЗ для наглядности. Выглядеть это будет примерно так:

Вы должны пройти все описанные в ТЗ сценарии – и либо подтвердить, что всё работает корректно, либо указать голосом на какие-то ошибки. В среднем на приложение из 20 экранов уйдёт полчаса – и на этом ваша работа по тестированию закончится. Весьма существенная экономия времени и нервов.

Следующий пункт, который вам нужно выполнить – перегнать всё записанное на видео в табличный формат. Руками это делать не нужно, для этого есть фриланс. Создаёте проект, пишете, что нужно перегнать видео в табличку по определённому формату, и ставите это в раздел «вёрстка».

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

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

Текст воспринимается проще – опросил нескольких программистов, и все они единогласно это подтвердили. Если уж совсем непонятное описание, то просматривается именно тот кусок, который вызвал вопросы. Ему не придётся просматривать все полчаса, нужно будет глянуть только те баги, которые он не понял.

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

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

Прикинем по деньгам: час видео – это где-то два-три часа ручной работы по заполнению. Полчаса, соответственно, полтора часа на таблицу. Если верстальщик на фрилансе за час берёт 600 рублей, то получение такого списка у вас будет стоить ±1 000р. Лучше нанять трёх-четырёх человек, чтобы посмотреть, насколько соотносятся полученные списки с тем, что на ваш взгляд написано более грамотно и адекватно, и выбрать того, кто вам подходит больше.

Тянуть время и экономить на таких непринципиальных суммах нет смысла – ладно ещё, если бы это стоило тысяч десять-двадцать, как у некоторых агентств по тестированию, но ценность выбрать наиболее грамотное описание стоит дополнительных 2-3 тыс. Контакты самого адекватного верстальщика оставляем.

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

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

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

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

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

Почему не передать проверку тем же вертальщикам, которые изначально работали над списком, а поручить дело копирайтерам? Ответ прост – услуги копирайтеров обойдутся в два раза дешевле. Если занесение этого списка стоило тысячу, то его проверка будет стоить 500 рублей. Точно так же можно заказать проверку у двух-трёх человек, если кто-то из проверенных специалистов не может взять проект в работу.

Соответственно, задача копирайтера – проверить, всё ли исправлено. Если баг починили, он выделяет его зелёным. Если нет, красным. Вот и вся работа – он просто повторяет ваши действия из видео и красит баги в те или иные цвета. Не нужно изучать ТЗ, не нужно погружаться в проект: есть список, есть видео, скачай, проверь, покрась.

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

Итого за 20 ошибок одного приложения на 20 экранов вы в среднем отдаёте тысячу рублей за составление списка и полторы на его проверку. За две с половиной тысячи рублей вы можете просто и без нервов тестировать приложения: вам нужно будет только вовремя реагировать на комментарии программиста, т.к. некоторые доработки вы можете оформить как ошибки, это уже вопрос переговоров и доплаты.

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

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

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

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

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

Больше интересных материалов по ведению проекта можно посмотреть на моём YouTube.

#тестирование