Pull to refresh
0
@ipulyahin read⁠-⁠only

User

Send message

Эй, QA! Почему вы не нашли этот баг?

Reading time 6 min
Views 21K

Почему это «токсично» и как сформулировать вопрос правильно.

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

На следующий день те же самые менеджеры, ещё не оправившиеся после вчерашнего допроса, обращаются к своим тестировщикам и спрашивают: «Почему вы не нашли этот баг?»

Читать далее
Total votes 13: ↑10 and ↓3 +7
Comments 16

Как решать сложные (технические) проблемы

Reading time 4 min
Views 14K
image


Мировоззрение


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


Поиск первопричины


  • Постарайтесь воспроизвести проблему
    • Можете ли вы воспроизвести это из командной строки?
      • Другим людям легче воспроизвести проблему
      • Легче проверить исправление
  • Есть ли логи? Что за сообщение об ошибке?
    • Прочтите описание ошибки. Каждое его слово. Дважды.
    • Есть ли где-нибудь опечатка (командная строка / конфигурация / код)?
  • Изолируйте проблему
    • Удалите некоторые части системы и попробуйте воспроизвести ошибку
    • Меняйте одно за раз, сохраняя все остальное постоянным
Читать дальше →
Total votes 20: ↑15 and ↓5 +10
Comments 6

TestOps: писать автотесты недостаточно

Reading time 9 min
Views 27K

Совсем недавно я услышал замечательную историю о проекте внутри крупной российской IT-компании, ищущей руководителя в отдел тестирования. Задача была простая: есть отдел из 20 человек, которые за последние несколько лет наколбасили несколько тысяч автотестов и спроектировали пачку тестов ручных. В целом все работало, но СТО на собеседовании сказал примерно следующее: “Ваша задача — выкинуть все это к чертям собачьим и сделать нормально. А то когда предыдущий QA Lead ушел, мы поняли, что вся эта инфраструктура у нас нигде не используется.” 

Ситуация невообразимая. Так не бывает. У нас точно не так. У нас же не так? 

Проблема “works on my machine” и “ответственность за нерабочий код лежит на том, кто его деплоит” ровно о том же. И пока разработчикам рассказывали про спасительный DevOps, тестировщики и QA-специалисты как-то со стороны смотрели на это “не шаля, никого не трогая, примус починяя”. Ну что, пришло время набросить и на этот вентилятор.

В этой статье мы с Артемом Ерошенко из Qameta Software попробуем разобраться, что такое “делать тестирование нормально” в новых проектах и какие инструменты могут в этом помочь. 

Давайте разбираться!
Total votes 21: ↑20 and ↓1 +19
Comments 28

Самый полный список метрик тестирования на русском языке

Reading time 7 min
Views 49K

За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании? 

Читать далее
Total votes 6: ↑4 and ↓2 +2
Comments 2

Чек-лист тестирования WEB приложений

Reading time 5 min
Views 206K
Привет! После публикации статьи «Чек-лист тестирования мобильных приложений», поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого WEB приложения.


Читать дальше →
Total votes 12: ↑10 and ↓2 +8
Comments 9

Знай сложности алгоритмов

Reading time 2 min
Views 982K
Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!
Читать дальше →
Total votes 312: ↑296 and ↓16 +280
Comments 99

Swagger/OpenAPI Specification как основа для ваших приёмочных тестов

Reading time 17 min
Views 65K

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


Я занимаюсь автоматизацией тестирования в Яндексе с 2013 года. Из них более четырёх лет автоматизирую тестирование REST API-сервисов. На Heisenbug я рассказал об использовании OpenAPI-спецификации как основы для приёмочных тестов, а также о том, как легко поддерживать автотесты на огромное количество REST API-сервисов и добавлять автотесты на новые проекты.



Под катом — видеозапись и расшифровка моего доклада. Примеры из доклада есть на GitHub.

Total votes 19: ↑19 and ↓0 +19
Comments 5

Автогенерация тестов на Puppeteer встроена в Chrome DevTools

Reading time 3 min
Views 20K

В Chrome 89 в DevTools добавлена экспериментальная поддержка автогенерации JS-скриптов на Puppeteer.

Схематично это работает так: вы открываете нужную страницу, в DevTools включаете запись действий, и после делаете что-то на странице обычным образом (кликаете по ссылкам и кнопкам, переходите на другие страницы, вводите текст). По мере выполнения действий браузер наполняет DevTools-вкладку с виртуальным файлом записи JS-кодом, описывающим через API Puppeteer все действия. После этого запись можно остановить, и сохранить полученный код в виде реального JS-файла.

Для демонстрации новой функциональности (названной Puppeteer Recorder) авторы подготовили небольшую демо-страницу (хотя проверять можно на любой странице, никаких предварительных условий от сайта не требуется).

Но сперва, поскольку это ещё ранняя экспериментальная функция (хотя авторы планируют развивать и расширять Puppeteer Recorder), её нужно включить в настройках DevTools, на вкладке Experiments, в виде пункта Recorder:

Читать далее
Total votes 17: ↑17 and ↓0 +17
Comments 5

Ставим Selenium Grid на колеса Apache Mesos

Reading time 13 min
Views 13K
Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.



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

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.
Читать дальше →
Total votes 35: ↑35 and ↓0 +35
Comments 18

Как выполнять много UI-тестов параллельно, используя Selenium Grid?

Reading time 7 min
Views 22K

Всем привет! Я работаю в Avito и занимаюсь разработкой инструментов для тестирования. Когда у нас стало много UI-тестов, мы столкнулись с проблемой масштабирования Selenium-серверов, и сейчас я расскажу, как мы ее решили.


И так как же все-таки выполнять много UI-тестов параллельно, используя Selenium Grid? К сожалению — никак.
Selenium Grid не способен выполнять большое количество задач параллельно.
Хотите зарегистрировать действительно большое количество нод? Что ж, попробуйте.
Хотите скорости? Её не будет — чем больше нод зарегистрировано на гриде, тем менее стабильно выполняется каждый тест. Как следствие — перезапуски.
Хотите отказоустойчивость на случай, если Grid перестал отвечать? Тоже нет: вы не можете запустить несколько реплик и поставить перед ними балансировщик.
Хотите обновить Grid без даунтайма и чтобы тесты, выполняющиеся в данный момент, не упали? Нет, это не про Selenium Grid.
Хотите не держать тысячи Selenium-ов разных конфигураций в памяти, а поднимать их по требованию? Не получится.
Хотите знать, как решить все эти проблемы? Тогда приглашаю вас прочитать эту статью.
*(Мой доклад с таким же названием уже звучал на Heisenbug 2017 Moscow, и, возможно, кто-то из читателей с ним знаком. Под катом — более подробная текстовая версия рассказа об инструменте).


Читать дальше →
Total votes 26: ↑26 and ↓0 +26
Comments 10

Callisto. Зачем мы придумали замену Selenium Grid

Reading time 7 min
Views 8.2K

На Хабре уже не раз писали о том, что у Selenium Grid есть проблемы, которые не решить простым способом (например: раз, два, три). В этой статье мы поделимся нашим опытом и расскажем, как нам в Wrike удалось построить стабильную инфраструктуру для Selenium-тестов.

TLDR: Мы написали своё open source решение и полностью заменили им Selenium Grid.

Читать далее
Total votes 16: ↑15 and ↓1 +14
Comments 11

Паттерны и антипаттерны Cucumber BDD

Reading time 7 min
Views 20K
Потратив множество человеко-часов над разработкой автотестов для нескольких огромных проектов, я с полной уверенностью могу сообщить, что составил может быть далеко не полный, но уж точно достаточно крупный набор практик, с которыми хочется поделиться с каждым. Итак, следуя стопам классиков, хочу (надеюсь увидеть дополнения от вас в комментариях) составить:

Шаблоны проектирования Cucumber BDD сценариев


Цели:

  • получить готовый инструмент, при помощи которого станет возможным стандартизировать процессы разработки и контроля качества исполняемых сценариев, построенных для работы в Cucumber-based технологических стеках (cucubmer jvm, SpecFlow и проч.)
  • получить набор правил, позволяющих специалистам с разных проектов легко мигрировать между проектами без длительной фазы привыкания
  • получить чистый, легко-читаемый код сценариев, который легко расширяется и слабо подвержен полным переписываниям текстов сценариев при минимальных изменениях UI

Итак, поехали!
Читать дальше →
Total votes 18: ↑14 and ↓4 +10
Comments 7

Паттерны проектирования в автоматизации тестирования

Reading time 22 min
Views 160K
«Нельзя просто так взять и написать классный тест. Один тест написать можно, но сделать, так чтобы по мере того, как количество этих классных тестов росло, как количество людей, которые пишут эти классные тесты, и вы не теряли ни в скорости, ни во времени...»

Эта мысль красной нитью пойдет сквозь материал под катом, и она, пожалуй, требует пояснения. Статья основана на докладе Николая Алименкова, к которому он подошёл не просто прогретым, а горящим после дискуссии с Алексеем Виноградовым о подходах к написанию тестов: методом прямого кода или при помощи паттернов. Нужны ли какие-то еще паттерны, кроме PageElement, Steps, PageObject?! С чего кто-то решил, что паттерны усложняют код, заставляют нас тратить время на создание ненужных (?) boilerplate-простыней? SOLID вам не угодил? А ведь все они создавались с учётом всего накопленного опыта сообщества разработчиков и они знали, что делают.

Николай xpinjection Алименков – известный Java-разработчик, Java техлид и delivery-менеджер, основатель XP Injection. В настоящее время является независимым разработчиком и консультантом, Agile/XP коучем, спикером и организатором различных конференций

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



В основу этого материала легло выступление Николая Алименкова на конференции Heisenbug 2017 Piter под названием «Паттерны проектирования в автоматизации тестирования». Слайды здесь.
Total votes 30: ↑28 and ↓2 +26
Comments 4

11 шагов к высокой доставляемости email рассылки

Reading time 5 min
Views 12K


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

По статистике 21 % email рассылок коммерческого назначения не доходят до адресатов. Это значит, что каждое пятое отправленное письмо блокируется почтовым сервисом или теряется из-за несуществующих адресов и переполненных ящиков пользователей.
Читать дальше →
Total votes 22: ↑15 and ↓7 +8
Comments 7

Опыт автоматизации регрессионного визуального тестирования на Java + Selenium Webdriver + aShot

Reading time 3 min
Views 9.2K
Здравствуйте.

В этой статье я бы хотел рассказать о своем опыте автоматизации визуального регрессионного тестирования.
Читать дальше →
Total votes 17: ↑13 and ↓4 +9
Comments 3

Простое решение для визуального регрессионного тестирования на Java + Selenium Webdriver + aShot

Reading time 4 min
Views 13K
Здравствуйте.

Я уже публиковал статью о своем опыте автоматизации визуального регрессионного тестирования.

С тех пор проект был значительное доработан — изменилась структура, стало гораздо проще настроить проект и начать писать автотесты, значительно улучшен отчет.



VisualRegressionFramework — это довольно простое решение для небольших проектов. Для проекта с которым я работаю написано около 50 автотестов (страницы + элементы).
Читать дальше →
Total votes 5: ↑4 and ↓1 +3
Comments 5

Как мы тестируем поиск в Яндексе. Screenshot-based тестирование блоков результатов

Reading time 5 min
Views 41K
Чем крупнее и сложнее становится сервис, тем больше времени приходится уделять тестированию. Поэтому желание автоматизировать и формализовать этот процесс вполне законно.

Чаще всего для автоматизации тестирования веб-сервисов применяется Selenium WebDriver. Как правило, с его помощью пишут функциональные тесты. Но, как всем хорошо известно, функциональные тесты не могут решить задачу тестирования верстки сервиса, что требует проведения дополнительных ручных, зачастую кроссбраузерных, проверок. Как тест может оценить корректность верстки? Чтобы обнаружить регрессионные ошибки верстки, тесту потребуется некоторый эталон, в качестве которого может выступать изображение корректной верстки, взятой, например, с продакшен-версии сервиса. Этот подход носит название screenshot-based testing. Подход этот применяется достаточно редко, и чаще всего верстку все же тестируют вручную. Причина этому – ряд достаточно строгих требований к сервису, к среде выполнения тестов и к самим тестам.

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

На примере тестирования колдунщиков в поиске мы расскажем, какими особенностями должен обладать тестируемый сервис, какие проблемы возникают у нас при использовании screenshot-based testing, и как мы их решаем.

image
Читать дальше →
Total votes 78: ↑71 and ↓7 +64
Comments 17

Screenplay — не Page Object'ом единым

Reading time 9 min
Views 18K

Со временем вносить изменения в любой продукт становится сложнее, и растёт риск не только зарелизить новые фичи, но и сломать старые. Часто вместо того, чтобы руками проверять весь проект, этот процесс стараются автоматизировать. Если поговорить с людьми, которые занимаются тестированием интерфейсов, походить по конференциями, становится понятно, что в мире веб-тестирования правит Selenium, а в качестве организации кода подавляющее большинство используют Page Object.


Вот только мне, как программисту, этот паттерн и код, который я видел у разных команд, почему-то никогда не нравился — в голове звучали буквы SOLID. Но я уже был готов смириться с тем, что тестировщики пишут код, как им удобно, из-за отсутствия альтернатив, как где-то год назад, на Angular Connect, услышал я доклад, посвящённый тестированию Angular приложений c использованием Screenplay паттерна. Теперь хочу поделиться.


Читать дальше →
Total votes 16: ↑15 and ↓1 +14
Comments 1

Allure-Framework. Работа с кодом

Reading time 11 min
Views 104K
Продолжая серию публикаций о возможностях Allure-framework, сегодня мы поговорим о работе с кодом. Под катом разбираем, что такое шаг теста, как выводить информацию в отчет при выполнении шагов и какие бывают категории дефектов. Кроме того, расскажем об аннотациях Allure. Дальше еще интереснее!
Читать дальше →
Total votes 5: ↑4 and ↓1 +3
Comments 5

Information

Rating
Does not participate
Registered
Activity