Всем привет! Хочу рассказать о прохождении собеседования в Тинькофф, где я решила попробовать свои силы, несмотря на несколько этапов отбора.
Tory @SheWolf
Software Test Lead
Зачем CI/CD тестировщикам?
6 мин
Сейчас компетентность в сфере TestOps является таким же базовым требованием к QA-инженерам, как и написание автоматизированных тестов. Причина — в активном развитии CI/CD в проектах и необходимости QA-инженерам работать с пайплайнами (читать как "последовательность этапов в CI/CD") и даже внедрять свои. Так почему же CI/CD — отличный инструмент контроля качества? Давайте разбираться.
Программа самоподготовки младшего системного аналитика
2 мин
Мы решили узнать, как работает старый тезис «в интернете всё есть и бесплатно, курите маны, глупцы».
И подготовили программу самоподготовки, собранную из лучших бесплатных или совсем недорогих материалов, которые мы знаем. Общая длительность программы для освоения — от 150 часов.
Playwright — драматургия от Microsoft и новый инструмент для тестирования
5 мин
Я десять лет тестирую и пишу код, а последние четыре года — тестирую доклады в программном комитете конференции Heisenbug. Сегодня расскажу о сквозных тестах, кросс-браузерности и ощущениях от использования Playwright версии 0.10.0.
Из конца в конец
Зачем нужны сквозные (end-to-end) тесты? Они управляют браузером и имитируют действия пользователя. Например, я описал пользовательские сценарии и хочу, чтобы они были проверены с каждой версией продукта. Проверять все сценарии для всех версий вручную — дороже и дольше, чем автоматикой.
Есть разные инструменты: Selenium, Puppeteer, Protractor, Cypress и другие. Две недели назад вышел новый инструмент — Playwright, над которым работал Андрей Лушников, разработчик Puppeteer. Эта библиотека полностью решает проблему написания кросс-браузерных тестов.
SQL-инъекции' union select null,null,null --
9 мин
Согласно OWASP Top-10, SQL-инъекции считаются наиболее опасными уязвимостями. Успешная атака с их использованием может не только привести к компрометации данных, таких, как: пароли, данные кредитной карты или личная информация пользователя, но и, при определенных условиях, самого сервера. В этой статье мы рассмотрим предпосылки к появлению SQL-инъекций, ознакомимся с их видами и составим список рекомендаций для защиты веб-приложений от подобных недостатков.
Code review по-человечески (часть 1)
14 мин
Туториал
Перевод
В последнее время я читал статьи о лучших практиках code review и заметил, что эти статьи фокусируются на поиске багов, практически игнорируя другие компоненты ревью. Конструктивное и профессиональное обсуждение обнаруженных проблем? Неважно! Просто найди все баги, а дальше само сложится.Так что у меня случилось откровение: если это работает для кода, то почему не будет работать в романтичных отношениях? Итак, встречайте новую электронную книгу, которая поможет программистам в отношениях со своими возлюбленными (обложка на иллюстрации слева).
Моя революционная книга обучит вас проверенным техникам по выявлению максимального количества недостатков в своём партнёре. Книга не затрагивает следующие области:
• Обсуждение проблем с сочувствием и пониманием.
• Помощь партнёру в устранении недостатков.
Насколько я могу понять из чтения литературы по code review, эти части отношений настолько очевидны, что вообще не стоят обсуждения.
Как вам нравится такая книжка? Предполагаю, что она вам не очень по душе.
REST-assured: полезные советы
4 мин
В данной статье я собрал полезные советы по использованию REST-assured, одной из самых распространенных Java-библиотек для автоматизации тестирования REST-API.
Все примеры жизненные, они собраны из моей практики проведения code-review в более чем 50 проектах с автотестами.
Все примеры жизненные, они собраны из моей практики проведения code-review в более чем 50 проектах с автотестами.
Если у вас нет собаки…
7 мин
Если вашему бизнесу необходим BDD с живой документацией на русском, нет выделенной позиции тестировщика, либо уровень его знаний недостаточен для самостоятельной автоматизации и важно обеспечение единого стека технологий между scrum-командами, то вам безусловно необходимо хотя бы раз подключить нашу библиотеку Akita и проверить ее в действии. Перед тем как пуститься в рассказы о том, что такое библиотека Akita, хотелось бы рассказать как мы дошли до мысли о ее реализации, какие проблемы хотели решить и что в итоге у нас получилось.
Анализ ключевых показателей производительности — часть 1
7 мин
Перевод
Тестирование и анализ производительности — тема, которую хотелось бы обсуждать побольше. Мы начинаем публикацию перевода руководства от небезызвестной команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод — спасибо Игорю Щегловитову из Лаборатории Касперского, нашему бессменному автору материалов про тестирование. Остальные наши статьи по теме тестирования можно найти по тегу mstesting
Введение
Анализ производительности – дисциплина сложная. Она изучает систему на предмет выполнения требований производительности и определяет причины, если эти требования оказываются не достигнутыми. Статья Performance Analysis Primer из этого цикла содержит введение в эту тему, описывая инструменты и подходы, применяемые в облачной разработке для того, чтобы достичь хорошей производительности.
Аспектно-ориентированное программирование, Spring AOP
6 мин
Аспектно-ориентированное программирование (АОП) — это парадигма программирования являющейся дальнейшим развитием процедурного и объектно-ориентированного программирования (ООП). Идея АОП заключается в выделении так называемой сквозной функциональности. И так все по порядку, здесь я покажу как это сделать в Java — Spring @AspectJ annotation стиле (есть еще schema-based xml стиль, функциональность аналогичная).
До
и после
Т.е. есть функциональность которая затрагивает несколько модулей, но она не имеет прямого отношения к бизнес коду, и ее хорошо бы вынести в отдельное место, это и показано на рисунке выше.
Выделении сквозной функциональности
До
и после
Т.е. есть функциональность которая затрагивает несколько модулей, но она не имеет прямого отношения к бизнес коду, и ее хорошо бы вынести в отдельное место, это и показано на рисунке выше.
Join point
Знакомство с АОП
10 мин
Парадигмы программирования
В современном мире IT-разработки существует довольно большое множество различных подходов к написанию программ. Так, например, кому-то нравиться представлять программу в виде последовательности действий, а кто-то считает, что программа должна представлять собой множество объектов, общающихся друг с другом. Совокупности этих идей и понятий образуют своего рода стиль написания программы, который принято назвать – парадигма программирования.
У каждой парадигмы есть свои особенности, однако, главным фактором, различающим их, является понятие основной единицы программы. Вот самые популярные из них:
- инструкция (императивное программирование, FORTRAN/C/PHP),
- функция (функциональное программирование, Haskell/Lisp/F#/Scala),
- прототип (прототипное программирование, JavaScript),
- объект (объектно-ориентированное программирование, С++/Java),
- факт (логическое программирование, PROLOG).
Стоит заметить, что в общем случае язык программирования однозначно не определяет используемую парадигму: на том же PHP можно писать как императивные, так и объектно-ориентированные программы.
В этой статье я хочу рассказать о сравнительно молодой, но крайне, на мой взгляд, полезной парадигме программирования – аспектно-ориентированном программировании.
Советы и рекомендации по развёртыванию процесса автоматизация тестирования с нуля
23 мин
Предисловие
Описанные ниже советы и рекомендации были сформированы на основании опыта создания тестирования и автоматизации с нуля в двух компаниях и старте подобных работ в третьей. Соответственно, на лавры всезнающего специалиста нет никаких претензий, это скорее попытка поделиться опытом, сформированная в виде пошагового руководства по актуальной последнее время теме — автоматизации тестирования в компании.
Если вы решитесь это прочитать, сразу стоит учесть, что теме именно создания автотестов на языке программирования и выбора инструментария под ваш конкретный проект здесь будет уделено мало места, по причине невозможности их унифицировать и вывести для вас строгий список — на каких проектах какие инструменты будут лучше. Здесь, несомненно, придётся покопаться самому.
А вот о том, как вообще подойти к тестированию, с чего начать, как продумать тест план и начать формировать тест кейсы, как отбирать тесты для дальнейшей автоматизации, оценивать время работ и нужна ли вам вообще автоматизация и будет рассказано ниже.
P.S.: И последнее — данный текст бы никогда не сформировался, если бы не полезные лекции Алексея Баранцева и Натальи Руколь, а также пропасть информации, написанная добрыми людьми за последние годы по данной теме.
Вот теперь всё, вы предупреждены — можно начинать рассказ.
Паттерны проектирования в автоматизации тестирования
22 мин
«Нельзя просто так взять и написать классный тест. Один тест написать можно, но сделать, так чтобы по мере того, как количество этих классных тестов росло, как количество людей, которые пишут эти классные тесты, и вы не теряли ни в скорости, ни во времени...»
Эта мысль красной нитью пойдет сквозь материал под катом, и она, пожалуй, требует пояснения. Статья основана на докладе Николая Алименкова, к которому он подошёл не просто прогретым, а горящим после дискуссии с Алексеем Виноградовым о подходах к написанию тестов: методом прямого кода или при помощи паттернов. Нужны ли какие-то еще паттерны, кроме PageElement, Steps, PageObject?! С чего кто-то решил, что паттерны усложняют код, заставляют нас тратить время на создание ненужных (?) boilerplate-простыней? SOLID вам не угодил? А ведь все они создавались с учётом всего накопленного опыта сообщества разработчиков и они знали, что делают.
Николай xpinjection Алименков – известный Java-разработчик, Java техлид и delivery-менеджер, основатель XP Injection. В настоящее время является независимым разработчиком и консультантом, Agile/XP коучем, спикером и организатором различных конференций
Автоматизация тестирования имеет собственный набор задач, так что существует и набор полезных паттернов проектирования для этой области. В докладе Николай рассказывает обо всех известных паттернах и подробно описывает их с практическими примерами.
В основу этого материала легло выступление Николая Алименкова на конференции Heisenbug 2017 Piter под названием «Паттерны проектирования в автоматизации тестирования». Слайды здесь.
Собеседование на должность Automation QA Engineer
4 мин
Вот и у меня нашлась тема, которой я могу поделиться с Хабр сообществом. Надеюсь, данная статья получится не только познавательной, но и интересной.
Входные данные:
Локейшн: Днепропетровск.
Позиция: Junior Automation QA Engineer.
Технологии: C#, Selenium, MSTest, TeamCity, Hibernate.
Так получилось, что пару месяцев назад я оказался на лавке запасных в одной большой компании. Клиент решил поделить нашу команду автотестеров на 2 (хорошо, что не на ноль) и так как у меня на этом проекте срок работы был невелик, то я попал в резерв. Внутренних проектов не ожидалось, а в резерве обычно сидеть скучно и невыгодно в денежном плане. Так я начал ходить на интервью.
IMHO, как писать на Хабр
10 мин
Акронис на прошлой неделе попросил меня рассказать про опыт на Хабре. После семинара я обещал выложить основные тезисы. Возможно, вы найдёте что-то полезное ниже.
Итак, Хабр, по моему мнению, это сейчас самая большая площадка Рунета для образованных людей. Сами по себе посты очень хорошо читаются, и это одна из главных сторон. Можно охватить порядка шести миллионов разных людей за пару лет.
При этом активных (голосующих) пользователей всего около 3 тысяч. Уровень знаний аудитории на входе в пост — в примерно 95% случаев низкий, в 5% — экспертный (разбиение оценочное). Проще говоря, есть люди, которые вообще не понимают, что вы хотите сказать (и их большинство), и есть те, кто разбирается в теме на голову лучше вас. Поэтому лучший пост — это тот, что проходит от ликбеза к хардкору. На площадке довольно высокий уровень агрессии (точнее, желания проверить материал на прочность). Ранее был экстремально высок. Средняя или низкая внимательность читателя (ранее была высокая).
Разумеется, это всё моё личное мнение, и можно поспорить. Сейчас постараюсь объяснить, почему я так считаю, и как это влияет на посты. Я основываюсь на опыте примерно 1500 постов за 6 лет, которые написал сам или помогал готовить.
Но начнём с численных показателей. Вот эти компании так или иначе вызвали мой интерес тем, что для них работают агентства или выделенный инхаусный пиар:
Данные тут на конец августа, я их к другому семинару (в Хабре для владельцев блогов) готовил.
Почему 98% текстов на ваших сайтах не работают. Вообще. И как это починить
7 мин
Вот так люди видят вашу страницу
Привет!
Проблема вот в чём. Если зайти на практически любой сайт интернет-магазина или компании с услугами, вы встретите контент. Точнее — отвратительные тексты, которые писали, кажется, маркетологи, воспитанные сеошниками.
Разумеется, можно не делать, как они. Если работать по-умному, то вы поможете и читателям по жизни, и себе в продажах.
По моим примерным подсчётам (усреднение с ряда позиций), конверсии для нас выглядят так:
- Только название и картинка — около 1,5%.
- С описанием от производителя — чуть более 2%.
- С описанием человека, который держал это в руках и знает правила — около 6%.
Ниже — рассказ про то, как мы доводили время на сайте от 3 минут сначала до 6:40, а потом до 20:48. Да-да, двадцати минут сорока восьми секунд для среднего посетителя. Честного среднего, с учётом отказов и по полной выборке.