vc.ru ищет PHP Middle разработчика

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

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

В закладки

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

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

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

Что, если не автотест и почему начинается конфликт?

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

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

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

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

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

Как правильно принимать приложение или сайт?

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

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

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

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

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

Объявление на vc.ru

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

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

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

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

Как передать материалы программисту?

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

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

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

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

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

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

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

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

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

Повторная проверка после исправления

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

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

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

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

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

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

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

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

Удобство работы с верстальщиками и копирайтерами

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

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

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

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

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

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

{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": ["\u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435"], "comments": 27, "likes": 17, "favorites": 90, "is_advertisement": false, "subsite_label": "dev", "id": 146483, "is_wide": true, "is_ugc": true, "date": "Sun, 02 Aug 2020 11:03:28 +0300", "is_special": false }
Трибуна
ApiX-Drive — онлайн-коннектор разных сервисов и приложений между собой без программистов
Рассказываем, как запустили аналог Zapier за три месяца.
Объявление на vc.ru
0
27 комментариев
Популярные
По порядку
Написать комментарий...
6

Кейс работы интересный, но, полагаю, намного проще на том же фрилансе за рублей 300-400 в час нанять мануального тестировщика. Он выполнит нормальный баг репорт в сравнении с техническим заданием, запишет по гифке на каждый баг и вышлет вам. Не придется самому записывать видео и думать о том, кто будет его расшифровывать и проверять. По деньгам выйдет много дешевле, учитывая, что скорость работы у тестировщика будет раза в 2 больше чем у верстальщика, плюсом к тому ваш разработчик не будет гореть от описания бага типа: "Блок корзина: сделано не по т3", потому что верстальщики могут любую глупость написать в описании бага, а тестировщики сделают это по общепринятым стандартам, к примеру: "
- Окружение: Win10, Chrome;
- Настоящее поведение: В блоке 'корзина' не отображаются добавленные товары;
- Ожидаемое поведение: В блоке 'корзина' должны отображаться добавленные пользователем товары;
- Описание: что-нибудь подробно описывает по поводу бага

Ответить
3

Сначала хотел вас распять за видео, но потом дошёл до момента перевода в текст. Хороший подход, надо будет попробовать 

Ответить
3

Так-то у нормальных разрабов юнит-тесты неотъемлемая часть разработки (сам не такой, но стремлюсь).
Чтобы не ругаться с разработчиком, надо тестировать по ТЗ. Соответствует - ок. Не соответствует - баг. Не понимаю, где тут может быть повод для ругани.

Ответить
2

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

Ответить
0

Если честно, я не понял, почему список ошибок текстом ХУЖЕ съёмки видео?? Мне кажется, что это что-то новенькое.
И да, если работник не исправляет свои ошибки после N-ого количества итераций, то это плохой работник и его нужно менять.

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

Ответить
2

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

Ответить
–3

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

Ответить
0

Сделать столько ошибок в одном имени оскорбительно.

Ответить
0

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

Ошибки в приложении могут быть по разным причинам, если они есть в технической части не факт что виноват исполнитель. Планирование, проектирование, аналитика, инфраструктура не менее важны и не все ошибки в таких местах возможно исправить быстро.

Говоря в целом, по моему опыту, самые успешные заказчики-менеджеры были из тех, кто вообще не был способен злится и/или искать виноватых, просто слов таких не знали. У них всегда сходилась на проектах вся экономика.

Ответить
0

А как тогда использовать скрам и беклог?? Сомнительно то, что вы говорите. Обычно программист - это человек с мозгами. А если он не с мозгами, то зачем такой программист?? Как он тогда инструкции читает ?? Взаимодействует с другими программистами?? Да элементарно код пишет, если он не способен читать??

Не знаю, не согласен я с вами. Со всем уважением.

Ответить
5

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

Ответить
0

Что такое душнила??

Ответить
0

Мне кажется, что вас оскорбила вторая часть моего мнения, про бесполезных программистов, которые не способны понимать текст. Увы, но это так :( Если они не могут читать, то значит не могут кодить, разбираться с документацией и заданиями, не могут эффективно взаимодействовать с сообществом.

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

Ответить
1

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

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

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

Ответить
0

Все равно ваш комментарий не отвечает на вопросы.

Ответить
0

Да? Подумал, что мы про более абстрактные вопросы говорим.

Коротко: скрам лишние траты при таком бюджете, бэклог и так ведётся, список есть список. Скидывать проблемы на проекте на "тупых тик ток программистов" не профессионально.  Просто потому что ты их сам нанимал. Нужен кто-то лучше? Плати больше и молись чтобы смета сошлась, а если не можешь, то работай с тем кто есть. Или не профессионально потому что ту или иную проблему решать должен вообще не программист, кто бы что не думал там себе.

Подробнее:
Все умеют читать, но текущая задача звучит так:
1. Ресурсы на найм тестировщика отсутствуют.
2. Человек, принимающий работу не обладает всеми нужными навыками и временем чтобы полноценно заменить тестировщика.

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

Этого ответа достаточно?

Ответить
0

Со всем уважением к вам, но без контроля вы ничего не сделаете. Итерационная работа и поправления работника - благо в любой ситуации. Фриланс или нет, ИТ или нет, контроль - важная часть любого процесса. Так что вы не правы. Беклог вы можете выставить сразу, но иетрации всё равно будут. Будет ли полностью работать по скраму работник или будет делать его элементы, это его право, но я уверен, что частично это будет делать любой.

Ответить
0

Я не про работу без контроля, я про работу без скрама.

Ответить
0

Скрам в том числе про контроль. Итерация и контроль. Например демо. Скрам - это не только про команду и процедуры внутри, это ещё и заказчик.

Ответить
0

Вам уже написали что нужно почитать скрам манифест. Бэклог это далеко ещё не весь скрам.

Ответить
0

Я думал я дурак, пошел смотреть в интернет. Не нашел, что такое "скрам манифест".

Есть "Принципы скрам" и "Скрам гайд", см: https://www.scrumalliance.org/

Но что такое "Манифест скрам", я не увидел.

Может быть вы говорили про аджайл манифест??

Отвечая по существу, я говорю не совсем про беклог. Я говорю еще и про такие определения как спринт, и обзор спринта. См. скрам гайд.

Что касается, аджайл манифеста, то если честно, я не понял, что именно вы мне вменяете?? Напишите конкретно, где именно я не прав и почему.

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

Я даже документа такого не вижу в который вы меня отсылаете.

Ответить
0

Если честно, вы ответили много не по существу.

Ответить
1

Спасибо за инфу!)

Ответить
1

Отличная статья! Люблю такие "живые" статьи с примерами из реальности.

Ответить
1

Толковый материал, взял на вооружение.

Ответить
1

Для формата MVP попробуйте писать е2е. Но не от балды, а руководствуясь ТЗ. Экономит много времени, можно встроить в CI, в некоторых случаях вскрывает проблемы приложения, которые иначе бы просмотрели

Ответить
1

Прямо в точку. У нас в группе компаний сейчас создается продукт как раз по протоколлированию ручного тестирования https://bugcatcher.pro/, кому интересно, обращайтесь. Проект находится а альфа версии, и пока можно бесплатно поюзать.

Ответить

Комментарии