Home

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Практически каждый крупный язык программирования имеет тест-фреймворки BDD, и Python – не исключение. На самом деле у Python их даже несколько? Как их сравнивать, какой из них лучше? Давайте разберемся.

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я имел счастье делать доклад на конференции UKStar 2019 в Лондоне, и говорил о том, как задавание правильных вопросов (подсказка – сначала спрашивайте "зачем", а потом "как") помогает командам и организациям предотвратить "автоматизацию ради автоматизации" и повысить шансы на то, что тест-автоматизация станет важной и значимой частью жизненного цикла разработки и тестирования.

В своем докладе я использовал аналогию, сравнивая тест-автоматизацию с пузырчатой пленкой в попытке помочь людям увидеть автоматизацию в новом свете, не рассматривая ее как "идеальное" решение всех проблем тестирования (что до сих пор происходит чрезмерно часто). Об этой аналогии потом писали и задавали уточняющие вопросы в Твиттере, поэтому я решил, что нужно рассказать о ней подробнее.

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Автоматизация тестирования – это краеугольный камень непрерывного процесса поставки программного обеспечения. Автоматизация постоянно держит новые фичи под огнем тестов, которые никогда не будут вовремя завершены, если мы начнем выполнять их вручную. Однако по моему опыту код тест-автоматизации – это иногда худший код в мире разработки. Команды зачастую не придают значения его важности, объему требуемой работы и его уникальным техническим трудностям. В результате выходит не код, а громоздкая куча мусора! Его даже можно назвать "банкротом".

Что делать в этой ситуации? Полностью забить на существующее решение по автоматизации и начать заново? Может, и так, а может, и нет. Не торопитесь взорвать все, что можно, и начать сначала! Нет такого понятия, как идеальный проект, и, возможно, еще можно что-то сделать. Перезапуск автоматизации с нуля – не самое простое решение.

Публикуем доклады с конференции SQA Days 25, посвященные вопросам автоматизированного тестирования.

• Тестируем SQL Server код с tSQLt – Никита Белковский, АО "Аркадия" (Таганрог).
• Ведущие разработчики учат меня писать автотесты – Виталий Рощупкин, ЗАО "ПФ "СКБ Контур" (Екатеринбург).
• От Page Object к MVC с использованием .NET – Игорь Ершов, АО "Калуга Астрал" (Калуга).
• Tips and tricks: упрощение синтаксиса тестов и multi-environment тестирование – Лилия Сапурина, Deutsche Bank (Санкт-Петербург).
• Специфика разработки и тестирования статического анализатора – Сергей Хренов, PVS-Studio (Тула).
• Швейцарский нож тестировщика или Jmeter не только для нагрузки – Сергей Махетов, СКБ Контур (Екатеринбург).
• Хочешь написать фреймворк для автоматизации тестирования бэкенда? Спроси меня как! – Людмила Михейцева, OOO "БСЦ Мск" (Нижний Новгород).
• Автоматическое регрессионное тестирование с помощью AET при непрерывном развёртывании ПО – Радек Логмин, Cognifide (Познань).

 Видео докладов ниже.

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы занимаетесь тест-автоматизацией через веб-интерфейс (например, при помощи Selenium WebDriver), то, возможно, тратите много рабочего времени на поиск элементов на странице – к примеру, кнопок, полей ввода и блоков. Поиск нужных элементов может быть сложным делом, особенно в тех случаях, когда у них нет уникальных идентификаторов или имен классов. Это руководство поможет вам профессионально находить любые веб-элементы.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Это завершающие заметки к серии статей про исследовательское тестирование API.

Исследовательское тестирование API, часть 3

Исследовательское тестирование API, часть 2

Исследовательское тестирование API, часть 1

Давайте вернемся к исходному вопросу:

Тестируете ли вы API исследовательским методом? Как?

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Люди довольно серьезно настроены в отношении BDD. Я часто слышу, скажем, такие мнения:

"Зачем мне использовать BDD-фреймворк вместо традиционного – например, JUnit, NUnit, pytest? Дополнительный уровень шагов Gherkin мешает коду автоматизации, и вместо него я могу напрямую писать код для этих шагов. BDD-фреймворки требуют кучу лишней работы, а толку от этого никакого. Моя команда все равно не пользуется практиками разработки через реализацию поведения".

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

Меня зовут Виталий Котов, я довольно много занимаюсь автоматизацией тестирования и мне это нравится. Недавно я участвовал в проекте по настройке автоматизации «с нуля» на стеке TypeScript + Protractor + Jasmine. Для меня этот стек был новым и необходимую информацию я искал на просторах интернета.

Самые полезные и толковые мануалы мне удалось найти только на английском языке. Я решил, что на русском тоже надо такой сделать. Расскажу только основы: почему именно такой стек, что надо настроить и как выглядит самый простой тест.

Сразу оговорюсь, что довольно редко работаю с NodeJS, npm и в целом с серверным JavaScript (тем более с TypeScript). Если где-то найдете ошибку в терминологии или какое-то из моих решений можно улучшить — буду рад узнать об этом в комментариях от более опытных ребят.

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Это последняя часть моего цикла статей о ретроспективных уроках автоматизации. Мне кажется, я достаточно выразил свою философию тестирования и личный опыт. Последнее, чем я хочу поделиться, относится к проекту, с которым я работаю уже год, и касается создания автоматизированных проверок API бэкэнда, который мы сейчас разрабатываем. Мы пишем тесты на PHP во фреймворке Codeception. Я не буду углубляться в особенности фреймворка – я сфокусируюсь на базовых вещах. Итак, вот они – уроки по тестированию API, которые мне нелишним было бы знать заранее – до того, как я изрядно налажал.

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Допустим, вы отвечаете за изначальную подготовку набора автотестов в вашей команде. Используя ваш основной компьютер, вы создали все сценарии, тщательно их протестировали, и теперь они готовы к использованию. Они основаны на существующем смоук-наборе тестов, и вы планируете запускать их при каждом деплое – теперь этим не нужно заниматься тест-команде. Автоматизация имеет бешеный успех и бережет кучу времени тестировщика еженедельно! Вы планируете заслуженный отпуск – всего на недельку.

Кто будет запускать автотесты в ваше отсутствие?