Запускаем серию материалов о тестировании продуктов в сфере iGaming – интерактивных азартных игр, в частности, мобильных приложений для ставок на спорт. Тестировать букмекерское приложение, не делая ставок? Легко – если понимать, что важно.
Ещё один крутой кейс, с которым мы недавно работали: разогнали регресс-тестирование и вернули доверие 2+ млн пользователей fashion-маркетплейсу!
Заказчик пришел с тем, что регресс превратился в бесконечный кошмар тестировщиков, релизы буксовали неделями, рейтинг приложения падал на глазах. А компания, один из топовых европейских fashion-маркетплейсов, теряла долю рынка.
С вами снова бизнес-аналитик, который умеет превращать хаос требований в работающие базы. На этот раз говорим про логическую модель данных. Ту самая, на которой обычно всё и начинает идти не по плану. Если вы уже сталкивались с таблицами, которые «вроде бы работают, но никто не понимает как», то вам сюда. Объясняем почти на пальцах и с примерами. Вы поймете, даже если все кажется сложным! Полезно аналитикам, архитекторам, всем, кто проектирует под что-то большее, чем «лишь бы завелось».
У бизнеса сегодня новая фобия – не просто «сбой», а сбой в самый неподходящий момент. Когда платежи не проходят в «Чёрную пятницу». Когда отчёт к инвесторам уходит в небытие из-за падения сервера. Когда человеческий фактор срывает срок по тендеру.
Простои становятся слишком дорогими, чтобы надеяться на авось. Поэтому в стратегию входят не только RPA и автоматизация, но и стресс-тесты – цифровой краш-тест инфраструктуры. Вместе они формируют то, что мы называем цифровым иммунитетом бизнеса – способность выдержать пиковые нагрузки, ошибки и сбои без потерь и паники.
В этой статье разберём, как связка стресс-тестов и роботизации даёт не только контроль над процессами, но и реальную отказоустойчивость. А значит, конкурентное преимущество в мире, где ошибки слишком дороги.
Сегодня вторник, а значит, мы с бизнес-аналитиком Юлией Чугуновой разбираем архитектуру данных – от бизнес-сущностей до связей в БД (базе данных). Учимся переводить требования в структуру таблиц, разбираем, как избежать «костылей» в базе и почему ошибки в данных дороже багов. И главное – учимся строить реляционные модели, которые не развалятся при масштабировании.
Эта статья – разбор Quality Gates: что это, как работают на каждом этапе жизненного цикла ПО и почему критически важны для стабильности, безопасности и спокойствия ИТ-команд. Мы детально рассмотрим 6 ключевых типов гейтов, их цели, конкретные инструменты для реализации, строгие критерии прохождения и ощутимые выгоды. Знания эти незаменимы для сисадминов и DevOps-инженеров, QA и руководителей тестирования, руководителей ИТ-подразделений.
Вам в руки попадает долгожданный документ с требованиями. Толще «Войны и мира». Хмм… Лучше поздно, чем никогда, конечно, но вообще-то сроки поджимают. И вроде круто, что требования на проекте есть, но… глаза разбегаются… Где тут главное? Что тестировать ПРЯМО СЕЙЧАС, чтобы не утонуть в регрессах и не подставить команду?
Первый шаг к адекватному тестированию – глубокий тест-анализ. Мы уже установили, что он определяет что и как тестировать, минимизируя необоснованные обвинения в адрес тестировщиков при появлении багов. Но анализ – это лишь карта. Следующий критический шаг – определение видов тестирования, которые наиболее эффективно «покроют» выявленные тестовые условия, риски и цели проекта. Выбор правильных видов тестирования – это не произвольное решение и не следование шаблону. Это стратегический вывод, напрямую вытекающий из результатов тест-анализа.
В первых трех статьях мы прошли большой путь: слушали заказчика сквозь «у меня что-то не так», собирали разрозненные мнения фасилитацией,
фиксировали требования в BRD, SRS и Backlog. В этой статье разберем:
User Story, Use Case и диаграммы.
В индустрии разработки ПО до сих пор частенько встречается опасное заблуждение: если баг обнаруживается на проде или на поздних стадиях разработки, это автоматически считается провалом тестировщика. «Пропустил баг!» звучит как приговор. Но это не особо верный подход, т.к. он искажает суть процесса контроля качества. Тестировщик не создает баги и не гарантирует их 100% обнаружение. Его задача — обеспечить адекватное тестирование на основе качественного тест-анализа. Именно тест-анализ является тем фундаментом, который определяет, насколько обоснованно и эффективно будет проведено тестирование, и почему найденный баг — это не ошибка тестировщика, а следствие системных факторов.
