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

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

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

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

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

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

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

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

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

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

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

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

Заказчик:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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