Home

Автор: Андрей Алексеев (aa0ndrey)

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

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

Все примеры с кодом написаны на Java, но без использования каких-либо фреймворков и специфичных библиотек. Это сделано для того, чтобы статья была понятна читателям вне зависимости от их применяемого стека технологий.

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

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

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

В этой серии статей я углублюсь в четыре столпа (фундаментальных принципа ) объектно-ориентированного программирования:

• Инкапсуляция
• Наследование
• Полиморфизм (эта статья)
• Абстракция

Автор: Валентин Агапитов

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

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

Автор: Куликов Дмитрий 

На сайте hh.ru есть около 100 вакансий, где навык составления XPath важен для работодателя, также в интернетах полно материалов, вроде шпаргалок по составлению локаторов или ворк-шопов на ютубе. Как-то у меня спросили на собеседовании про то, какой из языков построения локаторов использовать лучше XPath vs CSS, и я ответил — лучше использовать тестовые аттрибуты, а если мы их используем то и использовать эти языки необязательно. Скорее всего такой ответ не устроил, но я ответил честно, т.к на предыдущем месте мы старались не использовать XPath для решения этой задачи

.

Автор: Александр Романов (Oleksandr Romanov)
Оригинал статьи
Перевод: Ольга Алифанова

Действительно ли легко писать и поддерживать UI-тесты? Действительно ли юнит- и интеграционные тесты – самые сложные?

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

Автор: Марк Уинтерингэм (Mark Winteringham)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Недавно я слушал в Twitter про Page Object vs Screenplay. Это было интересное обсуждение, прозвучало много хороших точек зрения и идей. Затем я написал в Twitter, что эта сессия укрепила меня в убеждении, что автоматизированный стэк подходит для множества вариантов внедрения автоматизации. Стоит ознакомиться с сессией Spaces и тредом в Twitter.

Привет! Меня зовут Александр Шуров, я работаю QAA менеджером в компании Wrike, начинал с позиции QAA инженера в далеком 2010-ом и был первым в этой роли. За 12 лет нам удалось построить крутую команду и создать систему контроля качества, которая позволяет быстро и без багов деплоить продуктовый код в продакшен. 

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

Привет! Меня зовут Артём Комаренко, я работаю на позиции QA Lead в команде PaaS в СберМаркете. Хочу поделиться историей, как мы придумывали способ быстро убедиться, что очередные изменения в скриптах деплоя не разломают процесс выкатки во всей компании. 

Статья будет полезна QA-специалистам и DevOps-инженерам, которые хотят автоматизировать тесты инфраструктуры. Вы узнаете как и с помощью чего можно проверить такую сущность как деплой.

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

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

"К коду тестов нужно относиться так же, как и к коду продукта".

Недели не проходит, чтобы кто-нибудь об этом не заявил в докладе, статье, посте на LinkedIn.

Я согласен. Вы должны обращаться с кодом тестов так же, как и с кодом продукта. Проблема тут в том, что просто заявить "вы должны" недостаточно, чтобы это магическим образом произошло за одну ночь. К сожалению, я крайне редко вижу, чтобы сказавший это человек поделился практически применимыми советами, как же обращаться с кодом тестов аналогично коду продукта.