project-management
January 30, 2023

Как не обосраться с первым релизом

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

А на утро был показ у заказчика инвестора лечащего врача и оказалось что «ничего не работает».

Знакомо?

Конечно же вы тестировали.

Ваши разработчики тестировали локальную сборку, тестировщики с аналитиками — на стенде. И все дружно сказали «молодца», выставили статусы в трекере и закрыли спринт.

Но тем не менее все дружно обосрались на живых пользователях.

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

Или даже на первых реальных пользователях.

Проверено неоднократно, никак не зависит ни от уровня разработчиков, ни от типов проведенного тестирования, ни даже от количества юнит-тестов.

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

Меня долго и сильно били лопатой учили, еще дольше я учился сам, чтобы теперь сидеть перед вами и выеб#ваться своим опытом.

Типичный пользователь, ваш.

Особенность первая: поворот не туда

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

Есть ряд действий, которые делают пользователи, но никогда не делают представители мира ИТ:

  • Запуск нескольких копий — может быть открытие нескольких вкладок в браузере (если у вас веб-приложение) или запуск нескольких копий приложения одновременно и быстрое закрытие, до завершения запуска (если десктоп).
  • Перетаскивание элементов (Drag&Drop) — файлы, текст, html, куски объектов из Word. Десктоп-приложение может легко упасть на входящей обработке такого элемента, особенно если вы не выставили лимиты на тип и размер данных. В случае веба — может зависнуть браузер на обработке страницы.
  • Насилие над вводом — пользователи легко могут зажать кнопку мыши при клике или кнопку на форме. Минут на 5. Если ваша событийная обработка к такому не готова — ждите вот этих ребят: OutOfMemoryError, «Aw snap!» и «Segmentation fault».
  • Волшебные кнопки «Назад» и «Отмена» — «Назад» в первую очередь в браузере, плюс в пошаговых диалогах. «Отмена» — в диалогах и на формах. Чтобы понять насколько часто это встречается — просто понажимайте «Назад» на ваших любимых сайтах. Очень скоро получите ERR_CACHE_MISS.

Представляете как обидно:

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

А если это инвестор перед раундом финансирования?

Вот так выглядит ваша система на первом релизе. Данных нет.

Особенность вторая: звенящая пустота вместо данных

Очевидно что в новой системе пока еще нет пользователей и нет загруженных данных.

И это проблема, большая. Дело в том что:

система с данными и система без данных — это две разные системы.

Вот настолько все серьезно.

Существует огромный список серьезных ошибок, допущенных при разработке, которые вылезают наружу только при более-менее серьезном объеме данных:

выборки аля select * , без пагинации, фильтрация на клиентской стороне, in-memory кеширование без указания лимитов количества и т.д. и т.п.

Внешне это выглядит как дикие тормоза при открытии страниц с данными и сильная загрузка CPU и памяти.

Поэтому обязательно залейте хотя-бы 30% от планируемого объема в виде тестовых пользовательских данных.

До вашего релиза.

И тестируйте вашу систему сразу с объемом данных:

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

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

Это называется "use cases" или "варианты использования".

Эпилог

Я честно не понимаю, почему про эти особенности не пишут в книжках по тестированию и не упоминают на конференциях.

Полагаю это все же важнее чем умение отличать юнит-тесты от интеграционных. Как думаете?