Пользователь
Как обеспечить качество программного обеспечения? Как обеспечить качественные производственные процессы? Как сделать так, что поменять, чтобы процессы и сам продукт имели встроенное качество?
Такими вопросами задаются практически все компании, которые занимаются производством программного обеспечения и для которых важно доставлять ценность до клиента без дефектов.
Этой статьей начинаю серию публикаций, посвященную встроенному качеству и как мы меняли процессы в нашей компании.
Какое мышление должно быть у команды для встраивания качества в продукт? Какая на продукте пирамида тестирования? Как ускорить получение обратной связи при разработке программного обеспечения? Продолжим разбираться...
Пишем UI автотесты на TypeScript используя Page Object + Page Factory, Playwright, Allure.
В этой статье мы поговорим о том, что можно проверить у локатора (элемента) и какие вообще есть возможности проверок. Более того, в этой статье я описал упражнения, которые вы можете выполнить и отработать в качестве практики.
Обычно мои статьи были холиварными, а не техническими. Но в этот раз решила выложить что-то действительно техническое и полезное. Тестировщики, налетай! Очень хочу, чтобы опытные ребята, которые с playwright работают давно, поделиться своим мнением о примерах в тексте статьи. Достаточно ли они информативны.
Проверки локаторов
Это могут быть как интерактивные элементы (кнопки, поля ввода, чек-боксы, ...), так и статика (картинки, текст, иконки и т.д.).
Каждый элемент на странице может давать пользователю обратную связь: поле ввода подсвечивается красным, если вы ввели невалидные данные, иконка "Сохранить" неактивна, потому что вы еще не внесли изменения в документ, цвет всплывающего уведомления должен быть красным, потому что случилась ошибка. Чаще всего, нам нужно получить какое-то свойство элемента только для того, чтобы сразу же проверить его значение. Мы хотим проверить, что отображается правильный текст или элементу присвоен нужный CSS-класс.
С другой стороны, иногда нам нужно, все же, уметь получать свойства элементов для промежуточных действий. Например, мы хотим посмотреть, сколько сейчас строк в таблице, удалить одну и проверить, что строк стало меньше на одну. Для того, чтобы организовать такую проверку, нам нужно вычислить, сколько всего строк было до того, как мы удалили последнюю строчку. Если в таблице было X строк, то, после нажатия, должно быть X-1. Найдите икс, получается? И вот тут нам нужна "ручка", которую мы дернем и получим число, без всяких assert'ов.
Всем привет! Меня зовут Антон, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 Retail Group.
В этой статье я расскажу о системах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использовать данный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.
Всем привет! Меня зовут Елена Поплоухина. Я — один из авторов Youtube‑канала по тестированию «Багаж тестировщика».
На канале выходил выпуск про построение процесса ручного тестирования с нуля. Данная статья содержит основную информацию из этого выпуска — 2 общих совета и 6 первых шагов для организации процесса.
Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»
Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.
Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.
После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =)
