Автор:

Javascript – прекрасный язык программирования: он легок, быстр, и располагает ресурсами для решения практически любых приходящих в голову вопросов. Он профессионально управляется с бэкендом через Node.js. Однако если в вашем javascript-коде попался баг, дебаг может сильно выматывать и раздражать, а иногда это глупые, легко предотвратимые баги.

TypeScript пользуется всеми преимуществами JavaScript и NodeJS и усиливает их – он поможет писать код, который легче читать и проще поддерживать. У него статическая типизация, классы, интерфейсы, типы, декораторы и поддержка IDE в режиме реального времени вроде Visual Studio Code.

Работа тестировщика состоит из множества различных задач, но самые важные — это обнаружение и описание багов. Однако сам процесс выявления ошибки — лишь половина дела. Настоящая ценность для команды разработки заключается в грамотном документировании найденного бага, а именно — в создании баг-репорта.

Написание баг-репорта может показаться простой задачей, однако чтобы он действительно был полезным и помогал разработчикам быстро разобраться в проблеме, важно учесть множество нюансов. Хорошо составленный баг-репорт не только описывает саму ошибку, но и содержит всю необходимую информацию для её воспроизведения, анализа и последующего исправления. Этот навык требует определённых знаний, внимания к деталям и опыта.

Автор:

Все больше компаний обзаводится собственными мобильными приложениями, и многие экс-веб-тестировщики переходят в мобильное тестирование. Совершая этот переход, тестировщики иногда полностью игнорируют вроде бы мелкие проблемы вроде нестабильного интернета при использовании мобильного приложения пользователями (ниже я буду называть это «путем потребителя»).

Знаете ли вы, как ваше приложение справляется с ошибками или проблемами задержек, вызванными нестабильным соединением с Интернетом?

Тестирование мобильных приложений – это, в частности, отдельный, приобретаемый навык. В создании наилучшего пользовательского опыта для клиентов ваших мобильных приложений множество нюансов, но я хочу поговорить об этом, зачастую игнорируемом аспекте. В этой статье тестировщики получат представление о том, как эти проблемы влияют на качество, и как оценить это влияние.

Вы когда‑нибудь оказывались в неловком положении на собеседовании, когда вас спрашивают: «Может, у вас есть к нам вопросы?» Это момент, которому не учат в университетах или на курсах по тестированию, но он может стать критической развилкой на вашем профессиональном пути. Если вы только пробиваете себе дорогу в мире IT и это ваше второе или третье собеседование, то умение задать правильные вопросы может стать вашим личным компасом в определении, находитесь ли вы на пороге мечты или очередной галеры? На просторах Хабра можно найти множество статей на подобные темы, большая их часть сосредоточена на обсуждении таких аспектов, как зарплаты, отпуска, бонусы и так далее.

Меня зовут Влад Бубнов (@vladbubnov), я работаю в VK на позиции QA Engineer. Хочу поделиться своим топом вопросов для собеседования на позицию тестировщика, которые я собрал благодаря прохождению не одного десятка собеседований. Они помогут вам понять, с какой компанией вам предстоит иметь дело.

Автор:

Введение

Недавно я отметил двадцатилетие своей карьеры тестировщика. Почти десять лет я изучаю цифровую доступность и разработку приложений, сайтов и продуктов для максимально широкой аудитории. Я решил писать, говорить и даже преподавать доступность окружающим, так как, начав работать с доступностью, я обнаружил, что мало кто обучает ей.

Теперь, когда ИИ-инструменты широко распространяются, начинают появляться и инструменты тестирования доступности на основе ИИ.

Как правило, они делятся на три категории:

• Инструменты оценки: подсвечивают все, что кажется им проблемой.
• Инструменты оценки и рекомендаций: подсвечивают найденные проблемы и предлагают способы подхода к ним или их исправления.
• Инструменты оценки и исправления: напрямую применяют исправления к тестируемому коду на основании своих находок.

Эти инструменты, особенно те, которые просто правят все за вас, выглядят прекрасной идеей! Но решат ли они все проблемы? К сожалению, нет. Помогут ли они? Да, в правильных условиях и в разумном масштабе.

В этой статье я рассмотрю уже существующие инструменты. Я изучу, что они предлагают, особенно по отношению к планируемым обновлениям методических указаний по доступности веб-содержимого (WCAG). Я пройдусь по плюсам и минусам применения искусственного интеллекта в оценке и тестировании доступности.

Оригинальная публикация

Всем привет! Меня зовут Ксения Лопатина. В предыдущей статье я рассказывала вам о своем подходе к построению карты компетенций для команды тестирования. Там я описала зачем нужна карта компетенций, как можно подойти к ее построению и как провести оценку.

Сегодня я хочу рассказать о том, что же делать дальше, после того, как вы провели оценку. Вы узнаете, что такое ИПРы и как создавать их на базе карты компетенции, как правильно ставить задачи и нужно ли контролировать их исполнение. Также покажу вам наиболее оптимальный формат, который я выработала путем проб и ошибок. Статья будет полезна и тем, кто уже выбрал подход работы с ИПР и тем, кто только в начале данного пути. Также будет полезно если вы составляете ИПР себе самостоятельно или делаете их для ваших сотрудников.

Автор:

Сейчас, как никогда, критически важно убедиться, что ваше приложение полностью совместимо с широким спектром ПО (операционных систем и браузеров) и железа (брендов и устройств).

К счастью, у разработчиков и тестировщиков есть под рукой разнообразные инструменты тестирования совместимости. Ниже – ряд инструментов, которыми пользуюсь я.

Привет! Я — Маша, которая заваривает qaшу (и иногда крепкий кофе, когда глаза уже отказываются фокусироваться на экране).

Сегодня хочу поговорить о проблеме, с которой сталкивался, наверное, каждый тестировщик (и не только). В один «прекрасный» день ты садишься проверять фичу или делать регресс, а баги просто перестают быть видны. Ты кликаешь, прогоняешь сценарии, но будто слепнешь — всё кажется рабочим. А потом оказывается, что пропустил очевидный косяк, и по цепочке начинается: чувство вины → стресс → ещё большая усталость → ещё больше ошибок.

Знакомо? Тогда давайте разберёмся, как выбраться из этой ямы, пока она не превратилась в профессиональное выгорание.

Автор:

Ловкость рук и никакого обмана: что такое Гейзенбаг?

Сталкивались ли вы с дефектом, который, казалось бы, отрицает логику и увиливает от всех попыток его воспроизвести?

Если ваш ответ «Да», то уверяю, вы не одиноки.

Такие дефекты часто всплывают при вроде бы случайном наборе условий – то есть у нас нет надежного способа выявить необходимые для воспроизведения шаги. Зачастую единственная информация, которой мы располагаем – это невнятное описание вроде «Я столкнулся с этим, следуя определенному процессу, но с тех пор проблем не было».

Из-за этого такие проблемы часто называют «невоспроизводимыми дефектами» или, как я недавно узнал, «Гейзенбагами». Одна из основных характеристик Гейзенбагов заключается в том, что любая попытка понаблюдать за ним или подебажить может потенциально изменить поведение кода приложения. Вы просто хотите понаблюдать за проблемой – и непреднамеренно меняете условия ее воспроизведения. Мы об этом еще поговорим.

Всем привет! Меня зовут Николай, я ведущий инженер по производительности в Т-Банке, более 15 лет работаю с различными утилитами НТ для нагрузочного тестирования. Мы с командой выстраиваем процессы проведения тестов производительности.

Раньше наша команда помогала разрабатывать скрипты НТ и проводить анализ результатов их выполнения. Но поддерживать высокий уровень сервиса и постоянную доступность силами небольшой команды невозможно. Полтора года назад мы решили передать разработку скриптов в команды разработки продуктов.

Как и все молодые специалисты, команды начали из раза в раз допускать ошибки. Спустя 1,5 года я собрал наиболее популярные и хочу поделиться ими. Начинающим специалистам это поможет понять, как лучше выстраивать процесс, и значительно сократить время на разработку и внедрение НТ.

Автор:

В динамическом мире разработки ПО очень важна способность эффективно масштабировать и оптимизировать процессы. Работая над улучшением инфраструктуры нашей автоматизации в Glassbox, мы пришли к применению возможностей DevOps, Groovy, скриптов DSL и AWS EC2 Jenkins-агентов. Эта комбинация позволила создать масштабируемую и устойчивую систему, способную на запуск более чем 1000 задач в день, что дает нам высокую производительность и надежность.

Оригинальная публикация

Всем привет! Меня зовут Ксения Лопатина, я вот уже почти 9 лет в тестировании. Не так давно поймала себя на мысли, что мой аккаунт на Хабре совсем запылился. А ведь за годы работы у меня было достаточно много опыта на различных позициях от ручного тестировщика до руководителя и мне действительно есть чем поделиться. Так и пришла в мою голову мысль поднять в очередной раз тему развития в тестировании. Мне кажется, что эта тема будет актуальна всегда. Эта статья будет первой, в планах у меня уложиться в три, но там уж как пойдет. 

В этой статье я хочу поделиться своим опытом построения карты компетенций для команды тестирования. В первую очередь будет полезно тем, кто еще не сталкивался с картами компетенций и пока не знает как к ним подступиться. Также будет полезно, если у вас уже есть набор компетенций, но нет понимания как это структурировать и разложить по полочкам. 

Я годами живу двойной жизнью. Днем я работаю тестировщиком. Я пишу тест-автоматизацию, хожу на встречи, занимаюсь исследовательским тестированием, делаю заметки и работаю на грани своих возможностей. Но наступает вечер, и просыпается мафия – я становлюсь разработчиком, делающим свой личный сайт, создающим и улучшающим приложения, сражающимся с упаковщиками, фреймворками, CSS, базами данных и API.

Мое присутствие в обоих мирах заставило меня задуматься о жизни разработчиков и тестировщиков. Я видел достаточно компаний, построивших довольно высокий забор между этими ролями. Тестировщики и разработчики сидят не рядом, не разговаривают и, что еще хуже, не понимают друг друга. Они живут своей жизнью в отдельных помещениях, зданиях или даже компаниях.

Тестировщики и разработчики отличаются по навыкам, но цели у них общие (по крайней мере, должны такими быть). Я считаю, что тестирование и разработка – две стороны одной медали. Когда разработчик запускает веб-приложение в браузере, он перестает быть разработчиком? Когда тестировщик проектирует автоматизированный скрипт, он больше не тестировщик?

Конечно, нет.

Автор: Игорь Авдонин

С момента своего появления и по сей день подход Test-Driven Development (TDD) вызывает оживленные дискуссии в сообществе разработчиков, и до сих пор нет единого мнения о ее эффективности.

Но что будет, если совместить TDD и AI-генерацию кода? В статье я покажу:

• Как соединить TDD и AI;

• Как AI-driven TDD улучшает процесс разработки;

• Как TDD влияет на качество сгенерированного AI кода.

А кроме того, попытаюсь немного поразмышлять относительно того, как будет развиваться область взаимодействия человека и AI в кодогенерации в ближайшие годы.

Кратко о TDD

Разработка через тестирование (Test-Driven Development, TDD) — это методология программирования, при которой тесты пишутся до написания кода. Процесс строится на коротких итерациях: сначала создается тест, затем реализуется минимальный код для его прохождения, после чего код рефакторится. Утверждается, что такой подход помогает создавать надежное и поддерживаемое программное обеспечение, снижая вероятность ошибок и улучшая архитектуру кода.

Автор:

Тестирование с Apache Kafka – критически важная практика, позволяющая гарантировать надежность потоковой передачи данных и обработки событий в приложениях, созданных на платформе Apache Kafka. Оно включает в себя спектр тест-техник, включая юнит-тесты, интеграционные тесты, а также нагрузочные тесты – и все они нацелены на валидацию целостности данных, масштабируемости системы и устойчивости к падениям в экосистемах Kafka.

Это необходимый шаг при разработке устойчивых и надежных решений для обработки данных в реальном времени. Kafka Streams опирается на Kafka, чтобы выполнять множество операций. Для этого нам нужен кластер Kafka. У тестирования тут три основных стратегии.

Привет! Давайте знакомиться. Меня зовут Илья, я являюсь Lead QA и SDET. Сегодня я хотел бы поделиться своим опытом создания платформенных решений в области автоматизации тестирования, а также рассказать о работе с уже существующими платформами. В данной статье я собрал все плюсы и минусы, которые заметил за время своей работы, чтобы понять, насколько платформы полезны и когда их стоит внедрять.
Прежде чем углубляться в тему, важно договориться о терминах, чтобы мы говорили на одном языке. Давайте синхронизируемся по терминам!

Автор:

Тестировщики, скорее всего, знакомы с понятием тест-пирамиды: юнит- и компонентные тесты, различные уровни интеграционных тестов, и все остальное.

Инструменты и приложения - с открытым или закрытым исходным кодом, коммерческие или для внутреннего использования, - всегда требуют соблюдения специфических правил для корректного и оптимального использования. Командам полезно внедрять в эти инструменты автоматическую валидацию вроде статического анализа кода. Статический анализ кода позволяет тестировать программу, не запуская код. Не путайте с подсветкой синтаксиса, когда подсвечиваются ключевые слова и элементы языка программирования.

Техники вроде статического анализа кода помогают убедиться, что созданный инструмент можно использовать целевым образом, особенно если планируется его широкое применение в отрасли. Такие проверки могут выявить проблемы кода на ранних этапах процесса разработки, и даже помочь инженерам разобраться, как работать с этими инструментами.

Начинаем

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Что мы имеем? Сложную предметную область, высокую вариативность сценариев и потенциально огромные риски от ошибок с одной стороны, и короткие итерации разработки и частые циклы доставки с другой. Я расскажу о том, как на данный момент при таких вводных выглядят процессы обеспечения качества множества сервисов, которые поставляют всю необходимую информацию нашим торговым терминалам.

Я начал свой путь в компании в конце 2017 года с должности специалиста технической поддержки, некоторое время поддерживал скрипты на python, а затем в мае 2019 года стал тестировщиком.

Здесь и далее я буду употреблять именно слово “тестировщик”, так как согласен с мнением, высказанным в книге “Agile Testing”, что в попытке называть специалистов QС или QA больше желания уйти от негативных ассоциаций низкоквалифицированной должности, чем реальных расширений компетенций. Тем не менее тестировщик в agile, как правило, более t-shaped и оказывает влияние на весь процесс разработки ПО. О выделенных ролях QC и QA, не занимающихся непосредственно тестированием, речи мы не ведем.

В мае 2021 года мне предложили занять должность тест-лида, которая со временем трансформировалась в тест-менеджера. В течение этих трёх с половиной лет мы пару раз меняли подходы к процессам в тестировании: сначала по собственной инициативе, а затем вместе с переходом компании на методологию SCRUM. Мы хотели всё и сразу, убеждались, что это невозможно, интуитивно находили более полезные сценарии действий.  А потом читали в книжках, что так давно уже все делают – но без набитых шишек нам бы и не удалось осознать, что это именно то, что нам нужно в наших условиях. Итак, приступим.

Автор:

Всем привет. Хочу рассказать об отличных способах применения ИИ в вашей IDE.

Сейчас диалоговые ИИ вроде ChatGPT напрямую встраиваются в наиболее популярные IDE – например, в Visual Studio Code, Visual Code, и семейство IDE от JetBrains.

Для начала я проведу обзор вариантов использования, в которых ИИ пригодился мне для создания кода тест-автоматизации. Затем – предложу ряд ИИ-инструментов, которые могут вам помочь.

Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»). 

В этой статье решил разобрать оба подхода и рассказать, в чём преимущества каждого из методов, какие проблемы они решают, а какие нет, и как их комбинировать. 

Автор:

Что такое простота разработки?

Простота разработки, также известная как опыт разработчика или DX (developer experience) – тема, быстро набирающая популярность в области ИТ. Однако появилась она не вчера. Первые упоминания о ней относятся к ранним 2010-м, и в последнее время в сообществах разработчиков ей уделяется все больше внимания.

Простота разработки связана с вопросом, насколько легко или сложно разработчику выполнять задачи, необходимые для процесса разработки. Положительный опыт разработчика означает, что эти задачи довольно легко выполнимы командой, потому что для поддержки процесса разработки существуют необходимые системы, технологии, процессы и культура. Короче говоря, хороший DX важен, так как позволяет разработчиком писать код с уверенностью, приносить больше пользы и повышать производительность, затрачивая меньше сил.

Когда мы говорим о «разработчиках», это включает любого вовлеченного в процесс разработки инженера, включая инженеров по обеспечению качества (QA) и тестировщиков, работающих над качеством ПО, а также любую иную техническую роль в тех же процессах.

У некоторых компаний целые отделы занимаются поиском способов улучшить опыт разработчика. Крупнейшие ИТ-компании вроде Spotify даже создали специализированные инструменты, цель которых - улучшить опыт внутренней разработки – например, Backstage, помогающий создавать порталы для разработчиков, где централизованно располагаются все инструменты, ресурсы и документация компании.

Эта статья также продемонстрирует, как улучшение опыта разработчиков напрямую влияет на качество ПО, и поэтому эта тема, возможно, заинтересует QA и тестировщиков.

Это история о том, как я погрузился в наш продукт, нашел баги, замерзал, боролся с ветром, но в итоге спас сотни заказов. Я применил философию гемба, чтобы увидеть мир глазами тех, для кого мы создаём свои решения.

Автор:

Представьте на минутку, что вы тест-робот, задача которого – тщательно следовать тест-скрипту. Ваша ключевая проблема – это выполнить текстовую инструкцию в графическом интерфейсе пользователя. Если вы тестируете веб-приложения, то ваши инструкции могут выглядеть, как строка CSS – нечто вроде ".posts:n-th(3) button:has(.pencil)." Это можно интерпретировать, как кнопку редактирования третьей записи, но в структуре приложения зависимость более глубокая.

Разработчики часто предпочитают текстовые описания, создавая юнит-тесты. Они неявно проверяют однородность наименования элементов на любимом веб-разработкой языке программирования. Проблемы начинаются, когда разрыв между разработчиками и тестировщиками увеличивается. Представьте, что вы тестируете интеграцию ряда приложений – наверное, не стоит полагаться на идентификационную схему каждого участника. Вы хотите, чтобы компьютер говорил на вашем языке, а не наоборот.

Самый простой способ показать, чего вы ожидаете от приложения – это скриншот. Это позволит быстро верифицировать тестируемую фичу. Сообщения об ошибке будут сразу считываться как две различающиеся картинки. Отчеты о падениях будут выглядеть, как зримые артефакты – тестировщики смогут взглянуть на них и исправить, даже не зная внутренней структуры. Вы получите то, что на экране. Поэтому давайте взглянем на тестирование UI на основе графики.

Страница регистрации – это не просто форма для создания учетной записи пользователя. Это тщательно продуманный процесс, который обеспечивает защиту бекэнда, соответствие стандартам конфиденциальности и безопасности, а также проводит проверку пользователей перед предоставлением определенных прав доступа к сервисам. Если вам нужно протестировать страницу регистрации, но вы не знаете с чего начать, ознакомьтесь с нашим руководством, в котором вы найдете более 100 тест-кейсов для страницы регистрации с подробным описанием.  

В этой статье мы перечислим наиболее распространенные и важные тест-кейсы и распределим их по группам.  

Автор:

Переход от «рассмотрения» к «уточнению» багов

Когда я вышла на работу в мою нынешнюю компанию, в бэклоге было столько багов, что за ними невозможно было уследить. Все знали, что с багами проблемы, но никто не знал, с чего начать. Более того, в команде за короткое время появилось и исчезло множество людей. Изменения происходили на ряде ключевых позиций – сменились вице-президент продукта, главный разработчик, главный QA-инженер и техлид. Сумятицу усиливало и то, что ключевая команда разработки сильно сократилась в объемах, и многим из нас пришлось наряжаться в множество новых шляп.

Как новичок и тестировщик, я должна была поддержать команду в улучшении качества продукта. Но это было возможно только после решения вопроса, как нам работать в изменившихся командных условиях.

Ранее у нас были регулярные встречи по рассмотрению багов, но по различным причинам никто не стремился их воскресить. Я, однако, заметила, что команда считает, что встречи по грумингу фич помогают нам повысить качество кода юзер-стори. Поэтому мы решили применить тот же подход к рассмотрению багов. И так родились сессии по уточнению багов!