Home

Автор: Дэн Эшби (Dan Ashby)
Оригинал статьи
Перевод: Ольга Алифанова

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

У моего сына Ангуса довольно давно есть игрушка-ходилка. Она помогла ему удерживать равновесие – сейчас, в возрасте 17 месяцев, он носится очень шустро, и нет сомнений, что в том есть заслуга игрушки.

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

Автор: Сунагатов Ильдар, Юшкова Юлия (Haulmont)

Оригинальная публикация

Автор: Владимир Янц (Badoo)
Оригинальная публикация

Как оценивать качество тестов? Многие полагаются на самый популярный показатель, известный всем, — code coverage. Но это количественная, а не качественная метрика. Она показывает, какой объём вашего кода покрыт тестами, но не то, как хорошо эти тесты написаны. 

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

На Badoo PHP Meetup в марте я рассказывал, как организовать мутационное тестирование для PHP-кода и с какими проблемами можно столкнуться. Видео доступно по ссылке, а за текстовой версией добро пожаловать под кат.

Автор: Энди Найт (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-фреймворки тест-автоматизации лучше, нежели традиционные, для большей части тестирования характеристик (на уровне выше юнит-тестов, для черного ящика). И вот почему.