Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия QA и Support. Сложностей было предостаточно, как и неприятных последствий. Но со временем мы успешно разобрались во всем. Хочу поделиться нашим опытом и рассказать, какие изменения сработали во благо.
25 лет назад Якоб Нильсен описал 10 основных принципов проектирования взаимодействия. Эти принципы были разработаны на основе многолетнего опыта в области юзабилити-инженерии и стали правилами для взаимодействия человека и компьютера.
Сегодня эти принципы так же актуальны, как и тогда. С их помощью команды разработчиков могут сэкономить значительное количество времени на раннем этапе тестирования юзабилити, чтобы они могли направить свое внимание на более сложные задачи дизайна. Кроме того, их стоит использовать в качестве контрольного списка при разработке нового продукта или функции.
Идеальный код – это код, которого нет, а функция его выполняется. Понятно, что в реальной жизни ни идеальных технических систем, ни идеального программного кода не существует. Но так порой хочется, чтобы ошибок и кривого кода было меньше, а стилистика и архитектура выбранных решений вызывала уважение коллег по цеху.
Именно поэтому сложно жить без инструмента, который бы помогал нам в автоматическом режиме следить за качеством кода. Также мы хотели, чтобы наши продукты соответствовали определённым правилам и стилю кодирования. Речь про автоматические метрики, которые можно было бы посчитать (например, сложность кода) и сделать его логику простой для понимания, без излишеств. Это не значит, что мы захотели отказаться от написания сложного кода, просто если существует возможность написать простой и сложный код для одной функциональности, лучше выбрать первое, глядишь и дебажить придется меньше. Так в нашей жизни появился SonarQube.
Привет, Хабр! Сегодня хочется поговорить про XPath — мощный и гибкий инструмент для работы с веб-интерфейсами, который при этом почему-то остается не особенно популярным. Статей и мануалов по XPath очень много, и в этом посте я постараюсь рассказать, как мы применяем данный инструмент и почему считаем его более эффективным, чем другие подходы. Если вам знаком термин “селектор”, а тем более — если вы слышали про XPath, добро пожаловать под кат, там много полезного!
Привет!
"QAчественное общение" стал одним из наших регулярных митапов для тестировщиков. Новый сезон — 5 октября (вторник), с 19.00 до 20.40 МСК.
Будут три доклада (Альфа-Банк, Test IT и Redmadrobot). Чтобы принять участие, надо заранее зарегистрироваться.
Меня зовут Святослав, в онлайн кинотеатре IVI я отвечаю за бета-тестирование. Хочу рассказать вам про то, как пользователи сервиса могут принимать активное участие в его тестировании, получать от этого удовольствие и вносить неоценимый вклад в его качество.
Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать — задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в UI/UX становится первым решением для упорядочивания и хранения данных. Сегодня поговорим о тестировании, так что в нашем случае объектами хранения будут выступать тест-кейсы. Как их хранят чаще всего? Верно, в папочках!
Привычно? Да. Но так ли это решение хорошо и универсально? Вопрос подкрепляется существованием исключений: почта, JIRA-тикеты и много чего другого хранится не в папках. Давайте разбираться, почему.
Есть такая поговорка: если за дело берется профессиональный тестировщик, он обязательно что-нибудь сломает. Ну а если серьезно, то это достаточно интересная тема для обсуждения. Тестирование, как правило, лежит на стыке двух областей — разработки и того, чему посвящен разрабатываемый продукт. Это может быть медицина, физика, компьютерные игры — все что угодно.
В тестировщики часто идут люди, хорошо разбирающиеся в какой-то своей области, с целью помочь сделать продукты для нее лучше. Ну а еще из-за денег.
В статье вы найдете ответы на 10 важных вопросов о тестировании: инструменты, скилы, карьерный рост, проекты, зарплату и еще кое-какую информацию, которая может оказаться полезна, если вдруг вы надумали переквалифицироваться в тестировщики.
В этом кратком обзоре я хотел бы поделиться своим опытом, как отключить проверку SSL для тестовых сайтов, иначе говоря, как сделать HTTPS сайты доступными для тестирования на локальных машинах.
Сегодня я расскажу вам об отслеживании ошибок в реальном времени в приложении React. Приложение внешнего интерфейса обычно не используется для отслеживания ошибок. Некоторые компании часто откладывают отслеживание ошибок, возвращаясь к нему после документации, тестов и прочего. Однако, если вы можете изменить свой продукт в лучшую сторону, то просто сделайте это!
Количество запрещенных в России сайтов стабильно растет. От блокировок страдают не только плохие ребята но и рядовые пользователи интернета.
Я как разработчики различных веб-сервисов и ресурсов, периодически сталкиваюсь с недоступностью последних в России. Это создает проблемы как для бизнесов, так и для личных проектов. Нельзя быть уверенным, что завтра ваш сайт откроется у посетителей.
Продвинутые пользователи уже привыкли жить с VPN или прокси. К сожалению, простые смертные зачастую ничего об этом не знают. Заставить всех использовать средства обхода невозможно, в таком случае, я предлагаю взять ответственность за доступность сайта в свои руки.
Есть несколько способов, в том числе официальных, узнать о том что ресурс заблокирован, например Is It Blocked In Russia? — идею которого я позаимствовал. Этого достаточно для ручной проверки сайта. Действие легко воспроизвести, а значит автоматизировать.
В качестве проекта выходного дня, я запилил небольшой сервис, который частично копирует и расширяет возможности оригинального проекта. Для простоты, я добавил отдельный путь вида /ping?url=habr.com, который в виде ответа возвращает HTTP-статус: 200 — сайт доступен в России, 451 — сайт недоступен, 400 — с адресом что-то не так. В таком виде, ссылку можно скормить любому сервису мониторинга, например https://uptimerobot.com.
Код должен тестироваться на той СУБД, с которой он будет работать. Testcontainers — это такая библиотека, которая позволяет использовать в юнит тестах практически любую СУБД с той же лёгкостью, что embedded базы данных типа HSQLDB или H2. Был бы только Docker образ
Именно сборке удобного для использования с Testcontainers докер образа посвящена эта статья. У меня при попытке его сделать возникли проблемы, и тут я делюсь своим решением.
Собирать буду образ для Oracle 11, потому он небольшого размера и мне версии 11 хватает. С другими версиями подход примерно тот же.
Для того, чтобы было понятно, как использовать образ, тут также будет код на Java, который демонстрирует применение образа для тестирования Spring Boot приложений. Способ подключения к testcontainers я привёл, наверное, не самый лучший. Но во-первых он демонстрирует как использовать настройки, заданные при создании образа. Во-вторых он простой. И в-третьих он почти не завязан на Spring, его можно воткнуть даже в джава код, в котором нет ничего, кроме public static void main.
Предполагается, что читатель обладает поверхностным знакомством с Docker и Testcontaners, а также хорошо знает Java. Для сборки нужно использовать linux, если собираете под Windows, нужно будет применить msys2 или что-то в этом духе.
Демонстрационный код залит на гитхаб вот сюда https://github.com/poxu/testcontainers-spring-demo Поправленные скрипты для сборки образа можно посмотреть в моём форке Оракловских инструкций https://github.com/poxu/docker-images/tree/master/OracleDatabase/SingleInstance
Вначале была функция и вызывали ее в одном месте. Потом мы захотели вызвать ее в другом месте с новыми возможностями и обновили ее. Нам эта ф-ия так понравилась, что мы вызвали ее в третьем месте и еще сделали функциональные правки и… в первом месте что-то пошло не так. А как узнать? Проверять во всех местах где мы использовали эту функцию, все ли правильно работает? Можно, но лучше использовать unit тесты.
Всем привет. На связи аноним из песочницы. Как правильно тестировать свой код вы можете найти в первых строчках поисковика, а вот с настройкой окружения приходится повозиться. Так вот сегодня я хочу помочь начинающим разработчикам настроить окружение для unit тестирования своего кода.
