Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
Большинство руководителей в IT-сфере выросли из технарей. Нам комфортнее работать с программами, чем с людьми, а слово “сервер” нам ближе и понятнее, чем слово “мотивация”. Чтобы решить эту проблему, биг-боссы компаний приглашают сторонних коучей и экспертов по мотивации, а IT-менеджеры пытаются ломать себя и следовать правилам с тренингов: хвалить, давать обратную связь, мотивировать и стимулировать. Такие натянутые действия тоже не приводят ни к чему хорошему!
Оказывается, люди мотивированы всегда, и их не надо пинать! Вопрос не в том, мотивированы они или нет, а в том, что мешает раскрытию их максимального потенциала.
В своём докладе Виктория расскажет о том, как решили эту задачу в Лаборатории качества, внедрив новую парадигму Менеджеров Счастья. В числе тех инструментов, которые помогли им, и которыми автор поделится с вами:
* анализ проблем, хотелок и пожелалок наших любимых сотрудников; * обучение линейных руководителей менеджменту счастья; * совместная проработка общих целей; * решение не поверхностных, а корневых проблем.
Не нужно создавать созданное, нужно научиться применять имеющееся. Все проще, чем кажется.
Если поискать в Интернете список мнемоник тестирования, можно найти более 30 мнемоник, связанных с тестированием. Одна из наиболее известных эвристик (мнемоник)– это SFDPO (San Francisco Depot), созданная Джеймсом Бахом. Мнемоники не только помогают держать в голове важные разделы, которые нужно покрыть во время тестирования – они также могут поспособствовать генерации новых идей.
Мнемоника MOBILE APP TESTING
Тестируя мобильные приложения, я в основном пользуюсь мнемоникой I SLICED UP FUN, созданной Джонатаном Колом. Она помогает мне сконцентрироваться на различных областях наших приложений. Сегодня я хочу поделиться своей собственной мнемоникой – она называется MOBILE APP TESTING. Правда, легко запомнить? Ниже – подробное описание мнемоники с объяснениями, подсказками и ресурсами, которые помогут вам тестировать мобильные приложения.
Heisenbug 2018 Moscow стартует уже на следующей неделе. На конференцию приезжают лучшие специалисты по тестированию и разработке. Но это еще не все!
У вас будет возможность познакомиться с одним из топовых блогеров русского ютуба, который ведет популярный канал о технологиях и ПО.
На заключительном кейноуте первого дня конференции выступит Валентин Wylsacom Петухов! Он расскажет об epic fails производителей девайсов и почему у новейшего Google Pixel 3 выросла вторая «бровь».
А еще на Heisenbug 2018 Moscow приедет Алексей Баранцев, он занимается тестированием аж с 1994 года!
Сейчас Алексей разрабатывает ядро в проекте Selenium WebDriver, а также развивает главный российский портал про тестирование Software-Testing.ru. Организаторы Heisenbug взяли у него интервью и опубликовали в своем хабраблоге.
Вы узнаете, что изменилось в представлениях о тестировании, как развивается Software-Testing.ru, какой браузер лучше всех реагирует на баг-репорты и, конечно же, насколько тщательно протестирован сам Selenium.
На конференции Алексей расскажет о том, с какими сложностями встречаются разработчики популярного инструмента Selenium, как они их решают и как сообщество контрибьютеров помогает в разработке этого инструмента.
О, благословенная страна тест-автоматизации, сберегающая столько денег, времени и сил! Мы беремся за автоматизацию, чтобы повысить эффективность и частоту проверок, однако большая часть усилий в области автотестов пропадает впустую. Это плохо, если учитывать, что правильно внедренные автотесты очень выгодны.
В проекте по начислению пенсии мы внедряли решение по автоматическому приему, отказу или постановку в очередь на ручную обработку уведомлений о состоянии здоровья – в зависимости от четырех разных оценок. Пока оно внедрялось, я сделала автоматизированный набор тестов, управляемый через данные, проверяющий все возможные комбинации и диапазоны оценок.
Финальный тест был запущен спустя месяц разработки и занял десять минут. Вообще-то пять, но менеджер проекта не верила своим ушам и заставила меня прогнать его повторно.
Этот проект отлично подходил для автотестов, но не все проекты так же хороши. Я собрала ряд рекомендаций для тех, кто раздумывает над внедрением автотестов.
30 ноября в московском офисе Mail.Ru Group пройдёт митап, полностью посвящённый мобильному тестированию.
Приходите поделиться опытом и пообщаться!!
Андрей Копейко (Mail.Ru Group) раскроет секреты построения «headless» Android-эмулятора для UI-тестирования дизайнерских приложений (спойлер: стандартными средствами такого не достичь);
Слава Фролов (Badoo) научит на какие грабли не наступать при переводе автоматизированных тестов на iOS12, а также расскажет о взаимодействии с отделом ручного тестирования, девелоперами и релиз-инженерами в процессе;
Дмитрий Меркурьев (AvitoTech) в своем докладе «Andorid CI: Impact Analysis» рассмотрит подход к оптимизации CI через анализ изменений проекта.
А еще в завершении дня у участников будет возможность вместе с экспертами обсудить преимущества и недостатки нативных инструментов автоматизации и Appium.
Если вы сталкивались с автоматизацией тестирования, то это, скорее всего, были автотесты для web-страницы, web-блога, web-интерфейса. Возможно, ваша команда использует Appium для функционального тестирования мобильного приложения или инструментальные тесты Android (Espresso).
Но в 2018 году всё ещё нужно разрабатывать десктопные приложения, поддерживать legacy-проекты. Банки, финансовые отделы компаний, производства и лаборатории, сегмент HoReCa применяют Windows Desktop-приложения. Множество бизнесов разных направлений применяют их для учета, организации и автоматизации бизнес-процессов.
Пользовательская машина дает не меньше возможностей, чем web. А иногда и больше. Например, это работа с локальными файлами и устройствами: обработка больших данных, возможность использовать специфичное оборудование, обращаться к различным сервисам. Причин для сохранения десктопных приложения масса:
Подключение внешних устройств. К примеру, использование сканера отпечатков пальцев для идентификации, сканера паспорта и других устройств.
Соблюдение политики безопасности. Например, на заводе или в банке, где запрещен выход в Internet.
Уже существующий парк машин, который может состоять, например, из PС на OC Windows 7.
Всё вышеперечисленное — потребности реальных заказчиков, и достижения web для таких задач неприменимы.
Вы когда-нибудь задумывались о том, что команде, которая что-то разрабатывает, тестировщик или разработчик автотестов на самом деле не нужен? Этой команде необходим человек, который будет совмещать свою роль с ролью тестировщика.
Давайте рассмотрим традиционное положение вещей.
Если у вас не agile, то у вас скорее всего есть:
-отдел разработки;
-отдел аналитиков;
-отдел тестирования
И все они могут одновременно работают над разными продуктами.
А если вы еще решили делать автоматизацию тестирования, то появляется еще отдел автоматизации тестирования. И для управления всем этим добром, как правило, нужен руководитель проектов (РП). А теперь внимание, что делать РП, у которой тестировщика нет? Или он ушел в отпуск, или заболел?
-Забивать на качество продукта?
-Ждать когда он вернется?
-И нести финансовые потери от несвоевременного запуска продукта или же наоборот, от того что продукт выпустили в «забагованном» состоянии.
Если же у вас agile, то проблемы остаются те же. Только тут, как правило 1 тестировщик и 1 разработчик автотестов на команду, как минимум.
И тут помимо озвученных вопросов, возникает еще вопрос:
-Что делать, если этих двух людей на один проект? Проект не генерирует такую нагрузку для двоих?
-Что делать, если разработчик автотестов отказывается заниматься функциональным тестрованием, если вы оставляете его одного в команде?
-Или же, если тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно?
В своем докладе автор расскажет о том, что такое кроссфункциональная команда. Расскажет, как на своем примере «затащили» роль тестировщика в каждого члена команды, а также от безвыходности и необходимости автоматизации тестирования научили разработчиков писать и помогать поддерживать автотесты тестировщикам.
Сознаюсь в страшном: я считаю тест-кейсы. Прежде чем возмущаться, читайте дальше. Я считаю кейсы с целью понять, сколько у нас чего где в наличии. Вот пример таких подсчетов – "30 тест-кейсов автоматизированы", чтобы понимать, сколько концептуальных программных частей у нас есть, или "добавлено 100 строк функциональности, а количество юнит-тестов не изменилось". Подсчеты довольно полезны, но ими дело не ограничивается.
С другой стороны, прошло как минимум восемь лет с тех пор, как я в последний раз подсчитывала тест-кейсы, чтобы понять, сколько их в ручном наборе, сколько их них прошло и сколько упало, и сколько еще предстоит создать, исследуя продукт. Точнее, прошло восемь лет с тех пор, как кому-либо удавалось заставить меня написать тест-кейс, или поручить эту задачу кому-то еще. Вместо этого я пишу тест-кейсы как автотесты, и высвобождаю время на исследовательское тестирование.
