Принципы «правильной» автоматизации всем хорошо известны, но почему-то даже опытные автоматизаторы не всегда им следуют. Допуская ошибки одну за другой, мы и не замечаем, как укорачиваем жизнь нашим авто-тестам. В результате, нередко случается так, что наши решения со временем забрасываются и не выживают, либо же превращаются в «чемодан без ручки» - когда нести тяжело, а выбросить жалко.
Я предлагаю по-новому взглянуть на автоматизацию в проектах и увидеть общие ошибки. Я расскажу о 10 принципах автоматизации, к которым пришла моя команда на собственном опыте, и которые помогут не наступать на одни и те же грабли.
Доклад смогут «прочувствовать» все тестировщики, работающие на проектах, где есть автоматизация.
QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.QAFest
- История проекта (с чего началось внедрение SCRUM в QA команде, какая была команда и тп)
- Тестирование в идеальном Agilе (как происходит построение процесса в идеале и что мы можем получить)
- Советы тестировщику в Agile
- Показатели или что от нас хочет Product Owner
- Что мы добавили в обычное SCRUM тестирование и какой получили результат
Выводы что дал SCRUM команде и как поменялась
Большинство клиентов, прежде чем покупать "тестирование как сервис" для своих проектов, хотят видеть реальные цифры пользы (вложение/затраты на сэкономленное время/ресурсы), которую им даст данная инвестиция в «качество». Клиенты привыкли слышать, что тестирование, словно по-волшебству, повысит качество.
Я хочу показать конкретные цифры: как визуализировать вот ту самую пользу и дать четкие числа, на основании которых люди, инвестирующие деньги в тестирование, смогут видеть практическую пользу тестирвоания, как ручного, так и автоматизированного. Мы поговорим о метриках в тестировании и KPI, что именно и как собирать, как отслеживать данные непрерывно, как анализировать тренд и презентовать его клиентам.
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...QAFest
В докладе будут представлены самые важные вопросы, которые должен и может задавать окружающим лидер группы тестировщиков перед началом каждого проекта для того, чтобы проект был успешно запилен.
QA Fest 2015. Василий Сливка, Игорь Роздобудько. Кросплатформенное тестирован...QAFest
Хотите автоматизировать мобильные приложения? Хотите делать это быстро и безболезненно? И одновременно на двух платформах?
Эти и другие секреты откроют для вас гуру автоматизации мобильных приложений, которые стояли у первоисточников Calabash - Василий и Игорь
QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.QAFest
- История проекта (с чего началось внедрение SCRUM в QA команде, какая была команда и тп)
- Тестирование в идеальном Agilе (как происходит построение процесса в идеале и что мы можем получить)
- Советы тестировщику в Agile
- Показатели или что от нас хочет Product Owner
- Что мы добавили в обычное SCRUM тестирование и какой получили результат
Выводы что дал SCRUM команде и как поменялась
Большинство клиентов, прежде чем покупать "тестирование как сервис" для своих проектов, хотят видеть реальные цифры пользы (вложение/затраты на сэкономленное время/ресурсы), которую им даст данная инвестиция в «качество». Клиенты привыкли слышать, что тестирование, словно по-волшебству, повысит качество.
Я хочу показать конкретные цифры: как визуализировать вот ту самую пользу и дать четкие числа, на основании которых люди, инвестирующие деньги в тестирование, смогут видеть практическую пользу тестирвоания, как ручного, так и автоматизированного. Мы поговорим о метриках в тестировании и KPI, что именно и как собирать, как отслеживать данные непрерывно, как анализировать тренд и презентовать его клиентам.
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
QA Fest 2015. Алена Черненко-Дыба и Алексей Лупан. Секреты успешного проекта...QAFest
В докладе будут представлены самые важные вопросы, которые должен и может задавать окружающим лидер группы тестировщиков перед началом каждого проекта для того, чтобы проект был успешно запилен.
QA Fest 2015. Василий Сливка, Игорь Роздобудько. Кросплатформенное тестирован...QAFest
Хотите автоматизировать мобильные приложения? Хотите делать это быстро и безболезненно? И одновременно на двух платформах?
Эти и другие секреты откроют для вас гуру автоматизации мобильных приложений, которые стояли у первоисточников Calabash - Василий и Игорь
Концепция построения процесса тестирования в Agile проектах: 3+1LuxoftTraining
13-15 мая 2013 г. прошла онлайн-конференция Chief ConfeT&QA, посвященная различным вопросам тестирования: от методов приоритизации тестирования до синдрома профессионального выгорания в тестировании.
Елена Саламаха, тренер Luxoft Training, представила доклад о трёх основных концепциях построения тестирования в Agile:
• Техники предотвращения появления дефектов
• Автоматизация, Непрерывная интеграция
• Концепция постоянного улучшения, «гибкого внедрения гибкости»
Также в своем докладе Елена ответила на ряд вопросов:
• Как избежать непредвиденных багов?
• Как избежать недопонимания и разночтения требований?
• Как избежать рутинной ручной и, часто лишней, работы?
• Как поддерживать стабильный уровень качества в условиях частых поставок?
• Как не потеряться в постоянных изменениях?
QA Fest 2015. Игорь Хрол. Автоматизация тестирования: отбрасываем лишнее и пр...QAFest
Наиболее популярный вид тестирования, применяющийся на проектах - это тестирование чёрного ящика. Когда решается задача автоматизации тестирования, чаще всего это происходит ʺв лобʺ - в точности повторяя действия пользователя. Это наиболее понятный и простой путь. Но к сожалению, этот путь очень сильно ограничен в своей области применения.
Концепция построения процесса тестирования в Agile проектах: 3+1LuxoftTraining
13-15 мая 2013 г. прошла онлайн-конференция Chief ConfeT&QA, посвященная различным вопросам тестирования: от методов приоритизации тестирования до синдрома профессионального выгорания в тестировании.
Елена Саламаха, тренер Luxoft Training, представила доклад о трёх основных концепциях построения тестирования в Agile:
• Техники предотвращения появления дефектов
• Автоматизация, Непрерывная интеграция
• Концепция постоянного улучшения, «гибкого внедрения гибкости»
Также в своем докладе Елена ответила на ряд вопросов:
• Как избежать непредвиденных багов?
• Как избежать недопонимания и разночтения требований?
• Как избежать рутинной ручной и, часто лишней, работы?
• Как поддерживать стабильный уровень качества в условиях частых поставок?
• Как не потеряться в постоянных изменениях?
QA Fest 2015. Игорь Хрол. Автоматизация тестирования: отбрасываем лишнее и пр...QAFest
Наиболее популярный вид тестирования, применяющийся на проектах - это тестирование чёрного ящика. Когда решается задача автоматизации тестирования, чаще всего это происходит ʺв лобʺ - в точности повторяя действия пользователя. Это наиболее понятный и простой путь. Но к сожалению, этот путь очень сильно ограничен в своей области применения.
I am interested in optical fiber communication and i have knowledge about optical fiber work with experience of 3 years.
I need your kindness.
Thanking you.
Regards,
Fahad ali shah
00923152282082
00923325208712
QA Fest 2015. Сергей Пирогов. Красивые JBehave отчетыQAFest
В докладе я хочу поделиться личным опытом написания кастомного репортера для JBehave. Покажу причины решения написать свой репортер и пути решения проблемы. В конце я покажу как я имплементировал связку Allure report и знаменитого BDD фреймворка для Java - JBehave.
Артём Быковец "Bus Factor - или как контролировать и снижать процессные риски...Fwdays
Ризики низького значення Bus Factor відомі більшості менеджерів, але практика показує, що ці ризики часто ігноруються, або відкладають "на завтра", оскільки у нас безліч ТЕРМІНОВИХ задач і ми не маємо часу займатись розподіленням досвіду між "ключовими" виконавцями та молодими джунами.
Разом розберемо приклади з мого досвіду в яких цей фактор ігнорували і чого це коштувало проектам.
QA Fes 2016. Иван Пашко. Теория Дарвина в тестах. Эволюция Wait-ов.QAFest
Наш код умнеет и совершенствуется вместе с нами. Хорошие пракитики отпечатываются в ДНК наших тестов, и остаются с нами и в новых проектах. Плохие - совершенствуются или отмирают.
В даном докладе мы познакомимся с процессом эволюции wait-хромосомы(примеры на языке .NET). И посмотрим, куда эволюционировать дальше.
В докладе будет изложена информация о том, как можно, при помощи JavaMail API автоматизировать тестирование почтовых рассылок проекта, это: доставляемость писем (задержка получателем, inbox/spam..), проверка контента и служебных заголовков.
Управління ефективністю організації для бізнес-об'єднаньUNDP Ukraine
Презентація до вебінару “Управління ефективністю організації” для керівників, лідерів, фахівців з підбору персоналу членських бізнес-об’єднань малих і середніх підприємств, інших неприбуткових організацій.
Запис вебінару за посиланням https://youtu.be/NgJLtKsQb1I
#itSMFru2014 - Патрик Болджер в секции Мирный КосмосCleverics
Мост в космосе: как правильно использовать SLM
Управление уровнем услуг (SLM) позволяет связать ИТ и бизнес. Связь совершенно необходимая, и тем не менее этого процесса нет более чем в половине внутренних ИТ-служб. В итоге задачи управления ожиданиями, предоставления услуг должного качества за приемлемые деньги решаются нестабильно, бессистемно и не слишком успешно. Реализация процесса SLM может стать основой для существенного улучшения ИТ-услуг в глазах бизнеса и изменить к лучшему отношения Ит-службы с внутренними заказчиками. Патрик расскажет о том, как наладить диалог о качестве услуг, избежать непродуктивного взаимодействия и сосредоточить усилия ИТ-службы на формировании ценности для бизнеса
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 6 июня, 17:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2553.html
Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.
...
Опыт совместной работы хостера (Webzilla) и клиента (CityADS) над достижением...Ontico
Для любого крупного проекта работа над uptime сервиса должна быть постоянной, непрерывной и многовекторной.
Каждый инцидент с доступностью проще всего “свалить” на поставщика услуг хостинга и провайдера. Однако, начиная с определенного уровня масштаба сервиса, такой подход уже начинает стоить бизнесу слишком много.
Данный доклад — это обзор работы над проблемами доступности на пути от клиента до хостера, проведенной с целью достижения доступности сервисов клиента выше 99,99% на примере интернет-компании с оборотом выше 1 млрд рублей.
Ключевая особенность доклада в том, что он максимально объективен в силу того, что каждый докладчик представляет свою сторону "баррикад".
В докладе будут рассмотрены вопросы:
+ Почему хостер — наименьшая из проблем?
+ Какие бывают источники проблем?
+ Как научиться видеть проблемы и построить необходимый базис для своевременного их обнаружения и решения?
+ Третий не лишний — почти всегда между хостером и вами есть еще один источник проблем.
+ Что учитывать в современных реалиях при выборе dedicated / colocation услуг?
+ Чем различаются хостеры, как их сравнить, что от них стоит ждать?
Доклад на бизнес-завтраке «Практика импортозамещения систем управления ИТ» (Москва, 23 апреля 2015 г.).
Спикер: Илья Мальков, руководитель практики систем ЕСМ, Интер РАО
При внедрении на сайт нового функционала могут «поломаться» метрики, передаваемые в Google Analytics. В результате вы получите некорректные данные и, чем позднее выявите ошибку, тем выше будет стоимость ее исправления. Поэтому веб-аналитикам приходится вручную тестировать метрики после обновлений на сайте. В среднем на проверку данных после небольшого релиза уходит до 2 часов.
Хорошая новость в том, что этот процесс можно автоматизировать, чтобы освободить ценное время аналитика на поиск инсайтов и точек роста.
Автотестированию метрик на сайте посвящена эта презентация, а также бесплатный вебинар, который вы можете посмотреть в записи https://www.owox.com/c/3f6.
QA Fest 2019. Сергій Короленко. Топ веб вразливостей за 40 хвилинQAFest
Поговоримо про найпопулярніші помилки, яких припускаються розробники веб додатків, та як зловмисник може використати їх на свою користь. Охопимо максимальну кількість матеріалу за короткий проміжок часу.
QA Fest 2019. Анна Чернышова. Self-healing test automation 2.0. The FutureQAFest
Мы уже разговаривали о self-healing автоматизации, как она работает, какие есть подходы, чем они хороши, плохи и о новом инструменте, который мы разрабатываем в EPAM. Наш продукт завершает стадию POC и настало время поделиться результатами и понять, насколько self-healing автоматизация поможет вашим тестам стать стабильнее? Или наоборот, навредит?... Приходи и узнаешь!
QA Fest 2019. Doug Sillars. It's just too Slow: Testing Mobile application pe...QAFest
Mobile apps and websites are now the predominant ways that users interact with brands. Research has shown that slow sites and apps lose customer engagement. Despite this, most mobile sites and apps have performance issues that can be easily resolved once diagnosed. In this talk, we will walk through steps to diagnose network performance bottlenecks in mobile services. We'll discuss real-world examples and how they were resolved. Attendees will leave this talk armed with the tools to test, diagnose and resolve the top network performance issues that affect mobile today.
QA Fest 2019. Катерина Спринсян. Параллельное покрытие автотестами и другие и...QAFest
Раньше мы в Badoo фокусировались в основным на ручном тестировании. Получался этакий дедлок мануальной регрессии: не было времени, чтоб писать тесты, потому что много тестировали руками, а много тестировали руками, потому что не было автотестов.
Но мы смогли наладить свою систему автоматизации и процессы, разорвали этот порочный круг и начали писать годные тесты.
В своем докладе я расскажу, как нам удалось сократить ручную регрессию с 90% до 30% рабочего времени, при этом сохранить достойный уровень качества и профессионально вырасти!
QA Fest 2019. Никита Галкин. Как зарабатывать большеQAFest
Вам знаком термин mindshift? Именно его вы испытаете от этого доклада. Он будет не о QA процессах или инструментах, он будет о деньгах и бизнесе, о рисках и коммуникациях. Все это с примерами из Украинского и мировом IT в формате живого общения с аудиторией.
QA Fest 2019. Сергей Пирогов. Why everything is spoiledQAFest
In this talk, I will cover the pain points of the Test Automation process. We will discuss traps, mistakes and crazy decisions that lead to test automation failure and lost budgets.
QA Fest 2019. Сергей Новик. Между мотивацией и выгораниемQAFest
Поговорим о мотивации простым языком, проясним, что стимулирует нас работать лучше. Поисследуем обратную сторону мотивации – выгорание. Выясним, как диагностировать выгорание и не допустить неприятных последствий.
QA Fest 2019. Владимир Никонов. Код Шредингера или зачем и как мы тестируем н...QAFest
Для разработки современных программных решений необходимо обеспечить эффективную систему тестирования, которая состоит из большого количества компонентов и задает требования ко всем этапам разработки.
Владимир Никонов, руководитель департамента разработки платформы в Terrasoft, эксперт в области проектирования приложений с опытом работы более 10 лет, поделится экспертным мнением с участниками QA Fest и расскажет:
- об инструментах и процессах на каждом этапе создания и поставки функциональности: от unit-тестов до нефункционального тестирования;
- о требования к инструментам тестирования и компетенциям команды QA-инженеров, которые необходимо выдвигать на каждом этапе тестирования;
- как внедрять современные подходы в существующий проект с минимальными затратами;
- как развивать команду и процессы тестирования в целом.
QA Fest 2019. Владимир Трандафилов. GUI automation of WEB application with SV...QAFest
Доклад посвящен автоматизации тестирования WEB-приложений с SVG-графикой. В 1-ой части доклада даны короткое описание процессов разрабатываемого приложения и обоснование необходимости применения SVG-графики. Во 2-ой части сделан короткий обзор SVG-графики, показаны основные преимущества/недостатки такого типа графики, сделан обзор основных SVG-поверхностей и рассмотрен процесс их трансформации с помощью матрицы преобразования с разбором ее основных типов. В 3-ей части обозначены основные проблемы автоматизации действий с SVG-графикой, такие как drag’n’drop графических объектов (SVG на SVG), их масштабирование при помощи колесика мышки и выделение ломаный линий. В 4-ой части показаны решения обозначенных проблем с использованием JavaScript.
QA Fest 2019. Иван Крутов. Bulletproof Selenium ClusterQAFest
Browser tests are known to be the flakiest ones. This is partly because browser infrastructure is complicated to maintain. But the second reason is – mainstream browser automation tools such as Selenium server are far from being efficient.
A year ago I have shown Selenoid - a truly efficient replacement of the standard Selenium server. This year I would like to demonstrate how to organize a fault-tolerant and easily scalable Selenium cluster using virtual machines in the cloud. I will start by setting up several Selenoid nodes and configure them to send logs and recorded videos to S3-compatible storage. Then I will run multiple Ggr load balancer instances allowing to use all running Selenoid nodes and organize a single entry point to the cluster. Finally, we'll discuss how to work with VNC and video recording in such a cluster.
QA Fest 2019. Николай Мижигурский. Миссия /*не*/выполнима: гуманитарий собесе...QAFest
Случалось ли вам запускать автоматизацию на проекте? Испытывать непревзойденное удовольствие от необходимости собеседовать технического специалиста, когда сам не имеешь технического опыта? Если да, то этот доклад для вас.
Мы научимся анализировать сеньорность кандитата, его технический уровень и способность к организации команд. Но самое главное - все это мы сможем достичь без серьезного технического опыта. Будет интересно, заходи на огонек!
QA Fest 2019. Володимир Стиран. Чим раніше – тим вигідніше, але ніколи не піз...QAFest
Це буде огляд підходів до побудови програми безпеки програмного забезпечення в команді розробки або кампанії загалом, доповнений висновками з мого власного досвіду виконання практичних та консультаційних проектів в сфері Application Security.
QA Fest 2019. Дмитрий Прокопук. Mocks and network tricks in UI automationQAFest
Веб-приложения и технологии стремительно развиваются. Мы уже вступили в эру Single Page Application и идем к Progressive Web Application. В большинстве современных проектов идет разделение команд на front-end и back-end, и не только команд, но идет раздельная релизная политика. Это требует более детальных подходов к тестированию front-end. В этом докладе мы рассмотрим кейсы, который есть на практике при тестировании задач front-end и инструменты автоматизации, которые могут решать задачи описанные в этих кейсах: чтение request/response browser network и соответственно мокирование response.
QA Fest 2019. Екатерина Дядечко. Тестирование медицинского софта — вызовы и в...QAFest
Проектирование и производство медицинских устройств — это регулируемый бизнес. Государственные органы во всем мире призваны гарантировать безопасность и эффективность медицинских устройств. Несоответствие нормативным требованиям ставит под угрозу жизнь и здоровье человека. Как медицинское регулирование влияет на рабочий процесс компании производителя? Мы поговорим о том, какие вызовы стоят перед тестировщиком медицинского софта, а также какие возможности при этом открываются.
QA Fest 2019. Катерина Черникова. Tune your P’s: the pop-art of keeping testa...QAFest
Про «тестабилити» в последнее время говорят часто, зачастую говорят в рамках способности тестировать тот или иной функционал. А иногда и ограничиваются только возможностью автоматизировать. Существует техника “10P тестируемости”, которая используется для оптимизации процесса разработки, как инструмент анализа и настройки процессов для достижения успеха на проекте в целом. Вот об этом и поговорим.
QA Fest 2019. Алиса Бойко. Какнезапутаться в коммуникативных сетях ITQAFest
Твою гениальность не замечает никто кроме мамы? Идеи и проекты нравятся только твоему коту? Одногруппники уже руководители подразделений, а ты завис между middle и senior? Пришло время найти баги не только на проекте, но и в своей голове! Прокачаем коммуникативные навыки:)
QA Fest 2019. Святослав Логин. Как найти уязвимости в мобильном приложенииQAFest
С каждым годом мобильных приложений становится все больше, но мало кто обращает внимание на безопасность этого приложения, когда оно находится в процессе разработки. Так как бизнес нацелен только на то, чтобы оторвать большую часть пользователей, которые будут использовать это приложение, они обращают внимание на конфиденциальность своих клиентов в последнюю очередь. В своем докладе я расскажу как мануал QA может проверить мобильное приложение на уязвимости и найти топовые дыры по рейтингу OWASP. В презентации будут использованы такие тулзы Santoku Linux + Genymotion.
QA Fest 2019. Катерина Шепелєва та Інна Оснач. Що українцям потрібно знати пр...QAFest
Маючи досвід роботи з іноземними замовниками і колегами, а також вивчаючи культурні особливості жителів інших країн, ми якось поставили собі за мету з'ясувати, якими українців бачать іноземці, чи потрібно їм підлаштовуватись під нашу манеру спілкування, чи є щось, що вони зовсім не можуть прийняти.
Поділимося з вами результатами цієї затії, а також поговоримо про:
- те, що потрібно знати українцям про свої софт скіли,
- то, як відрізняються софт скіли українців і жителів кількох інших країн,
- важливість софт скілів для успішних комунікацій з іноземними колегами,
- важливість софт скілів для просування по кар'єрі.
QA Fest 2019. Антон Серпутько. Нагрузочное тестирование распределенных асинхр...QAFest
Обычно в процессе нагрузочного тестирование необходимые app-side метрики(response time, throughput, ..) можно получить прямо в генераторе нагрузки. Мы шлем запрос, получаем респонс и зачастую время выполнения запроса это и есть то что нам нужно.
Но что если после того как сервер отдал вам ответ происходит еще ряд асинхронных операций, время выполнения которых нам необходимо проверить? Как замерить время выполнения этих запросов? Какая часть системы является узким местом в производительности?
В докладе рассмотрим какие челенжи появляются в такой ситуации и как их можно решить.
QA Fest 2019. Петр Тарасенко. QA Hackathon - The Cookbook 22QAFest
Хотели бы вы, чтобы в Украине происходило больше QA ивентов? Чувствуете, что их не хватает?
Знаете, кто может это изменить? - Вы!
Я поделюсь подходами, которые мы использовали при организации QA хакатонов в Wix, которыми завтра вы сможете воспользоваться для создания вашего крутого ивента!
7. Общие причины
Сложные нестабильные сценарии
Сложность решения
Заказчик не понимает НА САМОМ ДЕЛЕ
необходимость поддержки
Авто-тесты тестируют не то, что нужно
10. Принцип №1:
Короткие тестовые сценарии
Отдельные компоненты системы
Интеграция между компонентами
Огромные бизнес сценарии со множеством зависимостей
Привлекать автоматизаторов к ревью ТС
А как же full flow?
Тесты могут связываться в цепочки,
запускаясь последовательно
12. Принцип №2:
Независимость
• Проверить конфигурацию
системы
• Изменить
Конфигурация
системы
• Создать данные
• Искать подходящие данные в
системе
Данные в
системе
Preconditions
17. Принцип №5:
Поддержка
Кто? Когда? Как?
Честность с заказчиком
Поддержка – часть контракта
Review каждые 3-6 месяцев
Пример оценки затрат на поддержку
Type of Change Minor Medium Major
Change in TC 1-2h 4-6h 8-12h
UI change 0,5h 2-4h 10-16h
DB change 2h 4-8h >20h
…
26. Принцип №10:
Понятные отчеты
Детальные логи теста
Скриншоты на ключевых шагах
Скриншоты на ошибках
Агрегированный отчет для менеджера
Встроенного репортинга инструмента
может быть недостаточно
28. P.S.
Проанализируйте свои прошедшие проекты по автоматизации
– как они себя чувствуют?
Устройте аудит своим текущим проектам –
придерживаетесь ли вы best practices?
Составьте checklist полезных практик по
автоматизации, используйте его при старте
каждого нового проекта
Дайте возможность вашим решениям жить вечно
Принципы «правильной» автоматизации всем хорошо известны, но почему-то даже опытные автоматизаторы не всегда им следуют.
Допуская ошибки одну за другой, мы и не замечаем, как укорачиваем жизнь нашим авто-тестам.
В результате, нередко случается так, что наши решения со временем забрасываются и не выживают, либо же превращаются в «чемодан без ручки» - когда нести тяжело, а выбросить жалко.
Я предлагаю по-новому взглянуть на автоматизацию в проектах и увидеть общие ошибки. Я расскажу о 10 принципах автоматизации, к которым пришла моя команда на собственном опыте, и которые помогут не наступать на одни и те же грабли.
Доклад смогут «прочувствовать» все тестировщики, работающие на проектах, где есть автоматизация.
10 Test Automation Principles that I will Never Betray
Principles of «right» test automation are well-known, but for some reasons even experienced test automation engineers disregard them sometimes. Making mistakes one after another, we do not even see how we shorten lives of our auto-tests. As a result, our solutions are neglected with time and cannot survive. Or they transform to a “suitcase without a handle” – when it’s too hard to carry it and still you cannot throw it away.
I suggest to look at test automation by new way and see common mistakes. I will tell about 10 test automation principles that have been found out by my team on own experience, and which will help to avoid mistakes in future. The speech will touch all test engineers who are working in the projects with test automation.
Работаю в тестировании уже почти 10 лет, 5 лет занимаюсь автоматизацией.
В данный момент занимаюсь проджект менеджером, но остаюсь автоматизатором в душе.
Компания Итера предоставляет сервис автоматизации тестирования, и имеет хорошую репутацию.
У нас работают действительно хорошие автоматизаторы.
Более 10 автоматизаторов, около 10 проектов чисто по автоматизации, несколько проектов по разработке, где тоже есть автоматизация.
Мы решили взглянуть под новым углом на 3 успешных проекта по автоматизации, после прошествия некоторого времени.
Используется ли автоматизация по прошествии времени? Живы ли тесты без нашего постоянного внимания? Выживают ли тесты, когда меняются люди в командах?
Доволен ли заказчик нашим сервисом до сих пор? Приносят ли авто-тесты пользу?
1. Телеком проект. После окончания проекта прошло 2 года. Заказчик больше не использует ТА решение
Авто-тесты больше «не живы»
2. Банк. Проект недавно закончился. Заказчик хочет использовать ТА решение, но не может его поддерживать
Прогноз неутешителен: без нас, TA решение скоро «умрет»
3. Страховая компания. Заказчик использует ТА решение (6 месяцев)
Заказчик может поддерживать тестовые данные
Проект был стрессовый для команды, было много овертаймов, и некоторые вещи пришлось переделывать несколько раз
Но проектов было на самом деле намного больше! И за 9 лет в тестировании я вижу, что очень часто повторяется одна и та же история...
Мы решили взглянуть под новым углом на 3 успешных проекта по автоматизации, после прошествия некоторого времени.
Используется ли автоматизация по прошествии времени? Живы ли тесты без нашего постоянного внимания? Выживают ли тесты, когда меняются люди в командах?
Доволен ли заказчик нашим сервисом до сих пор? Приносят ли авто-тесты пользу?
1. Телеком проект. После окончания проекта прошло 2 года. Заказчик больше не использует ТА решение
Авто-тесты больше «не живы»
2. Банк. Проект недавно закончился. Заказчик хочет использовать ТА решение, но не может его поддерживать
Прогноз неутешителен: без нас, TA решение скоро «умрет»
3. Страховая компания. Заказчик использует ТА решение (6 месяцев)
Заказчик может поддерживать тестовые данные
Проект был стрессовый для команды, было много овертаймов, и некоторые вещи пришлось переделывать несколько раз
Но проектов было на самом деле намного больше! И за почти 10 лет в тестировании я вижу, что очень часто повторяется одна и та же история.
Где-то - ушли 3 ключевые человека из команды, поменялся менеджер – автоматизацию перестали поддерживать, проект умер.
Где-то – проект по автоматизации, успешно сдали, прошло время, и оказалось, что его уже никто не использует.
Еще один пример – команда автоматизаторов написала свой (!) инструмент для тестирования TIBCO платформы. Было заавтоматизирован много тест кейсов. Но затем один за другим автоматизаторы ушли из проекта, вместо них приходили другие люди. В итоге свои инструментам заниматься постепенно перестали, тесты забросили. Купили другой инструмент (коммерческий и очень дорогой),и уже на нем начали вновь автоматизировать те же самые тесты! О прошествии года о старом инструменте и старых тестах все забыли.
К сожалению, редко автоматизация живет много лет.
Разные проекты, разные ситуации, но исход часто один...
Если проанализировать причины в разных проектах, то они очень схожи:
Сложные нестабильные сценарии
Сложность решения
Заказчик не понимает НА САМОМ ДЕЛЕ необходимость поддержки
Авто-тесты тестируют не то, что нужно
Я хочу, чтобы автоматизация жила дольше! Ведь классно, когда есть проект или продукт развивается, и автоматизация, живет и используется 5-8-10 лет!
Проанализировав общие проблемы, мы пришли к 10 приципам, которых необходимо придерживаться, чтобы не наступать на те же грабли снова.
Некоторые из этих принципов – известные best practices, которые мы прочувствовали на своем опыте, а некоторые принципы потребовали изменения в наших подходах.
Но эти принципы помогут продлить жизнь автоматизации и получить больше пользы от нее.
Настолько короткие, насколько возможно, узконаправленные. Должны тестировать:
либо отдельный компонент системы
либо интеграцию между компонентами
Огромные бизнес сценарии со множеством зависимостей не автоматизировать
Настолько короткие, насколько возможно, узконаправленные. Должны тестировать:
либо отдельный компонент системы
либо интеграцию между компонентами
Огромные бизнес сценарии со множеством зависимостей не автоматизировать
Часто тесты нестабильны именно из-за зависимостей от конфигурации системы или на данные в системе.
1. Добавить в тесты pre-condition шаги, которые проверяют конфигурацию системы и если необходимо меняют
2. Создать pre-condition тесты, которые создадут все независимые данные
3. Или найдут подходящие данные в системе
Часто тесты нестабильны именно из-за зависимостей на конфигурацию системы или на данные в системе.
1. Добавить в тесты pre-condition шаги, которые проверяют конфигурацию системы и если необходимо меняют
2. Создать pre-condition тесты, которые создадут все независимые данные
3. Или найдут подходящие данные в системе
Простая идея, но ее реализация – довольно трудоемкий процесс. Но в итоге это того стоит!
Больше server-side автоматизации, меньше в UI:
- DB
- HTTP запросы
- Использование веб-сервисов
- etc
Автоматизатор должен хорошо знать инфраструктуру системы!
Больше server-side автоматизации, меньше в UI:
- DB
- HTTP запросы
- Использование веб-сервисов
- etc
Автоматизатор должен хорошо знать инфраструктуру системы!
Хорошая распределенность в коде, возможность легко менять тестовые данные.
Ни в коем случае не «захардкоженные» данные.
И вроде бы все это знают и понимают. Но нередко бывает, когда в спешке, поджимает дедлайн, и что-то дописывается «на коленке», подставляются костыли в стиле «потом когда-нибудь» исправим, но это «когда-нибудь» почему-то не наступает.
Поддержке часто не придают должного значения в моммент начала работы над автоматизацией. Все вроде как понимают, что тесты надо будет поддерживать, но не четко не ообозначают кто, когда и как это будет делать.
Заказчики часто не понимают на самом деле, что поддержка нужна и важна.
Быть честным с заказчиком, если мы видим, что он сам не сможет поддерживать тесты
Поддержка должна предоставляться в пакете услуг вместе с автоматизацией
Делать ревью статуса автоматизации каждые 3-6 месяцев после финального деливери. Наставивать. Оценить объем требуемых изменений и предложить их
Поддержке часто не придают должного значения в моммент начала работы над автоматизацией. Все вроде как понимают, что тесты надо будет поддерживать, но не четко не ообозначают кто, когда и как это будет делать.
Заказчики часто не понимают на самом деле, что поддержка нужна и важна.
Быть честным с заказчиком, если мы видим, что он сам не сможет поддерживать тесты
Поддержка должна предоставляться в пакете услуг вместе с автоматизацией
Делать ревью статуса автоматизации каждые 3-6 месяцев после финального деливери. Наставивать. Оценить объем требуемых изменений и предложить их
Документ – оценки усилий по поддержке
Решение для автоматизации должно быть легко поддерживаемым.
В случае проектов “Test Automation as a service” – решение должно быть таким, чтобы с ним могли работать и не автоматизаторы, и возможно даже «не технические» люди.
Мы подошли к решению для автоматизации как продукту, который должен быть удобным.
1. Тестовые данные должны быть в удобном формате. Например, Excel с простой структорой.
Хранение данных в XML может быть удобным для автоматизатора, но не удобным для пользователя, который будет работать с данными.
Если все-таки было принято хранить данный в более сложном формате (XML, DB, etc), то желательно предоставлять удобные эдиторы для работы с такими данными.
2. Предоставлять заказчику шаблоны для хранения данных и примеры.
3. Создать скрипты, которые генерируют данные.
4. Behavior-driven testing
Решение для автоматизации должно быть легко поддерживаемым.
В случае проектов “Test Automation as a service” – решение должно быть таким, чтобы с ним могли работать и не автоматизаторы, и возможно даже «не технические» люди.
Мы подошли к решению для автоматизации как продукту, который должен быть удобным.
1. Тестовые данные должны быть в удобном формате. Например, Excel с простой структорой.
Хранение данных в XML может быть удобным для автоматизатора, но не удобным для пользователя, который будет работать с данными.
Если все-таки было принято хранить данный в более сложном формате (XML, DB, etc), то желательно предоставлять удобные эдиторы для работы с такими данными.
2. Предоставлять заказчику шаблоны для хранения данных и примеры.
3. Создать скрипты, которые генерируют данные.
4. Behavior-driven подход
Актуально для проектов “Test Automation as a Service”. Дать заказчику самому попробовать автоматизацию в процессе разработки
Сильные автоматизаторы часто хорошие программисты, и они зачастую уверены, что «круче» писать свой код, а не использовать встроенные возможности инструмента.
Я приведу пример, как такой подход навредил проекту.
Less custom code, more TA tool features
Используйте известные фреймфорки
KISS :-*
Документация – это «прививка», которая продлевает жизнь любому решению.
Почему же мы так редко ее пишем??
Документация – это «прививка», которая продлевает жизнь любому решению.
Почему же мы так редко ее пишем??
Мы поговорим о ситуации, когда авто-тесты тестируют не то, что должны, и почему это происходит.
Иногда – неправильно был выбран скоуп для автоматизации, и в итоге авто-тесты просто не приносят пользу.
Иногда – автоматизаторы неправильно интерпретировали ТС, и сместили фокус.
А иногда – в проекте просто был бюджет на автоматизацию, и автоматизировали «что-нибудь», не задумываясь, кому это будет нужно.
Одно из решений – это привлекать manual тестировщиков к автоматизации, или автоматизаторов к тест дизайну
Еще одно из решений – это изменить подход к написанию тест кейсов.
В любом случае – автоматизатор должен оставаться тестировщиком, и его главная цель должна быть ТЕСТИРОВАТЬ.
Понятные отчеты:
Детальные логи теста
Картинки на ключевых шагах и на ошибках
Понятные отчеты:
Детальные логи теста
Картинки на ключевых шагах и на ошибках
В своей компании, мы составили чеклист – список того, что необходимо проверить в любом проекте по автоматизации. На этапе завершения proof of concept, необходимо сделать ревью фрреймворка на соответсвие выделенных нами best practices.