TESTOREST

⚛️Нехватка времени на тестирование Данная тема заняла 2 место при ответе на вопрос: "С какими проблемами вы чаще всего сталкиваетесь в тестировании?" На первом: Частые изменения требований. Берем ту, на которую можем больше повлиять. Сегодня пробуем новый формат! Подготовила для вас небольшой разбор в виде короткого подкаста 🎧 В нем: Раскладываю по схеме возможные ситуации(схему прилагаю). И рассказываю как можно действовать там, где нужно. #подкаст @testorest

Вместо рубрики "поделать на выходных". Нужно же когда-то просто отдыхать и веселиться😁 Если все же чувствуете непреодолимую тягу к саморазвитию пользуйтесь постами с тегами: #саморазвитие #навыходных @testorest

⚛️ Мифы в Тестировании Перечислю часть мифов в сфере QA, которые хотелось бы расшифровать. С этими пунктами мы встречаемся по сей день. Поэтому, смахну пыль с фундаментальных основ, может и понимания к QA процессам станет больше. Есть вы никогда не встречали утверждения тезисов, описаных ниже - вам повезло 😁 1️⃣Тестирование находит все баги: самый распространенный миф. На самом деле, он противоречит принципу «Тестирование демонстрирует наличие дефектов, а не их отсутствие». Даже при тщательном тестировании часть багов не будет найдена. И это нормально, потому что цель тестирования не «найти ВСЕ баги», а помочь улучшить качество продукта до нужного, заказчику, уровня. 2️⃣Тестирование — это легко: многие до сих пор думают, что тестирование — это просто. Хотя оно требует аналитического мышления и знаний различных методик и инструментов, навыков работы с ОС и как минимум базовых знаний о сети. Добавьте к этому умение выстраивать процесс тестирования/выпуска версий, управление тестовыми стендами, умение читать логи(а иногда и код). Качественное тестирование требует не меньшего мастерства, чем разработка. Поэтому данную специализацию не зря выделили в отдельную. 3️⃣Только тестировщик несет ответственность за качество продукта: тестировщики играют важную роль в обеспечении качества, но ответственность лежит на всей команде, включая разработчиков, аналитиков и менеджеров. Так как в создании продукта принимают участие все, следовательно и влияние других этапов нельзя игнорировать. Многим знакома ситуация: разработка или аналитика задерживается для передачи работ на следующий этап, в итоге у тестирования остается меньше запланированного времени. Но, так как тестирование обычно в конце процесса - приходится за пару дней делать то, что хотели проверить за неделю)) Качество продукта в результате страдает. Как выжить в такой ситуации это уже другой вопрос, который мы, обычно, разбираем со студентами в конце курса. #мифы_тестирование @testorest

⚛️Поделать на выходных 🟢Пройти курс "Основы командной строки"

Этот курс подойдет всем, кто знакомится с *NIX-системами (Linux, MacOS) и хочет упростить работу с файлами и программами.

🟢Воспользоваться полезным чек-листом(приложен ниже): ✔️100 способов как изменить свою жизнь Уверена, что найдете что-то подходящее именно для вас ☺️ #саморазвитие #навыходных @testorest

⚛️Плюсы и минусы тестирования микросервисов Рассмотрим основные плюсы и минусы, которые следует учитывать при тестировании микросервисной архитектуры. Кстати, это частый вопрос на собеседованиях. ➕Плюсы: 1️⃣Модульность: Плюс: Микросервисы представляют собой независимые модули, что позволяет тестировать их изолированно. Это упрощает поиск и локализацию ошибок. Объяснение: Каждый сервис можно тестировать независимо от других, что упрощает процесс тестирования и уменьшает вероятность возникновения взаимозависимых проблем. 2️⃣Масштабируемость: Плюс: Тестирование микросервисов можно масштабировать по мере роста системы. Можно добавить новые тесты для новых сервисов без значительного изменения существующих тестов. Объяснение: Легкость в добавлении новых тестов для новых компонентов системы. 3️⃣Использование CI/CD: Плюс: Микросервисы легко интегрируются с CI/CD-пайплайнами, что позволяет автоматизировать тестирование и быстро получать обратную связь, если это необходимо. Объяснение: Автоматизация тестирования и быстрая доставка изменений. 4️⃣Гибкость в выборе технологий: Плюс: Разные микросервисы могут быть написаны на разных языках программирования и использовать различные технологии, что позволяет выбирать наиболее подходящие инструменты для тестирования каждого микросервиса. Объяснение: Возможность использования лучших инструментов и технологий для каждого конкретного случая. ➖Минусы: 1️⃣Сложность интеграционного и регрессионного тестирования: Минус: Интеграционное и регрессионное тестирование микросервисов может быть сложным из-за множества взаимосвязанных компонентов и необходимости эмулировать взаимодействие между ними. Объяснение: Трудности в установлении и поддержании тестовых сред, имитирующих реальные условия, оказание влияния на связанные компоненты. 2️⃣Сетевые задержки и проблемы с сетью: Минус: Тестирование микросервисов должно учитывать сетевые задержки и ошибки, что усложняет процесс тестирования. Объяснение: Необходимо учитывать сетевые проблемы, которые могут не проявляться в локальных тестах. 3️⃣Повышенные требования к инструментам и инфраструктуре: Минус: Необходимость использования сложных инструментов для оркестрации тестового окружения, таких как Docker и Kubernetes, что может требовать дополнительных знаний и ресурсов. Объяснение: Дополнительные затраты на обучение и поддержку инфраструктуры. #микросервисы @testorest

⚛️Поделать на выходных 🤪 🟢Пройти курс по БД YDB(Yandex DB) Некоторые уже переходят на YDB(Yandex DB) Вот небольшой бесплатный курс по теме. Мне очень помог при первом подключении к серверу, потому что там есть нюансы. А информации в интернете, так чтобы было понятно, очень мало. 🟢Воспользоваться полезными чек-листами(приложены ниже): ✔️Как учиться, когда ты взрослый ✔️30 дней достижения цели @testorest

⚛️Частые проблемы в тестировании 1. Частые изменения требований Описание: Частые изменения требований могут создавать хаос в процессе тестирования. Когда требования постоянно меняются, приходится проводить очередной ретест и менять тест-кейсы. А это дополнительное время и возможные баги. 2. Нехватка времени на тестирование Описание: Сжатые сроки и давление со стороны бизнеса часто приводят к сокращению времени, отведенного на тестирование, что сказывается на качестве продукта. 3. Недостаток коммуникации и сотрудничества Описание: Плохая коммуникация внутри команды (между разработчиками, тестировщиками, аналитиками, менеджерами) может привести к решению не приоритетных задач, и, как следствие, выпуску очередной версии с ненужными заказчику фичами(потому что ждал он, скорее всего, другие)). 4. Технические долги Описание: Накопленные из-за временных ограничений технические долги могут замедлить процесс тестирования и сделать его менее эффективным. Если баги не править, качество ПО не вырастет. Но важно править нужные баги. Все остальные могут подождать)) 5. Отсутствие тестовых данных Описание: Недостаток или неполные тестовые данные могут затруднить обеспечение нужного уровня качества, т.к. Вы не сможете проверить часть важного функционала. 6. Ограниченные ресурсы и бюджет Описание: Недостаток ресурсов, таких как тестовые среды, инструменты и персонал, может ограничивать возможности тестирования. 7. Проблемы с интеграцией Описание: Интеграция всегда является одним из тонких мест в приложениях - в этой части всегда есть баги). Кроме того, бывает непросто проверить интеграцию, если система, с которой осуществляется обмен, недоступна. @testorest

⚛️Как составить необходимый и достаточный набор тест-кейсов? Создание оптимального набора тест-кейсов — это баланс между полнотой покрытия и экономией ресурсов. Но в любом случае вам нужно будет пройти следующие стадии: 1️⃣Анализ требований: 🔸Начните с тщательного изучения требований и спецификаций. 🔸Определите ключевые функциональные и нефункциональные требования. 2️⃣Идентификация тестируемых областей: 🔸Разделите приложение на логические модули и компоненты. 🔸Выделите критические сценарии. 3️⃣Применение техник тестирования: 🔸Примените классы эквивалентности и анализ граничных значений. 🔸Используйте метод попарного тестирования для сокращения числа тестов. 🔸Если уместно, используйте и другие техники тестирования(метод состояний и переходов, таблица решений). 4️⃣Позитивные и негативные тест-кейсы: 🔸Проверьте, что присутствуют тест-кейсы для негативных и позитивных сценариев. 5️⃣Приоритизация тест-кейсов: 🔸Определите критические тест-кейсы, которые необходимо выполнить в первую очередь. 🔸Учтите риски и возможные последствия неработающего функционала. P.S. И помните, именно тестировщики обладают секретным знанием сколько и какие тест-кейсы нужно выполнить 😉 По крайне мере , в идеале. Дальше уже идет торг со временем. #тест_кейс @testorest

⚛️Как составить необходимый и достаточный набор тест-кейсов? Создание оптимального набора тест-кейсов — это баланс между полнотой покрытия и экономией ресурсов. Но в любом случае вам нужно будет пройти следующие стадии: 1️⃣Анализ требований: ▫️Начните с тщательного изучения требований и спецификаций. ▫️Определите ключевые функциональные и нефункциональные требования. 2️⃣Идентификация тестируемых областей: ▫️Разделите приложение на логические модули и компоненты. ▫️Выделите критические сценарии. 3️⃣Применение техник тестирования: ▫️Примените классы эквивалентности и анализ граничных значений. ▫️Используйте метод попарного тестирования для сокращения числа тестов. ▫️Если уместно, используйте и другие техники тестирования(метод состояний и переходов, таблица решений) 4️⃣Позитивные и негативные тест-кейсы: ▫️Проверьте, что присутствуют тест-кейсы для негативных и позитивных сценариев 5️⃣Приоритизация тест-кейсов: ▫️Определите критические тест-кейсы, которые необходимо выполнить в первую очередь. ▫️Учтите риски и возможные последствия неработающего функционала.