Что пишут в блогах

Подписаться

Онлайн-тренинги

Разделы портала

Про инструменты

Лучшие вакансии

.
Гейзенбаг 2017 Piter - доклады от экспертов в области тестирования
15.05.2017 08:47

До конференции Гейзенбаг 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.

 
Взаимодействие между тестировщиками и разработчиками: проблемы и пути решения
12.05.2017 08:11

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

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

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

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

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

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

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

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

Подробнее...
 
Selenium за 60 секунд
11.05.2017 08:04

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

Оригинальная публикация: 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 без платного сертификата
10.05.2017 08:18

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

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

Подробнее...
 
Ваш API – ваше лицо
05.05.2017 08:10

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

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

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

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

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

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

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

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

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



Подробнее...
 
Гейзенбаг 2016_пятёрка лучших докладов
04.05.2017 08:37

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

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

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

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

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

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

Подробнее...
 
Советы сеньоров: как прокачать знания junior QA
03.05.2017 08:54

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

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

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

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

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

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

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

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

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

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

Подробнее...
 
COMAQA Spring 2017 Сonference – большая конференция выходного дня
02.05.2017 08:05

Добрый день, друзья!

20 мая QA Automation & co сообщество COMAQA.by проведет очередную большую конференцию выходного дня, посвященную автоматизации тестирования и сопутствующим вопросам обеспечения качества. Спикеры из ведущих IT-компаний Беларуси и России соберутся вместе, чтобы рассказать о своем опыте в тестировании. Мы собрали лучшие доклады на различные темы: паттерны и антипаттерны автоматизации тестирования UI и backend-а, многочисленные инструменты автоматизации, тестирование usability и обеспечение Web безопасности, Docker и DevOps, вопросы организации процесса обеспечения качества и многое другое.

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

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

Приходите, будет интересно!

 
Освоение тестирования REST API
28.04.2017 08:36

Автор: Андрей Шальнев

Оригинал публикации: http://quality-lab.ru/rest-api-testing/

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

Немного о REST API и SOAP API

Стоит отметить, что на сегодняшний день есть два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API:

  • REST (от англ. Representational State Transfer – «передача состояния представления») обеспечивает общение между клиентом (как правило, это браузер) и сервером с помощью обычных HTTP-запросов (GET, POST, PUT, DELETE и т. д), передавая информацию от клиента в параметрах самих запросов, информацию от сервера – в теле ответа (который может быть, например, JSON-объектом или XML-документом). REST является архитектурным стилем, а не стандартом.
  • SOAP (от англ. Simple Object Access Protocol – простой протокол доступа к объектам, вплоть до спецификации 1.2) характеризуется использованием HTTP(S)-протокола лишь как транспорта (чаще всего, методом POST). Все детали сообщений (в обе стороны – от клиента к серверу и обратно) передаются в стандартизованном XML-документе. SOAP может работать и с другими протоколами прикладного уровня (SMTP, FTP), но чаще всего он применяется поверх HTTP(S). SOAP является протоколом и имеет спецификацию.
Подробнее...
 
Новости тестирования за вторую половину апреля
27.04.2017 12:05

Вышел выпуск рассылки за вторую половину апреля, его содержание доступно по ссылке.

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Подписаться на рассылку можно по ссылке.

 
Ловите изменения, пока они не стали проблемами
27.04.2017 08:24

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2017/01/16/catching-changes-before-they-become-problems/

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

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

Чувствуете ли вы, что это неплохой фильтр, который изловит практически любой внедренный баг?

Как вы будете себя чувствовать, когда узнаете, что был найден баг, а ваш зелененький прогон будет улыбаться вам с экрана? Не очень?

"Почему тесты этого не уловили?" Хм.


Причина

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

Я мог уже об этом писать где-то: код – это органическая структура.

Возможно, странно говорить так о коде. Но мы говорим о неодушевленных предметах, что у них есть личность – так и код впитывает природу и характер человека, который его пишет.

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

О многом просто забывают. Или в продукт вносятся изменения, а люди еще не в курсе, что автоматизация эти изменения не учитывает.

После того, как ваши автотесты написаны и дают вам достойную доверия обратную связь, как вы узнаете, что настала пора менять и пополнять их?

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

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

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

Если мы думаем, что у нас вполне приличный набор тестов, мы можем начать думать, что он не нуждается в добавлениях. Он полон, и мы, возможно, не стремимся к 100% покрытию, нам вполне достаточно 70-80%, и их мы получаем.

И даже в этом случае что-нибудь да просочится через нашу защиту.

Это происходит, как правило, редко, но если какой-нибудь "не тот" баг прокрадется в релиз, это станет проблемой для компании.

Пытаться решить вопрос "как протестировать добавленное" довольно сложно. Зато вполне легко решить вопрос "как определить, когда что-то добавлено".

Подробнее...