и посмотреть медиа
TestGrow - software testing
и посмотреть медиа
Channel of the software testing platform. Materials for testers.
Channel of the software testing platform. Materials for testers.
AI bot for text-to-speech and voice cloning in Telegram. Create audio using neural network quickly and easily.
Resource of the TestGrow platform for software testing. Useful materials and tips for QA specialists.
ПРОБЛЕМА КРИВЫХ ДАННЫХ: КОГДА САМА ТЕСТОВАЯ БД ЛОМАЕТ ТЕСТИРОВАНИЕ Всем привет! Сегодня хочу поднять тему, с которой я регулярно сталкиваюсь в рамках моего проекта по практике для тестировщиков Store Manager. Речь про кривые данные и неконсистентость в тестовых базах. Что это значит? Кривые данные - это записи в БД, которые не соответствуют текущей бизнес-логике или нарушают валидацию. Они могли попасть туда случайно, из старых тестов или при тестировании валидации, но итог один: тестирование ломается и возникают ошибки. Например, - В таблице пользователей сохранены email без «@», и после обновления валидации логин перестаёт работать. - В заказах у части записей отсутствует обязательное поле валюта, в итоге UI падает, когда пытается отрендерить сумму, а получает, например, 500 ошибку от бекенда. - В связке заказ–товар в БД есть ссылки на несуществующие товары и на фронте ничего не отображается. и так далее, ситуаций может быть много. Почему это ломает тестирование? Тестировщик находит баг, который как ему кажется связан с системой, а на самом деле, просто данные некорректны в БД, например, в прошлом релизе тестировщик проверял валидацию полей, завел кучу неправильных данных для негативных тестов, они сохранились в БД, а на новом релизе, где валидацию пофиксили, система начинает отбраковывать старые записи, но выглядит это как будто система сломалась. И главное, на такие ошибки тратится время на их расследование и локализацию, которые на самом деле не баги кода, а мусор в данных. Что я тут советую делать: 1. Всегда проверять, с какими данными работаете (соответствуют ли они правилам валидации). 2. Всегда проверять дефекты относительно корректности тестовых данных 3. Для воспроизведения багов лучше создавать свежие тестовые данные, а не полагаться на старые. Часто проблема кривых данных сложнее, чем сам баг в коде. Потому что она искажает картину. Тестировщик ищет ошибку там, где её нет. В моём проекте я регулярно вижу, как это сбивает новичков, потому что кто-то проверяет новый сценарий, а система не работает просто потому, что старые данные не проходят обновлённую валидацию. Поэтому никогда не забываем, что тестовые данные - это не просто то, что вам нужно для прохождения тестов, это еще и сущность, которую нужно регулярно валидировать и проверять перед тестированием. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний
Открыть канал и посмотреть медиаOnly registered users can share their opinion.
Be the first to share your impression of this resource!