🎨🎨🎨🎨🎨🎨

Мы хотим поделиться результатом работы Кати и Ивана с вами и поэтому разыгрываем один экземпляр книги «Эффективный Node.js».

Условия простые:

🟢Проверить подписку на канал
🟢Нажать кнопку «Участвовать»

Победителей определим 23 апреля в 15:00 по московскому времени.

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

Удачи! ✌️

🔥Как пройти путь от мобильного разработчика до CTO?

Наш CTO Андрей Хышов поделился своим опытом и карьерным треком в новом выпуске подкаста «Быть CTO».

Обсудили:
🟢как быстро адаптироваться в новой роли и разобраться в неизвестном
🟢культуру ownership и то, как она устроена в Купере
🟢как меняется мышление с ростом ответственности
🟢зачем CTO выходить «в поля» и лично развозить заказы

Смотрите выпуск:
YouTube
VK Видео

🥳 Подводим итоги розыгрыша книги «Эффективный Node.js»

✨Победителем становится @alt_swan✨

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

И спасибо всем, кто поучаствовал — было приятно видеть вашу активность!

🪑Садитесь в удобное кресло.

🎧 Надевайте наушники.

☕️ Заваривайте горячий чай 🍫 с чем-нибудь вкусным.

И включайте новый выпуск ProductCamp Podcast с нашим директором по продукту Еленой Тихоновой.

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

Слушать тут 🏃
Mave
Яндекс.Музыка
Apple Podcast
YouTube Аудио

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

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

В мини-интервью Арсений Лагутин, руководитель обеспечения качества тестирования, рассказал, как в большом e-commerce-продукте подходят к QA:

👉 Проверяете ли вы отдельные сервисы изолированно или чаще тестируете пользовательский путь целиком?

Основной объем нашей системы представляют собой микросервисы. Подход и уровни тестов зависят от задачи, модулей системы, которые она затрагивает или влиянию на пользовательский путь. Новую реализованную фичу в ветке стараемся проверять на изолированном окружении для сохранения гигиены master. Здесь же запускаем изолированные функциональные и интеграционные автотесты. Далее, при необходимости, проводится ручное интеграционное тестирование и Е2Е, а также приемочное на production или stage окружениях.

👉 Какие инструменты и подходы используете для автоматизации тестирования?

Тут у нас «сборная солянка». Для автоматизации используем Golang, Python, JS (Detox) и TS (Playwright). Определяем уровни автоматизации под потребности системы и команды, а зону ответственности делим между QA и разработчиком. Автоматизируем в рамках своей предметной области и стараемся запускать прогоны на каждое новое изменение сервиса. Автоматизацией занимается QA в продуктовой команде, а не отдельный департамент. За счет глубокого знания тестируемой области повышаем эффективность автотестов и стараемся привлекать разработку для разбора упавших автотестов в рамках создаваемых ими изменений.

👉 Как вы понимаете, что система готова к высоким нагрузкам и «переживёт» сезонный пик?

Ориентируемся на цели бизнеса прежде всего. Основным фактором для нас является ожидаемое число заказов. В компании имеется инструменты для проведения нагрузочного тестирования как на stage, так и на production окружениях изолированно для сервисов и Е2Е (в связке) на отдельных тестовых сущностях. Нагрузочное тестирование проводим на регулярной основе и в рамках валидации крупных изменений. Успехом является соответствие ожидаемой выдерживаемой нагрузки относительно бизнес-целей и реальной, полученной на production-окружении. В случае отклонений анализируем, проводим оптимизации и повторяем, пока всё не будет хорошо работать.

👉 Насколько QA вовлечён в продуктовые решения?

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