Привет, меня зовут Андрей Николаев и я занимаюсь автоматизацией тестирования в hh. Более 2/3 наших десктопных пользователей прямо сейчас используют последнюю версию Google Chrome, поэтому мы хотим, чтобы и в наших E2E-автотестах (Java + Selenium) версия браузера была максимально приближена к пользовательской. Но не всегда апгрейд версии в тестах проходит гладко (то работа с куками поменяется, то remote DevTools по умолчанию оказываются недоступны, то просто наши хитровыдуманные клики начинают кликать не туда, и т.д. и т.п.). Поэтому нельзя просто так взять и поднять версию Chrome в автотестах — нужна предварительная проверка, которая при ручном выполнении требовала множества телодвижений, поэтому в какой-то момент мы решили, что раз работа серверов стоит дешевле работы человека, то пусть они и проверяют.

Я работаю техническим писателем в компании documentat.io. Мы занимаемся заказной разработкой технической документации, в том числе на английском языке. Иногда я дорабатываю уже существующие документы или спецификации к API на английском. Как правило, такие документы написаны русскоязычными разработчиками, которые неплохо владеют английским. И всё же они часто допускают характерные грамматические, пунктуационные и стилистические ошибки.

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

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

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

Всем привет! Меня зовут Иван и я Head of QA Automation в Skyeng. Я регулярно занимаюсь обучением Manual QA и менторством начинающих QA Automation (далее – QAA) и часто слышу от падаванов вопрос: «А как же мне, собственно, стать QAA?»

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

Представим, что я Manual QA: каждый день занимаюсь ручным тестированием, пишу тест-кейсы, хожу на планирование, ревьюю требования и тестирую задачи. 

Однажды приходит осознание, что нужно расти. Но куда?

Содержание

• 1. Антипаттерны: плохое обоснование
  
  • 1.1. Очевидно же
  • 1.2. Мамой клянусь!
  • 1.3. Зайчики обиделись
• 2. Хорошие паттерны обоснования
  
  • 2.1. Пруфлинк
    
    • Ссылка на требования
    • Сами требования
    • Ссылка в интернет
    • Письмо заказчика
    • ROI
    • Статистика
  • 2.2. Единообразие
  • 2.3. Проблема, или #жизньболь
• 3. Когда обоснование не нужно
• 4. Итоги

• это действительно баг;
• его необходимо исправить;
• его нужно исправить именно так, как мы сказали.

• Коллеги отвлекают с вопросами «А почему это баг?», вырывая из контекста.
• Спустя месяц ты сам забыл, а, собственно, почему это был баг…

• начинающих тестировщиков — узнайте, как грамотно объяснять свою точку зрения;
• тест-менеджеров — чтобы дать ссылку своим падаванам и потом ссылаться на антипаттерны без дополнительных объяснений.

1. Антипаттерны: плохое обоснование

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

Меня зовут Александр Моргунов, я техлид в Самокате. Пишу на TypeScript, React, ReactNative. В разное время писал тесты для фронтенда, бэкенда и мобилок. В этом посте хочется поговорить о том, как можно тестировать современные фронтенд-приложения и какие подходы к тестированию сейчас актуальны. 

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

Всем привет! В статье продолжаю давать вредные советы из области автоматизации: по кодингу, коммуникациям, организации процессов, стандартам, визуализации и т. д. Здесь вы найдёте подробную инструкцию о том, что нужно делать автоматизатору, чтобы усложнить жизнь себе и окружающим. Первую часть можно прочитать здесь. 

Привет, Хабр! Меня зовут Мария Снопок, я отвечаю за автоматизацию тестирования на Python в X5 Tech. Я, конечно, не Остер, но могу дать с десяток вредных советов из области автоматизации. В частности, о том, как испортить жизнь себе и окружающим. 

В статье я собрала вредные советы по кодингу, коммуникациям, организации процессов, стандартам, визуализации и пр.: что нужно делать, чтобы тебя закидали помидорами. Смело наступаем на грабли – советы подкреплены реальными кейсами.

Что делать, если у команды появилась потребность регулярно оценивать производительность приложения и в динамике сравнивать быстродействие с прошлыми прогонами, а внедрять для этого решение enterprise-уровня - это как из пушки по воробьям? Мы решили пойти немного неочевидным, но продуктивным путём, воспользовавшись опытом реализации функциональных тестов и их интеграции в систему CI/CD, ведь, в сущности, почему нужно обязательно смотреть на тестирование производительности, как на что-то особенное? Что из этого получилось, и с какими проблемами при этом пока ещё приходится мириться - читайте под катом.

Мы расспросили шестерых прокачанных багхантеров, на счету которых сотни обнаруженных уязвимостей в системах известных компаний (в том числе с присвоенными CVE) и которые одними из первых присоединились к The Standoff 365 Bug Bounty, о том, какие ресурсы помогают им прокачивать навыки в offensive security и оперативно узнавать о новых ресерчах, техниках и эксплойтах. Надеемся, подборки Circuit, Ustinov, Zctym92, Fi5t, Impact и еще одного исследователя, пожелавшего сохранить инкогнито, помогут обнаружить те самые баги, которые принесут вам солидное денежное вознаграждение, признание комьюнити и публичную благодарность от известных компаний.

На большей части проектов сейчас востребованы знания по тест-дизайну и тестированию API.

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

Мы продолжаем делиться полезными материалами и сегодня поговорим о Selenium – инструменте тестирования web-приложений. Изучая его особенности, мы обнаружили в комьюнити ряд сообщений о различных ошибках: например, разработчики сталкивались с падением тестов, связанных с Shadow DOM, и получали ошибки в значениях root для Selenium. Однако, существует мнение, что такие сбои тестов могут оказаться не багом, а фичей. О своем подходе к работе с теневым DOM рассказал Титус Фортнер – core contributor в Selenium и автор материалов о тестировании. С разрешения автора переводим его статью, дополнив наблюдениями из нашей практики. Материал может быть полезен всем, кто занимается автоматизацией UI-тестирования с помощью Selenium.

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

Меня зовут Дмитрий Пирумов, я возглавляю команду автоматизированного и приемочного тестирования в РТЛабс. В этой статье я хочу поделиться опытом проведения тестирования на проде, внедренного у нас в компании, и попробовать показать профит и болевые точки такого подхода. 

Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:

1. Написать код приложения

2. Собрать проект

3. Поднять его на сервере приложения

Сегодня я расскажу про третий этап: что вообще такое сервер приложения и зачем он нужен.

Всем привет! Сегодня я расскажу о том, как мы тестируем Rest API в SM 2.0 с помощью инструмента Postman.

И сделаю это на примере реальной задачи — посмотрим сценарий пользователя (как оформляется заказ у нас на сайте), посмотрим, как это работает все изнутри, пару слов скажу о REST-запросах, расскажу про Postman. Далее мы перейдём в сам инструмент, посмотрим окружение, интерфейс, далее разберём исходные данные и приступим к решению самой задачи, и в конце немного расскажу про автотесты.

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

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

Когда я говорю о неэффективности популярных блокчейнов; или упоминаю то, что мы, похоже, мчимся к web3, централизованному настолько, что это бросает вызов крепкой хватке больших технологических компаний современного веба; или указываю на то, что почему-то никому не удалось найти хороший способ применения блокчейна, который был бы лучше, чем альтернативные варианты его не использующие, я часто слышу: «Это ещё ранние дни», «Всё только начинается», «Дай ему шанс», «Люди всё ещё разбираются во всех этих блокчейн-технологиях, устраняя их недостатки»...