Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту, их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.
Профессия тестировщика для многих служит "входным билетом" в IT. На что же может надеяться начинающий специалист?
Случилось чудо! Спустя сотни откликов вас позвали на первое собеседование на роль тестировщика. Что делать? Не паниковать — тревога и беспокойство ещё никому не помогли, скорее наоборот. Лучше порадуйтесь: скрининг резюме уже пройден, и это отлично — значит, вами уже заинтересовались! И помните, что вы идёте не на экзамен, где вас хотят «завалить», а на встречу к будущим коллегам.
На связи код-ревьюер на курсе «Инженер по тестированию», ментор тестировщиков в Мастерской программирования и руководитель соревновательных видов IT-практики в Яндекс Практикуме Кристина Пауэр, и я помогу вам подготовиться к первому собеседованию в IT.
Локатор — обязательный элемент любого автотеста, который позволяет системе находить правильный путь к тестируемому компоненту интерфейса. От точности локатора и корректности его оформления зависит не только, смогут ли разобраться с локатором тестировщики и другие коллеги, но и сможет ли в целом автотест безошибочно найти искомый компонент среди множества на странице для выполнения целевой проверки.
Меня зовут Елена Пранова. Я инженер по автоматизации тестирования в ОК. В этой статье я хочу рассказать о том, как мы работаем с локаторами для автотестов: каких принципов придерживаемся, чего стараемся избегать и какие правила выработали на своем опыте.
Инструменты для тестирования методом «чёрного ящика» сосредоточены на анализе входных и выходных данных программного обеспечения, его поведения и функциональности с точки зрения конечного пользователя. Они используются для различных типов тестирования, включая функциональное, системное и приёмочное, не требуя доступа к исходному коду.
Преимущества этих инструментов заключаются в их способности обеспечить объективную оценку внешних функций программного обеспечения. Они помогают убедиться в том, что разрабатываемый софт соответствует требованиям пользователей и ведёт себя ожидаемым образом в реальных ситуациях. Эти инструменты особенно полезны для выявления несоответствий в функциональности и интерфейсе программы, что делает их идеальными для тестировщиков без глубоких технических знаний о внутреннем устройстве софта. Такой подход способствует ориентированности на пользователя. В этой статье представлен обзор 13 инструментов для тестирования методом чёрного ящика.
До конференции по тестированию Heisenbug всего ничего, её программа уже известна, и пришло время рассказать о ней Хабру.
Каждый раз в Heisenbug есть и то, за что его знают и любят, и новое.
Что уже знакомо? Снова будут привычные тематические блоки: «инструменты и фреймворки», «мобильное тестирование», «нагрузочное» и так далее. Снова будут некоторые спикеры, полюбившиеся многим по предыдущим Heisenbug: Артём Ерошенко (поговорит о том, умерло ли тестирование), Дмитрий Тучс (продолжение темы JUnit extensions), Константин Волков (всегда что-то интересное про Flipper Zero). Снова будет формат «хоть приходите на конференцию ногами, хоть смотрите в онлайне».
А что будет нового? Конкретные темы докладов — они-то всегда свежие. И рассказываем Хабру, какие именно в этот раз:
Я большой поклонник автоматизированных тестов и достаточно дисциплинированный их автор. Проектирование ПО крайне сложно реализовать функционально корректно и ещё сложнее избежать регрессии в дальнейшем. Как сказал Майкл Фезерс, «легаси-код — это весь код, у которого нет тестов».
Некоторые вещи, например, конечные точки серверов, схемы баз данных и компоненты библиотек UI тестировать очень просто.
Другие вещи тестировать сложнее, например, конечные точки, вызывающие сторонние API, веб-страницы на React со сложными состояниями и асинхронные задачи, требующие детализированных записей баз данных. Airbnb мне было сложно тестировать письма со сбросом паролей, потому что отправка электронной почты выполнялась через аутсорсный сервис.
Но такая функциональность всё равно заслуживает тестов, и на то есть две причины. Во-первых, всё равно важно, чтобы она не регрессировала, из-за их сложности вероятность регрессии велика. Во-вторых, тестирование сложных фич часто заставляет инженеров проектировать фичу таким образом, чтобы её можно было тестировать. Если вводить тесты ещё на ранних этапах разработки, это может мотивировать к проектированию более узких интерфейсов и снижению связанности, а значит, в долговременной перспективе приводит к повышению качества кодовой базы.
Всем привет!
Сегодня хочу поделиться своим опытом сдачи ISTQB, особенностями проведения экзамена и советами для успешной подготовки.
Если вы читаете эту статью, то, вероятнее всего, вы уже знаете, что обозначают эти загадочные буквы «ISTQB», зачем вообще сдавать какой-то экзамен и почему к нему надо плотно готовиться.
Тем не менее для тех, кто забрёл сюда случайно или вчера в первый раз мельком услышал что-то об ISTQB и решил погуглить, я объясню:
WordPress - самый популярный CMS для создания сайтов. Поэтому появление уязвимостей в различных плагинах затрагивает множество пользователей по всему миру. Усугубляет общую картину и тот факт, что во многих плагинах отсутствует автоматическое обновление версий. Не исключением стал и плагин LayerSlider в котором была найдена уязвимость типа SQL-injection, получившая идентификатор CVE-2024-2879 и балл CVSS равный 9,8 (критический).
Давайте вместе с вами более детально рассмотрим данную уязвимость в нашей статье и покажем ее эксплуатацию.
Важно не забывать про безопасность при разработке. По мере усложнения сценариев и архитектуры в онлайн и екоммерс сервисах риск возникновения ошибок возрастает. Поэтому мы обучаем разработчиков основам безопасности в вебе и регулярно проводим стороннее пенетрационное тестирование перед запуском.
В этом материале расскажем о безопасности на примере мультиязычного e-commerce сервиса – интернет-магазина с аккаунтом покупателя. Проект построен на NextJS, где часть бекенда на JS и пишется фронтендерами. Поэтому помнить о безопасности в таком случае приходится более старательно, держа в уме случаи, о которых расскажем в этой статье.
Растут или снижаются зарплаты в тестировании? Какие скилы наиболее востребованы? Сколько вакансий для джунов? Узнали у экспертов, как изменился рынок в 2023 году и какие тренды сохраняются в 2024.
Всем привет!
Сегодня мы хотим вам рассказать о нашем продукте «Структура API» и последних изменениях в нём. Данный продукт позволяет решить одну из важнейших задач в управлении API – это получение актуальной и полной структуры API на основании реального трафика. Результат представляется в привычном swagger виде. На рисунке 1 представлен общий вид пользовательского интерфейса.
Привет, Хабр. Сегодня мы посмотрим на достаточно тривиальную тему с совсем нетривиальной стороны. Пожалуй, для каждого вебера HTML-инъекции являются темой, которой зачастую уделяют не очень много внимания. Взять даже собеседования: когда в последний раз вас спрашивали не об XSS'ках, а об HTML-инъекциях?
Сегодня я попробую рассказать про большую часть интересных векторов, которые мы можем использовать при ограничении в применении JS. Не стесняйтесь пользоваться оглавлением, потому что статья подготовлена для разного уровня читателей. Чтобы не обделять новичков, я достаточно подробно описал работу HTML, ее структуры и даже то, как HTML парсится браузером!
Тестирование баз данных включает в себя тестирование методом «чёрного ящика», «белого ящика» и набор требований ACID — атомарность, согласованность, изоляция и устойчивость. В этом руководстве я объясню все необходимые определения, расскажу, как оно проводится, и приведу примеры.
Автор: Роман Горбунов, руководитель QA-проектов в «Точка качества».
Тестирование — неотъемлемая часть разработки, так как оно обеспечивает надёжность, качество и функциональность программного обеспечения. Однако, чтобы действительно быть эффективным, тестирование должно быть систематическим, планируемым и охватывать все аспекты разрабатываемого бизнес-продукта. Важным аспектом тестирования является уровень тестового покрытия, который определяет, насколько хорошо тесты охватывают функциональность и код ПО.
В этой статье мы остановимся на определении тестового покрытия, рассмотрим важность для проверки качества бизнес-продукта и определим критерии его выбора.
Что такое тестовое покрытие
Тестовое покрытие — это метрика, которая показывает плотность покрытия тестами кода или требований. Если требования отсутствуют, то тестовое покрытие может отражать степень покрытия логической структуры приложения. Тестовое покрытие можно представить в виде сочетания глубины и ширины тестирования.
Ширина тестирования отражает какая функциональность затрагивалась тестированием (модули/функции).
Глубина тестирования отражает вид проверок, которые производились для модуля/функции (например, позитивность/негативность сценариев).
Уровни тестового покрытия по ширине:
Цель нашего обсуждения сегодня - разобрать процесс проведения тестирования проекта. Мы затронем следующие темы:
• Классический подход к тестированию
• Анализ успехов и неудач в ходе тестирования
• Проблема уменьшения покрытия(эрозии) тестирования
• Управление инцидентами в процессе тестирования
• Управление финальной игрой
Данная статья предлагает практические рекомендации по написанию интеграционных тестов, демонстрируя, как сосредоточиться на спецификациях взаимодействия с внешними сервисами, делая тесты более читаемыми и легкими для поддержки. Представленный подход не только повышает эффективность тестирования, но и способствует лучшему пониманию интеграционных процессов в приложении. Через призму конкретных примеров будут исследованы различные стратегии и инструменты - DSL-обертки, JsonAssert и Pact, предлагая читателю комплексное руководство по улучшению качества и наглядности интеграционных тестов.
Статья представляет примеры интеграционных тестов, выполненных с использованием Spock Framework на языке Groovy для тестирования HTTP-взаимодействий в Spring-приложениях. В то же время, основные методики и подходы, предложенные в ней, могут быть эффективно применены к различным типам взаимодействий за пределами HTTP.
Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA.
Важно подсветить, что под багом подразумевается отличие ожидаемого результата от фактического. Мы ожидали, что при нажатии кнопки А будет окно В, но происходит совершенно другое. На схеме выше отображаются риски не только появления бага, но и не предусмотренных ошибок в виде программа не делает лучше, а только затрудняет использование.
Первый риск: Идея попадает к аналитику
Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде.
Второй риск: разработка по тех. требованиям
Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.
Команда Яндекс Практикума изучила требования работодателей к инженерам по автоматизации тестирования. Рассказываем о том, что чаще используют для автоматизации — Java или Python, есть ли разделение внутри профессии на тех, кто пишет автотесты только на бэк или только на UI, и о других наблюдениях.
