Home

Осенью прошлого года сразу в трех городах состоялась традиционная конференция ITsubbotnik ЕРАМ, на которой специалисты по информационным технологиям рассказывали о разработке и тестированию ПО.

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

1. Павла Лебедя и Сергея Мишанина об автоматизировании мобильного web, о специфических проблемах с технологиями и их решениях.

2. Дмитрия Гуменюка о том, как использовать автоматизацию правильно.

3. Антона Туляганова о том, что необычного в тестировании VR/AR.

4. Антона Шапина о сложном и тернистом, но интересном переходе из ручных тестировщиков в автоматизаторы.

До конференции Гейзенбаг 2017 Piter осталось меньше месяца. Программа готова на 95%, а это значит, что уже можно принять окончательное решение об участии.

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

Всего будет 17 докладов от известных экспертов в области тестирования:
– 6 докладов по подходам и правильным паттернам в тестировании (Николай Алименков – Паттерны проектирования в автоматизации тестирования, Игорь Хрол – Тестирование в мире данных);
– 3 доклада по тестированию web-проектов (Алексей Лавренюк – Нагрузочное тестирование web-сервиса, Илья Коробицын – Пишем Selenium тесты на JS для тестирования Angular: плюсы, минусы, подводные камни);
– Несколько докладов по фреймворкам, облегчающим тестирование (Артем Ерошенко – Allure 2, Dan Cuellar – Appium: The Language of Automation);
– Пара докладов «вне категорий» (Claudio Criscione – Security testing at a scale).

Почти все доклады так или иначе связаны с автоматизацией тестирования. Как всегда, никакой воды – только хардкор!

Вся программа конференции и регистрация: https://goo.gl/ldbsnl
Для того, чтобы приобрести билеты по специальной цене, используйте ключевую фразу SoftwareTestingPromo.

Автор: Людмила Лихогляд, ведущий специалист по тестированию "Лаборатории Качества"

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

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

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

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

Типы взаимоотношений

Для понимания сути проблемы приведем классификацию взаимоотношений в рабочей группе, предложенную американскими исследователями Блейком и Myтoном и учитывающую комбинацию двух основных параметров – взаимоотношения сотрудников и их отношения к рабочему процессу.

Выделим 5 основных типов:
1) невмешательство – низкий уровень заботы как о проекте, так и о коллегах (каждый сам за себя, сотрудники не заинтересованы в совместном конечном результате и не чувствуют себя членами рабочего коллектива);
2) теплая компания – комфортные отношения в коллективе, не направленные на достижение конкретных и устойчивых результатов работы;
3) задача – внимание каждого полностью сосредоточено на решении производственных задач, человеческий фактор недооценивается или просто игнорируется;
4) золотая середина – сотрудники в своей деятельности стремятся оптимально сочетать интересы дела и коллег;
5) команда – наиболее предпочтительный тип взаимоотношений в рабочей группе. Максимально учитывает интересы производства и коллектива, объединяет деловитость и человечность на всех уровнях отношений.

Автор: Александр Андряшин

Оригинальная публикация: https://habrahabr.ru/post/327184/

Представляю вам перевод моей статьи на Medium.com.

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

Проблема

Как веб-разработчик или инженер по автоматизации тестирования вы можете столкнуться со следующими неудобствами при работе со стандартным Selenium сервером:

1. Нужно устанавливать несколько разных браузеров себе на компьютер. В обычной жизни вы, как правило, используете один браузер, например, Chrome, но вам приходится устанавливать себе Firefox и Opera, чтобы отлаживать в них Selenium-тесты.
2. Трудно устанавливать и использовать несколько версий одного браузера. Если вы устанавливаете браузер из пакетов, то вообще можно иметь только одну установленную версию. Кроме того Selenium и его веб-драйверы обычно ищут исполняемый файл браузера по определенному пути. Поэтому, поверьте, использовать несколько версий может быть трудной задачей.
3. Если вы запускаете браузер, установленный в вашей операционной системе — он забивает место на диске своими временными файлами и содержимым кеша.
4. Нельзя гарантировать, что настройки браузера всегда останутся в том же состоянии, как после чистой установки. Например, вы можете случайно изменить адрес прокси-сервера или настройки безопасности. Это может привести к падению ранее работавших тестов.
5. Трудно запускать несколько тестов в разных браузерах параллельно. Попытка сделать это как правило приводит к различным проблемам: окна начинают конкурировать за фокус, не срабатывающие события, не ожидаемые CSS стили и так далее.
6. Нужно знать какая версия Selenium совместима с какой версией браузера. То же самое верно для исполняемых файлов веб-драйверов (например, Chromedriver).

Приведенный выше список недостатков далеко не полный. Но давайте остановимся на этом и попробуем гораздо более удобный способ отладки Selenium-тестов локально.

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

По крайней мере, так было до недавнего времени. С выходом Xcode 8 Apple сняла это ограничение, и теперь можно подписывать приложения, даже не участвуя в этой программе. Однако этот факт до сих пор малоизвестен, к тому же нужно очень чётко следовать правилам, чтобы у вас получилось подписать приложение. В этом видео, которое является частью курса “Тестирование мобильных приложений”, рассматривается схема подписывания и установки приложения на iOS-устройство:

Автор: Юлия Багрий

Оригинальная публикация: http://quality-lab.ru/your-api-is-your-public-face/

Для начала нам нужно понять, что же такое API?
API (Application Programming Interface) – это интерфейс, который позволяет осуществлять взаимодействие между программами. Если человек общается с приложением через кнопки и диалоги (пользовательский интерфейс, UI), то программы обмениваются информацией друг с другом через API.

Категории взаимодействия API

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

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

Основные риски, связанные с внутренним API, – это функциональные дефекты и проблемы производительности. Здесь пользователи могут лишь предполагать, из-за чего конкретно приложение работает «как-то не так».

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

Подробно остановимся на втором варианте. Предоставление API является для некоторых главным бизнесом (те же социальные сети и платежи), для других же – приятным дополнением к основному сервису. Но в любом случае форма реализации и представления API, образно говоря, «приоткрывает дверь во внутреннюю кухню» разработки. И вот тут уже «спрятаться» за красивым дизайном и саппортом не получится.

4 июня 2017 года в Санкт-Петербурге состоится Гейзенбаг 2017 Piter - большая техническая конференция, которая соберет более 400 специалистов в области тестирования (не только тестировщиков, но и разработчиков, тимлидов и CTO). В преддверии этого события хотим предложить вам посмотреть видео 5 лучших докладов с прошлогодней конференции, проходившей в Москве.

1. Филипп Кекс (Creative Mobile) — Как научить роботов играть в игры?

2. Александр Баяндин (Badoo) — ChromeDriver Jailbreak

3. Дэн Куайяр (Appium) — Appium: Automation for Apps

4. Станислав Башкирцев (EPAM) — Рандомизированное тестирование

5. Владимир Ситников (Netcracker) — Подводные камни в нагрузочном тестировании

Оригинальная публикация: https://dou.ua/lenta/articles/senior-qa-tips/

Ярослав Пернеровский, Test Automation Lead в GlobalLogic, 12 лет в тестировании:

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

И тут уже критически важно владеть так называемыми «софт скилами»:

• правильно задавать вопросы;
• грамотно объяснять (касается также и написания баг репортов, тест кейсов и т.п.);
• уметь слушать.

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

Если все же стоит цель именно «прокачать» что-то, то тут самое важное сконцентрироваться на чем-то одном. Например, очень сложно «выучить все тестирование». Гораздо проще освоить «тестирование конкретного приложения». Для этого нам понадобится само приложение и гугл. Остаемся с приложением один на один и пытаемся «тестировать» именно его. Искать проблемы, пытаться эти проблемы документировать, гуглим, как правильно это делать, делимся репортами с разработчиками или знакомыми. Пытаемся разобраться, как оно работает, какие технологии под капотом и т.д.

Что касается навыков, которыми должен владеть начинающий тестировщик, то в первую очередь это язык. Можно, конечно, Java или Python, но лучше английский! Хотя бы на уровне — читаю блоги без словаря.

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

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