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

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

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



0. Разберемся на берегу


Зачем нужна стратегия тестирования?

  • Для организации процесса в условиях ограниченных ресурсов. Поэтому для начала неплохо бы осознать, какими ресурсами мы располагаем.
  • Для того, чтобы все участники проекта понимали роль тестирования, что оно может дать, какие профиты мы с этого получим. Чтобы у всех были равные ожидания и понимание, что вообще происходит в области контроля качества. А также для выявления возможных проблем, которые неизбежно станут очевидными в процессе обсуждения.

Кто составляет стратегию?

В первую очередь, конечно же, QA и обязательно менеджер проекта.

Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!

1. Какие типы тестирования будем применять на проекте и почему


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

Тестирование установки версии


В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.

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

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

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

Тестирование производительности


На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.
Дано Решение
Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей. Имеет смысл запланировать volume-тестирование с большими объёмами данных.
Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика. Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду.
Приложением пользуется несколько человек в неделю, объём данных минимален. Тестирования производительности не требуется.

Регрессионное тестирование


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

Интеграционное тестирование


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

Тестирование локализации


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

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

Кроссбраузерность и кроссплатформенность


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

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


Подобным образом необходимо разобрать все остальные типы тестирования:
  • Функциональное (проводим или нет),
  • Приёмочное (кто его проводит и каким образом),
  • UX/UI (каковы объективные критерии хорошего интерфейса)
  • Модульное и юнит (кто пишет контракт-тесты, кто пишет юнит-тесты и пишем ли их вообще),
  • Тестирование безопасности (кто гарантирует безопасность данных, и насколько система устойчива ко взлому),
  • Отказ и восстановление (как поведет себя система в экстренных обстоятельствах)

и другие.

2. Приоритеты в тестировании


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



В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).

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

3. Окружения для работы


Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.
Дано Решение
На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности. Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA).
Регулярно проводятся сессии бета-тестирования. Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение.

4. Работы тестировщика на проекте


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

Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.

Например, это могут быть:
  • оценка задач спринта на полноту и непротиворечивость,
  • оценка трудозатрат на тестирование,
  • подготовка чек-листов для тестирования (или тест-кейсов),
  • ревью сценариев автотестов,
  • написание функциональных автотестов,
  • непосредственно ручное тестирование,
  • деплой изменений на окружения,
  • актуализации стратегии тестирования и т.д.

5. Тестовая документация на проекте


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

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

6. Каким образом генерируются тестовые сценарии


Условия и сценарии эксплуатации зависят от конкретного решения, поэтому обязательно нужно обсудить:
  • какими техниками тест-дизайна имеет смысл пользоваться. В рамках этого пункта полезно составить список объектов, с которыми работает приложение, и их классы эквивалентности.
  • какие эвристики и банальный жизненный опыт помогают придумать сценарии тестирования для конкретного проекта. Для мобильных приложений удобно использовать стандартные эвристики, например, “I SLICED UP FUN”.

Дано Решение
На страховом проекте пользователь (агент) должен провести осмотр машины, в процессе которого необходимо сделать фотографии и загрузить их на сервер. Здравый смысл подсказывает, что в гаражах вряд ли есть wifi. А порой, там нет и мобильной связи. Значит, надо проверить приложение не только при работе с 3G, но и при отсутствии связи как таковой.
Любое действие пользователя в мобильном приложении авиакомпании — это часть некоего сценария. Например, нельзя выписать билет, не создав предварительно бронь. Поэтому логично использовать технику «сценарии использования».

7. Порядок работы с трекером


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

Проговорите с командой ключевые моменты:
  • Как мы будем отличать ошибки, найденные нами, от ошибок, найденными заказчиками (и надо ли нам их различать),
  • Как оформлять доработки,
  • Надо ли отличать доработки, которые мы придумали сами, от тех, которые попросил сделать заказчик. Каким образом?
  • В какой статус ставить ошибку, если она не повторилась,
  • Какой статус считать конечным.

Дано Решение
Тестировщик создаёт bug. Разработчик не может его воспроизвести, переводит в статус rejected. Тестировщик перепроверяет задачу и ставит статус Closed (конечный), если ошибка и правда ушла, либо уточняет описание и возвращает в New.
Заказчик ставит задачу на доработку. Разработчик понимает, что ему не хватает данных для реализации. Разработчик переводит задачу в статус Feedback.

(Подробнее о способах описывать баги и userstory мы писали в этой статье).

8. Критерии начала и окончания тестирования


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

На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.
Дано Решение
На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования. Считаем задачу проверенной, если мы прошли все пункты чек-листа.
На проекте ведется работа по спринтам. Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше.
На проекте составлен список функциональности по приоритетам. Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка.
На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом. Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5).

9. Инструменты для работы


Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.

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

Дано Решение
Для описания реализованной функциональности решили использовать mind-maps. Ребята в команде работают на разных платформах, поэтому нужно выбрать такой формат файла mind-map, с которым можно работать и в винде, и в линуксе, и на маке.
Мы договорились, что нам нужна автоматизация на проекте. Значит, нам нужны инструменты, которые позволят подготавливать тестовые данные (например, накатывать скрипты на БД), позволят осуществлять запуск в рамках конвейера (например, newman), позволят создавать заглушки (например, WireMock).

10. Оценка качества проекта и инструменты мониторинга


В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:

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

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

Заключение


Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.

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

Комментарии (9)


  1. izzmajjra
    30.10.2018 11:16

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

    Стратегия тестирования = тест-план в вашем подходе?

    Для того, чтобы все участники проекта понимали роль тестирования
    Многостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
    Эту задачу (в том числе и для руководства) лучше решает что-то типа тест-плана за 10 минут, одностраничного тест-плана
    Подробное перечисление видов тестирования с обоснованием того, зачем оно применяется не излишнее ли? Имхо, полезней описать что мы тестируем, а что не тестируем в нашем приложении (Например расписать из каких модулей/функционала состоит наше приложение и что из этого мы тестируем. Зачастую не функциональные требования остаются за скобками и тестирование говорит, что производительностью мы не занимаемся. Либо указываются ограничения для интеграций — например тестирование только на заглушках или эмуляторах)

    Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте

    Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.

    В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами)

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

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

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


    1. eastbanctech Автор
      30.10.2018 12:06

      Стратегия тестирования = тест-план в вашем подходе?

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


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

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


      Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.

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


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

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


      1. izzmajjra
        30.10.2018 14:27

        KPI мы используем не для того, чтобы отследить, работает или нет.

        Может не так выразился. В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
        Из интересного — вы предлагает в описывать в стратегии и правила/рекомендации/требования к тест-дизайну. Такого не практиковали, будет возможность можно опробовать. Как минимум один случай всплыл в памяти, когда это бы пригодилось команде.
        + тест-план или тестовая стратегия решает дополнительно еще одну задачу, для вас, может быть не актуальную — возможность ротации, безболезненной смены команды или замену людей в команде. Имхо, в том виде, что у вас документ эту задачу решит очень даже неплохо.


        1. eastbanctech Автор
          30.10.2018 14:36

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

          Полностью согласны. Мы написали про приотритеты тестирования во второй главе, кажется, это соотносится с вашим тезисом.


  1. NaCl
    31.10.2018 09:58
    +1

    Хорошая получилась памятка :) Выглядит действительно немного громоздко, но в реальности это все очевидно занимает меньше времени, и многие вещи наверняка делаются на автомате :)
    Интересно, в какой момент вы проводите этот процесс? Как соблюдается баланс между ранним планированием и получением как можно большего количества информации о внутренностях тестируемого продукта? Или фишка как раз в итеративности: прикинули план на раннем этапе, потом уточнили, когда обсудили архитектуру, подкорректировали по мере реализации?
    Для решения некоторых вопросов (инструменты, KPI), кажется, только менеджера и тестировщика мало. Как вы решаете этот вопрос: отправляете план на ревью всем заинтересованным и вносите поправки? Или сразу обсуждаете эти вопросы в расширенном составе?
    В пункте «Работы тестировщика на проекте» может ли менеджер влиять на состав команды? Например, в этом проекте у нас очень важный заказчик и нужно много автоматизации, поэтому возьмем тестировать Машу, потому что она хорошо пишет на Питоне, и Ваню, потому что у него нюх на всякую необъяснимую лажу. А в том проекте будет много рутины, с которой хорошо справляются Лена и Юра.
    Или этот пункт просто чтобы менеджер знал, чего от этой команды можно ждать, чего не стоит? Как-то в этом случае решается проблема «В команде никто не может, а надо»?


    1. eastbanctech Автор
      31.10.2018 12:23

      Дополним предыдущий ответ.


      Или фишка как раз в итеративности: прикинули план на раннем этапе, потом уточнили, когда обсудили архитектуру, подкорректировали по мере реализации?

      Да, вы совершенно правы, смысл в итеративности.


  1. pingywin
    31.10.2018 11:30
    +1

    Для решения некоторых вопросов (инструменты, KPI), кажется, только менеджера и тестировщика мало. Как вы решаете этот вопрос: отправляете план на ревью всем заинтересованным и вносите поправки? Или сразу обсуждаете эти вопросы в расширенном составе?

    Попробую ответить на этот вопрос с менеджерской колокольни.
    Будет сложно описать в комментариях как разрабатываются KPI и кто в этом участвует. Но попробую привести примеры.

    Есть Бизнесовый KPI, кратко можно сформулировать так «Объем продаж через нашу систему». Продажи растут, бизнес рад. Данный KPI разрабатывался вне стратегии тестирования с участием заинтересованных сторон проекта. В разработке идеологически и технически участвовали заказчик, руководство компании, проектная команда.

    Есть другие KPI, которые мы не обсуждаем с клиентами (считаем, что они априори с ними согласны). Например, мы выпускаем новый функционал. До выпуска мы знаем, что новой функцией должны пользоваться около 100 человек в день. При разработке мы закладываем нужные метрики и после выпуска настраиваем дашборд в Grafana на основе этих метрик, который отобразит нам сколько человек в сутки пользуется новой функцией. Такой дашборд нужен чтобы понять, что мы добились цели и получили тех 100 пользователей, а так же чтобы те кто участвовал в выпуске новой функции ощутили, что их работа не легла в стол. Сделал работу, увидел результат.

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

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

    В пункте «Работы тестировщика на проекте» может ли менеджер влиять на состав команды? Например, в этом проекте у нас очень важный заказчик и нужно много автоматизации, поэтому возьмем тестировать Машу, потому что она хорошо пишет на Питоне, и Ваню, потому что у него нюх на всякую необъяснимую лажу. А в том проекте будет много рутины, с которой хорошо справляются Лена и Юра.
    Или этот пункт просто чтобы менеджер знал, чего от этой команды можно ждать, чего не стоит? Как-то в этом случае решается проблема «В команде никто не может, а надо»


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


    1. NaCl
      31.10.2018 12:32

      А бывает такое, что уже в процессе разработки оказывается невозможным поддержать, например, планируемую нагрузку? У вас есть какие-то лайфхаки на этот случай?


      1. pingywin
        31.10.2018 13:00

        Лайфхаков, наверное, нет. Масштабируемость должна быть заложена в архитектуру приложения. Проблему нагрузки можно решить запустив приложение на нескольких серверах, но в таком случае появляется целый ворох проблем под названием «распределенная система». Здесь будет и балансировка и репликация данных и распределенные пользовательские сессии и распределенные транзакции (или без транзакций вообще) и многое другое. Все это должно быть заложено в приложение, либо это нужно реализовывать, коли возникла необходимость.
        Так же можно поставить более мощное железо и на какое-то время решить проблему. Но весь мир идет по первому пути :)