Home

Автор: Пол Меррил (Paul Merrill)

Оригинал статьи: https://techbeacon.com/5-ways-simplify-your-automated-test-cases

Перевод: Ольга Алифанова

Поддержка автотестов может занимать много времени, как и понимание отчетности по ним. К счастью, эти процессы можно ускорить.

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

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

29 июня в Харькове прошла тринадцатая встреча Smart Club for Smart Talks, где специалисты по тестированию могли услышать два интересных доклада на темы: «Как узнать, когда пора автоматизировать и с чего начать» Марка Курченко и «HP LoadRunner: expectations vs reality» Игоря Колосова.

Первый спикер рассказал, чем отличается автоматизация от мануального тестирования.
О том, какой язык предпочесть, какие фреймворки выбрать, TDD, BDD, DDD, Selenium)
А также об SQL, REST, SOAP, HTML/CSS, GIT и прочем.

Второй докладчик поделился опытом использования линейки продуктов для нагрузочного тестирования от Hewlett Packard, рассказал о том, как менялось его мнение на разных стадиях знакомства с инструментарием и дал несколько полезных советов тем, кто возможно столкнется с HP LoadRunner.

Ниже вы можете ознакомиться с записями докладов:

Автор: эксперт по инженерным практикам в Альфа-лаборатории Асеева Анастасия.

Оригинальная публикация: https://habrahabr.ru/company/alfa/blog/331434/

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

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

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline. 

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

Автор: Михаль Димек (Michal Dymek)

Оригинал статьи: https://michaldymek.me/postman-devoted-friend-api-testing

Перевод: Ольга Алифанова

Сидел я как-то раз, работал, и внезапно (ну, как обычно) один из наших проектных менеджеров возник передо мной с вопросом:

- Не можешь ли ты помочь с нашим внутренним проектом?

- Конечно, почему нет! – сразу же откликнулся я.

Я только начинал свой путь в QA, и многого еще не знал, но если опытный сотрудник просит твоей помощи, что еще остается сделать?

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

К счастью, они прислали мне рекомендацию, какие инструменты лучше всего использовать для тестирования через API, а также полную документацию на продукт (в Swagger, с этим я тоже раньше не сталкивался). Инструментом был Postman. Поначалу я боролся с ним методом проб и ошибок, но затем наши отношения наладились. Теперь я благодарен за этот опыт – я люблю Postman и постоянно его использую. В этой статье я хочу показать вам, почему работать с Postman очень легко и выгодно.

Итак, начнем с самого начала.

В июне в офисе Avito прошла встреча опытных iOS-разработчиков, где одной из главных тем было тестирование. Предлагаем посмотреть записи выступлений Никиты Анисимова на тему Автотесты в iOS, в котором он говорит о процессе разработки мобильных приложений iOS Почты Mail.Ru & myMail и системе для автоматизации проверок приложения, показывает, как стабильно выполнять более 500 UI-тестов на каждое изменение в проекте, а также обращает внимание слушателей на необычные векторы для дополнительных проверок, и Виктора Брыксина на тему Как всё починить и ничего не сломать: работа со сложным кодом при помощи тестов, где он рассказывает, как внести функциональные изменения в плохо спроектированный код в разумные сроки и при этом ничего не сломать, о возможных проблемах, ошибках в процессе и о том, как с ними справляться.

В эту субботу 23 сентября сообщество автоматизаторов и сочувствующих COMAQA проведет очередную большую конференцию выходного дня, посвященную автоматизации тестирования и сопутствующим вопросам обеспечения качества. 22 доклада в 5 секциях от специалистов из ведущих IT-компаний Беларуси, России и Израиля. Наш специальный гость Adam Carmi - сo-founder и CTO одного из ведущих инструментов автоматизации визуального тестирования Applitools. Так же нас ждет 2 обеда для неформального общения и удовлетворения не только духовных потребностей и камерное after party.

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

Полная сетка докладов и билеты ищите на официальном сайте конференции.

Про то, что на нашей онлайн-конференции КОТэ помимо докладов будут мастер-классы, мы уже писали отдельным постом.

Чем мастер-класс отличается от обычного доклада?

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

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

Разбор ответов и рекомендации тренеров прозвучат во время конференции, но никто не мешает выполнить задание «для себя». Практики мало не бывает  Да и регистрация на конференцию еще работает...

Задания для мастер-класса по заведению дефектов от Ольги Назиной

Задания для мастер-класса «Десять правил построения хороших локаторов» от Алексея Баранцева

Задания для практического мастер-класса по проведению проектной ретроспективы от Натальи Руколь

Оригинальная публикация: https://habrahabr.ru/company/agima/blog/337818/

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

Не будет нам обоим накладно

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