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