Если вы сталкивались с автоматизацией тестирования, то это, скорее всего, были автотесты для web-страницы, web-блога, web-интерфейса. Возможно, ваша команда использует Appium для функционального тестирования мобильного приложения или инструментальные тесты Android (Espresso).
Но в 2018 году всё ещё нужно разрабатывать десктопные приложения, поддерживать legacy-проекты. Банки, финансовые отделы компаний, производства и лаборатории, сегмент HoReCa применяют Windows Desktop-приложения. Множество бизнесов разных направлений применяют их для учета, организации и автоматизации бизнес-процессов.
Пользовательская машина дает не меньше возможностей, чем web. А иногда и больше. Например, это работа с локальными файлами и устройствами: обработка больших данных, возможность использовать специфичное оборудование, обращаться к различным сервисам. Причин для сохранения десктопных приложения масса:
Подключение внешних устройств. К примеру, использование сканера отпечатков пальцев для идентификации, сканера паспорта и других устройств.
Соблюдение политики безопасности. Например, на заводе или в банке, где запрещен выход в Internet.
Уже существующий парк машин, который может состоять, например, из PС на OC Windows 7.
Всё вышеперечисленное — потребности реальных заказчиков, и достижения web для таких задач неприменимы.
Вы когда-нибудь задумывались о том, что команде, которая что-то разрабатывает, тестировщик или разработчик автотестов на самом деле не нужен? Этой команде необходим человек, который будет совмещать свою роль с ролью тестировщика.
Давайте рассмотрим традиционное положение вещей.
Если у вас не agile, то у вас скорее всего есть:
-отдел разработки;
-отдел аналитиков;
-отдел тестирования
И все они могут одновременно работают над разными продуктами.
А если вы еще решили делать автоматизацию тестирования, то появляется еще отдел автоматизации тестирования. И для управления всем этим добром, как правило, нужен руководитель проектов (РП). А теперь внимание, что делать РП, у которой тестировщика нет? Или он ушел в отпуск, или заболел?
-Забивать на качество продукта?
-Ждать когда он вернется?
-И нести финансовые потери от несвоевременного запуска продукта или же наоборот, от того что продукт выпустили в «забагованном» состоянии.
Если же у вас agile, то проблемы остаются те же. Только тут, как правило 1 тестировщик и 1 разработчик автотестов на команду, как минимум.
И тут помимо озвученных вопросов, возникает еще вопрос:
-Что делать, если этих двух людей на один проект? Проект не генерирует такую нагрузку для двоих?
-Что делать, если разработчик автотестов отказывается заниматься функциональным тестрованием, если вы оставляете его одного в команде?
-Или же, если тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно?
В своем докладе автор расскажет о том, что такое кроссфункциональная команда. Расскажет, как на своем примере «затащили» роль тестировщика в каждого члена команды, а также от безвыходности и необходимости автоматизации тестирования научили разработчиков писать и помогать поддерживать автотесты тестировщикам.
Сознаюсь в страшном: я считаю тест-кейсы. Прежде чем возмущаться, читайте дальше. Я считаю кейсы с целью понять, сколько у нас чего где в наличии. Вот пример таких подсчетов – "30 тест-кейсов автоматизированы", чтобы понимать, сколько концептуальных программных частей у нас есть, или "добавлено 100 строк функциональности, а количество юнит-тестов не изменилось". Подсчеты довольно полезны, но ими дело не ограничивается.
С другой стороны, прошло как минимум восемь лет с тех пор, как я в последний раз подсчитывала тест-кейсы, чтобы понять, сколько их в ручном наборе, сколько их них прошло и сколько упало, и сколько еще предстоит создать, исследуя продукт. Точнее, прошло восемь лет с тех пор, как кому-либо удавалось заставить меня написать тест-кейс, или поручить эту задачу кому-то еще. Вместо этого я пишу тест-кейсы как автотесты, и высвобождаю время на исследовательское тестирование.
Были ли у вас когда-либо трудности с объяснением возможного бага разработчику, архитектору, проектному менеджеру? Бывает ли, что вас не понимают, или вы не понимаете других участников команды, обсуждая систему проекта или другие абстрактные концепции? Вы не одиноки. Большие и сложные системы влекут за собой возможность абсолютного отсутствия единства их понимания среди коллег. Эта статья рассматривает использование символов и рисунков как инструмента, который поможет вам понимать и объяснять сложные системы.
Приходя на новый проект, команда «Лаборатории качества» всегда закладывает время на первичное знакомство с ПО, даже если клиент уверяет, что «документация полнейшая», а «продукт простейший». Мы вежливо киваем, но предупреждаем, что в течение одной-двух недель наши инженеры по тестированию будут регулярно забрасывать «очевидными» вопросами всех, до кого смогут дотянуться. Потому что никаких «очевидных» вопросов и «само собой разумеющихся» ответов не существует, идет ли речь о стандартном банковском ПО или простом интернет-магазине. Вскоре и сам заказчик начинает понимать, что сервис кажется простым только ему и разработчикам. А вот тем, кто видит его впервые, многие решения могут показаться, мягко говоря, не очень понятными и логичными.
В докладе вы узнаете о проблематичных зонах в тестировании клиентской части мобильного приложения на примере команды звездолета Дискавери, которая тестировала свой новый фичер - споровый двигатель.
А также подумаем, что с ними (зонами) делать, чтобы не повторять ошибки команды и получить приложение наивысшего качества.
Давайте вначале разберемся, что подразумевается под словом "план". Мы с Джеймсом Бахом говорим о планировании (и учим планировать в курсе Rapid Software Testing), понимая план как сумму или пересечение стратегии и логистики. Стратегия – это набор идей, направляющих ваш тест-дизайн. Логистика – это набор идей, направляющих распределение ваших ресурсов. Объедините их, и получится план. Тут очень важно отметить, что план – это не физический предмет - это набор идей. Следовательно, важно различать план и документацию по планированию – то есть документы, содержащие какую-то касающуюся плана информацию.
Вопрос, что должно входить в тест-план, можно интерпретировать двояко – во-первых, как вопрос про "план", а во-вторых, как вопрос о документации планирования. Начнем с плана.
8 недель курса мы объясняли сложные термины простым языком, давали домашние задания, отправляли обратную связь и отвечали на вопросы. Мы сказали всё, что было возможно, во время занятий. А теперь пришло время дать слово нашему первому выпуску ПОИНТ (Первый Онлайн ИНститут Тестировщиков).
1 344 часа обучения. Как это было?
«Я прошла курс ПОИНТ на одном дыхании! Грамотно выстроенный процесс помогает плавно влиться в курс. Всё идёт в порядке возрастания и нагрузка не так ощутима. Преподаватели всегда разъясняют, что к чему, постоянно на связи. В самом курсе много информации, но она структурирована; и даже если кажется, что вы это уже знаете, то обязательно почерпнете для себя что-нибудь полезное. Ставлю курсам твёрдую 5! Вы большие молодцы. Однозначно рекомендую, курсы полезные»
Мария Б.
«Эти 2 месяца были очень насыщенными, интересными и, лично для меня, полны открытий. Придя на курс, я уже имела опыт работы в IT, хоть он был и до декрета, и также имела представление о тестировании (книга Савина и некоторые материалы из рассылки Форума тестировщиков). Основной целью было систематизировать и освежить свои знания.
В результате я получила значительно больше! Мне очень понравилось, что вы дали значительный список инструментов, с которыми я не была знакома. Да и навряд ли я освоила бы некоторые из них самостоятельно. Материал в целом подавался очень доходчиво, но порой его не хватало и хотелось больше».
Только 4 декабрявсе технологии по нагрузочному тестированию из первых уст от Перформанс Лаб, Сбербанк Технологии, Райффайзен банка.
Рады сообщить, что 4 декабря в Москве пройдет V юбилейная конференция по нагрузочному тестированию, организованная компанией Перфоманс Лаб, при поддержке известных вендоров и лидеров в данной отрасли. Из маленькой «дружеской» конференции тестировщиков, мероприятие переросло в марафон от ведущих компаний России, которые готовы открыто поделиться своим опытом.
Конференция не такая, как все. И вот почему:
1. Все практики и технологии только по теме Нагрузочное Тестирование. Ничего лишнего!
2. На конференции выступают спикеры известных IT-компаний России, вендоры. Они делятся реальным практическим опытом. Только технические доклады, никакой рекламы.
3. Материал доносится в понятной и доступной форме.
4. По окончании мероприятия каждый участник получит сертификат участника конференции.
5. Профессиональная среда и новые контакты.
Какие новые знания Вы получите на конференции:
1. Узнаете какие подходы будут использоваться для тестирования распределенных сетей в будущем и зачем нужен блокчейн в нагрузочном тестировании.
2. Узнаете какие выбрать инструменты при работе с высоконагруженными проектами, с примерами и тонкостями использования.
3. Как составлять профиль нагрузки в сложных ситуациях, и как поступить если вы встретились с криптографией в проекте по тестированию.
4. Как автоматизировать нагрузочное тестирование, и применить навыки DevOps.
В данной статье я бы хотел рассказать об особенностях мобильного тестирования и переходе от ручного тестирования к автоматизации на примере одного из наших проектов, в котором мы тестировали приложение для фитнес-девайса.
Специфика проекта
Данный проект был международным и распределенным территориально. Все коммуникации, процессы и артефакты были на английском языке. В проекте участвовали команды из Индии, центральной России, Москвы и Эль–Сальвадора, главный офис заказчика – в Калифорнии.
Мы занимались тестированием приложения, написанного для конкретного фитнес-девайса: приложение нельзя было просто скачать из магазина и приступить к работе. Также требовалось уделить особое внимание взаимодействию девайса с телефоном и приложением.
Наше общение с Заказчиком началось с того, что они не смогли самостоятельно пройти предрелизные проверки для добавления своего приложения в AppStore и Google Play. Как следствие, для начала нам потребовалось провести тестирование по гайдлайнам от Apple и Google.
Как это нередко бывает в мобильной разработке, iOS версия опережала на пару спринтов Android и все новые фичи сначала появлялись для IOS.
На старте проекта не было документации, и она появлялась только на новые фичи.
