Ищем разработчика, который без ума от JavaScript и клёвых анимаций

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

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

В закладки

Предыстория

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

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

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

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

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

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

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

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

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

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

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

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

Заказчик:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

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

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

{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 5, "likes": 6, "favorites": 12, "is_advertisement": false, "subsite_label": "legal", "id": 158296, "is_wide": false, "is_ugc": true, "date": "Sat, 19 Sep 2020 14:00:40 +0300", "is_special": false }
Маркетинг
Перемен! Новая модель монетизации как способ остаться востребованным на рынке
Мы живем в непростом 2020 году, в котором квест «Как сохранить бизнес?» прошли все предприниматели: от основателей…
Объявление на vc.ru
0
5 комментариев
Популярные
По порядку
1

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

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

Ответить
0

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

Ответить
1

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

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

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

Ответить
0

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

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

Ответить
0

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

Ответить

Комментарии

null