На что обращать внимание при принятии сайта или приложения?

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

Предыстория

Полтора года назад мы запустили вторую версию коробочного решения для маркетплейсов услуг. Общая идея в том, что для теста идеи не нужно тратить 1-1,5 млн на разработку сайта и приложения с нуля, а можно проверить идею на нашем решении в 10 раз дешевле.

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

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

Вместе с тем, недооценил, что для большинства веб-разработчиков работа вне стека php+mysql кажется уже сложной задачей и плановый 1 месяц на создание сайта превратился в долгие 5. Сегодня расскажу на какие вещи нужно обращать внимание при проверке и как правильно давать обратную связь о багах.

Что и как проверяем

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

Многим кажется, что проверку можно поручить помощнику — дело это очень скучное и не интересное. Я тоже так считал в начале года, если бы проверял с самого начала сам — сэкономил бы 2 месяца из 5.

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

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

В-третьих, тестируя со стороны пользователя можно увидеть и обкатать преимущества решения для этих самых пользователей.

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

Заказчик:

  1. Авторизуется на сервисе
  2. Создаёт задание
  3. Получает отклики и уведомления об откликах
  4. Просматривает профили исполнителей
  5. Пишет во внутренний мессенджер или звонит по телефону тем кто понравился, о новых сообщениях получает уведомления
  6. Может не создавая задание перейти в список исполнителей и далее на шаг № 4

Исполнитель:

  1. Авторизуется на сервисе
  2. Заполняет профиль исполнителя
  3. Просматривает биржу заказов
  4. Настраивает подписки на категории заказов и получает уведомления о новых заказах
  5. Смотрит детали заказа и пишет своё предложение
  6. Отвечает заказчику в мессенджере, о новых сообщениях получает уведомления

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

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

Вот пример видео и баглиста на его основе:

Видео с проверкой сайта,
Итоговый баглист

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

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

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

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

Переходим к откликам: открываем «все задания» и начинаем на них отвечать. У нас опять вылетает ошибка 404. Правда, только при нажатии на текст: если кликнуть на заголовок задания, всё работает, но должно-то работать одинаково как в первом, так и во втором случаях.

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

Попробуем ответить на своё задание с другого профиля: будет ли тогда чужой отклик виден автору задания? Как видим, нет. Заказчик не видит отклики исполнителей.

Ещё при нажатии на отклик у нас должен открываться профиль исполнителя: это не происходит. Соответственно, нельзя даже посмотреть, кто ответил на проект. Откроем список всех исполнителей, выберем одного из фрилансеров. Например, Дмитрия Классена. Щёлкаем – открывается Денис Гордиенко: в строку не подставляется ID выбранного профиля, а потому по умолчанию открывается свой собственный. То же самое будет и при клике на иных исполнителей.

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

Диалог открывается, пишем сообщение, отправляем. У получателя должно появиться уведомление — появляется. Отвечаем. Опять проблема: чужие сообщения в диалоге не видны, отображаются только свои. Так что мессенджер не работает, вот и ещё одна головная боль для программиста.

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

Таким образом, из глобальных вещей у нас не работают:

  • просмотр своего задания,
  • отклик,
  • чат,
  • переход из просмотра задания в профиль пользователя.

Итоги

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

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

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

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

0
5 комментариев
Артем Акулов

Кому лень читать.

На что обращать внимание при принятии сайта или приложения?

На сайт и приложение.
Конец.

Ответить
Развернуть ветку
Алексей Долгих - CVO Scout VC

@Денис Гордиенко очень слабое у вас понимание что такое приемочное тестирование, очень 😔 Очень важно иметь контекст, или поведенческие сценарии чтобы проверять функционал и делать статьи похожие на эту более качественными. Направление обеспечения качества производства коробочных продуктов очень развито, если вы не слышали про него, это только нехватка компетенции у вас, это не в коем случае не наезд, но так называемые end2end проверки много лет на рынке и помогают делать то где вы предпринимаете попытки нового направления (тестирование функционала чёрных ящиков) 🌞 Правда интересно с вами на эту тему поговорить, если заметите сообщение и будет время, пишите, есть приличный опыт в обеспечении качеств программных продуктов и понимание как это качество монетизировать!

Ответить
Развернуть ветку
Денис Гордиенко
Автор

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

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

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

Ответить
Развернуть ветку
Алексей Долгих - CVO Scout VC

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

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

Ответить
Развернуть ветку
Антон Котырев

а ты свой то софт до ума довёл или только болтать сюда пришёл?

Ответить
Развернуть ветку
2 комментария
Раскрывать всегда