Для написания автотестов используются XPath и CSS-селекторы. Они помогают найти элемент на странице, чтобы потом с ним как-то взаимодействовать (кликнуть, ввести текст, или что-то другое).
Я видела много статей о том, что это вообще такое, но мне очень не хватало шпаргалки по разным селекторам, причем в разрезе «Вот он в CSS и он же в XPath» для сравнения.
А мне такое для студентов надо. Поэтому решила сделать сама. Вдохновлялась страничкой «Xpath cheatsheet», но сделала на свой вкус — под автоматизацию, а не XPath вообще. И с комментариями, с ними удобнее.
Пишите, если где-то накосячила. Хотя я все селекторы проверяла на тестовых страницах, но мало ли… И надеюсь, вам такая шпаргалка тоже пригодится! =)
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Как вы, вероятно, догадываетесь, мне приходит много писем об инструментах тест-автоматизации. КУЧА. Я открываю почти все и бегло их просматриваю. Если что-то цепляет мой взгляд, неважно, хорошее или плохое, я тщательно читаю письмо. Думаю, многие из нас делают так же.
«Плохие» сообщения – это не что-то, полное ненависти или совершенно неуместное (с таким я управляюсь иным образом) – зачастую они относятся к активному продвижению идей автоматизации вне всякого контекста, для чего эти идеи подходят, и что нужно, чтобы их внедрить. Как правило, я просто удаляю это и еду дальше. Иногда мне хочется – конечно, вежливо, - ответить отправителю, что его компания тем или иным образом отклоняется от цели. Иногда я использую их в качестве идей для статьи; это как раз такой случай.
Изначально планировала в этой статье сравнить работу с ментором с курсами, однако, поскольку это будет сильно не объективно (курсов сейчас много, как и менторов), решила провести небольшое исследование на тему того, откуда люди изначально получали знания перед тем, как пойти в тестирование. В этой статье я постаралась собрать опыт 55 человек, заполнивших мой опрос или согласившихся провести со мной интервью, большая часть которых устроилась на свою первую работу в период с 2021 по 2024г. (т.е. когда конкуренция на стартовых должностях уже начала принимать серьезные обороты).
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Новый год – время задуматься, как ваша команда может улучшить качество продукта! Я часто слышу, как тестировщики жалуются, что стали «бутылочным горлом» для своей команды. На них постоянно давят, чтобы они закруглялись с тестированием, и им кажется, что у них не остается времени на качественное исследовательское тестирование или хорошую автоматизацию.
Мой опыт говорит, что тому есть девять основных причин. Читайте дальше, чтобы проверить, применимы ли они к вашей команде!
Всем привет! Я Тимур — iOS разработчик в платформенной команде hh.ru. Сегодня я расскажу о нестабильных UI-тестах в iOS, и как мы с ними справляемся.
Мы уделяем массу внимания UI-тестам, ведь именно они обеспечивают качество и стабильность в наших iOS-приложениях. Сейчас у нас включено около 600 UI-тестов: они гоняются утром, вечером и на каждом PR в develop. О том, как мы обеспечиваем качество мобильной разработки есть отдельная статья.
Рано или поздно большое количество UI-тестов скорее всего начнут тормозить разработку, потому что их стабильность зависит от множества факторов: стенды (API), инфраструктура (обновление Xcode, машин, СI), кодовая база. Даже из‑за проблем в самом XCUITest тесты могут начать выдавать аномалии.
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Расхожая фраза «как у всех нормальных людей» означает приобретение лишних «вещей» или особое поведение – только потому, что ваши друзья, соседи, коллеги уже имеют эти вещи или так себя ведут. Идея тут в том, что если вы не хотите выглядеть лузером на их фоне, вам нужно хотя бы идти в ногу с их социальной и экономической позицией. Мой сосед купил новую машину – мне тоже надо. У коллеги новый MacBook – мне тоже надо. Netflix использует Chaos Monkey – мы тоже должны. Даже в мире технологий мы можем стать жертвами схожего феномена, изучая, как другие компании и организации обращаются с различными дисциплинами и технологиями, и тестирование/автоматизация тут не исключение.
Принцип хорошего автотеста — «Подготовь себе данные сам. Не надейся, что они уже существуют». Такой тест можно прогнать на любом стенде, даже пустом. Сам себе всё подготовил, прогнал тест, а потом ещё почистил за собой.
В Postman тоже есть возможность подготовить себе данные для запроса. Причем это можно использовать не только для автоматизации, но и для ручного прогона. Удобно же, когда можно запустить конкретный запрос на конкретный метод, а он отработает успешно хоть на пустой базе, хоть на заполненной.
Подготовка данных делается через функцию pm.sendRequest() в pre-request скриптах, и в этой статье я покажу, как её использовать. Показывать буду в стиле «бери и повторяй» с примерами на бесплатной системе Users.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Первое, что я поняла, начав работать в тестировании – это то, что я страстно ненавижу системы управления тест-кейсами. Если вы не знакомы с такими системами, то это инструменты, позволяющие тестировщикам создавать коллекции ручных тестов, чтобы использовать их повторно. До бума популярности тест-автоматизации они были очень распространены. В этой статье я объясню, почему я так их ненавижу, а затем поясню, почему все равно ими пользуюсь и меньше недолюбливаю ту, которую я выбрала.
Всем привет! Меня зовут Фефилов Александр, я работаю в QA с 2017 года. По большей части это были компании, которые занимались аутсорсингом, но затем я присоединился к SM Lab.
Как вы уже поняли из названия поста, я расскажу о том, как взаимодействовать с заказчиком (а иногда и с заказчиками) с позиции QA-эксперта.
Под катом личный опыт работы в разных крупных компаниях и ответы на вопросы:
как работать с двумя представителями заказчика в случае, когда их требования часто противоречат другу другу, а сами они между собой не общаются
что делать, если ваш заказчик живёт в парадигме «Я плачу деньги, а ты просто делаешь всё, что я говорю»
как решать процессные задачи
как находить продуктовые проблемы
кто такой QA-эксперт и как им стать
полезная методика, которая может пригодиться вам в работе.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Наша главная задача как тестировщиков – это выявить реальный статус продукта. Помните – все остальные участники проекта сконцентрированы на Успехе, Предотвращении Проблем, Встраивании Качества, Добавлении Ценности, и всякое такое. Все это здорово, ничего плохого тут нет. Но есть нюанс.
Оптимистический фокус, необходимый для создания продукта, может отвлечь внимание от проблем, угрожающих его качеству и ценности – проблемы, которые просочились мимо всех усилий их предотвратить. Как тестировщики, мы изучаем продукт, исследуем его и экспериментируем с ним, чтобы выявить его настоящее состояние, особо концентрируясь на поиске багов и риска. Это делает нас особенными: у всех остальных не стоит основной задачи искать неприятности – в том числе потенциальные.
