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

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

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

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

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

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

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


    Это контракт между менеджером и тестировщиком. Таким образом мы формируем правильные ожидания у обоих. Менеджер не выбирает с кем он будет работать, у нас нет такой роскоши. Мы стараемся поддерживать компетенцию всех специалистов на уровне. Если кто-то что-то не умеет, то научим и подтянем.
  • Обзор самых интересных докладов Joker 2018: версия EastBanc Technologies
    +1
    Кирилл,
    Я бы сказал, что доклад Spring vs Micronaut в основном доносил мысль о том что в реальных приложениях время запуска в основном зависит от подключенных интеграцией(mongo/cloud/rabbitmq/etc) и это нивелирует особенности базовых реализаций core фреймворка. Ну и конечно ещё одна мысль, не нужно бежать мигрировать на микронавт). В любом случае надеюсь было полезно :)

    Было точно полезно! Мыслей и смыслов в докладе было много, думаю, что все поняли и восприняли что-то своё :)
    К слову, релиз Micronaut случился сразу после Joker — github.com/micronaut-projects/micronaut-core/releases/tag/v1.0.0
    Планируем попробовать его в деле.

    Для погружения в тему особенностей работы реактивного кода советую ознакомиться с докладом — youtu.be/tjp8pTOyiWg

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

    Сейчас для нас стоит обычная проблема, нам нужно мигрировать на Spring 5, чтобы хотя бы иметь возможность что-то попробовать на бою. Процесс миграции не детерминированный и не ясно, что может пойти не так, поэтому он вызывает определенный страх.
    Так же миграция на Spring 5 тянет за собой обновление почти всех зависимостей в проекте…
  • Как мы пишем статьи на Хабр: опыт разработчиков EastBanc Technologies
    +1
    Мне кажется статья немного шире, чем вы описываете. Она касается не столько «как написать статью, чтобы было много плюсов и просмотров», а касается мотивации, того что компания хотела бы донести и как разработчикам начать писать.
    «Выбрать какую-нибудь животрепещущую тему» это здорово, но как из повседневных задач сделать такую животрепещущую тему? А о повседневных задачах нужно писать, чтобы все знали, что не в бирюлки играем, а реальные дела делаем :)

    А вообще хороший челлендж, написать статью с большим количеством просмотров и лайков, надо попробовать поставить именно такую цель :)