QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...QAFest
Принципы «правильной» автоматизации всем хорошо известны, но почему-то даже опытные автоматизаторы не всегда им следуют. Допуская ошибки одну за другой, мы и не замечаем, как укорачиваем жизнь нашим авто-тестам. В результате, нередко случается так, что наши решения со временем забрасываются и не выживают, либо же превращаются в «чемодан без ручки» - когда нести тяжело, а выбросить жалко.
Я предлагаю по-новому взглянуть на автоматизацию в проектах и увидеть общие ошибки. Я расскажу о 10 принципах автоматизации, к которым пришла моя команда на собственном опыте, и которые помогут не наступать на одни и те же грабли.
Доклад смогут «прочувствовать» все тестировщики, работающие на проектах, где есть автоматизация.
QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.QAFest
- История проекта (с чего началось внедрение SCRUM в QA команде, какая была команда и тп)
- Тестирование в идеальном Agilе (как происходит построение процесса в идеале и что мы можем получить)
- Советы тестировщику в Agile
- Показатели или что от нас хочет Product Owner
- Что мы добавили в обычное SCRUM тестирование и какой получили результат
Выводы что дал SCRUM команде и как поменялась
Большинство клиентов, прежде чем покупать "тестирование как сервис" для своих проектов, хотят видеть реальные цифры пользы (вложение/затраты на сэкономленное время/ресурсы), которую им даст данная инвестиция в «качество». Клиенты привыкли слышать, что тестирование, словно по-волшебству, повысит качество.
Я хочу показать конкретные цифры: как визуализировать вот ту самую пользу и дать четкие числа, на основании которых люди, инвестирующие деньги в тестирование, смогут видеть практическую пользу тестирвоания, как ручного, так и автоматизированного. Мы поговорим о метриках в тестировании и KPI, что именно и как собирать, как отслеживать данные непрерывно, как анализировать тренд и презентовать его клиентам.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
QA Fest 2015. Александра Волкова. 10 принципов автоматизации, которые я не пр...QAFest
Принципы «правильной» автоматизации всем хорошо известны, но почему-то даже опытные автоматизаторы не всегда им следуют. Допуская ошибки одну за другой, мы и не замечаем, как укорачиваем жизнь нашим авто-тестам. В результате, нередко случается так, что наши решения со временем забрасываются и не выживают, либо же превращаются в «чемодан без ручки» - когда нести тяжело, а выбросить жалко.
Я предлагаю по-новому взглянуть на автоматизацию в проектах и увидеть общие ошибки. Я расскажу о 10 принципах автоматизации, к которым пришла моя команда на собственном опыте, и которые помогут не наступать на одни и те же грабли.
Доклад смогут «прочувствовать» все тестировщики, работающие на проектах, где есть автоматизация.
QA Fest 2015. Виктор Гожий. SCRUM в QA команде и как с этим жить.QAFest
- История проекта (с чего началось внедрение SCRUM в QA команде, какая была команда и тп)
- Тестирование в идеальном Agilе (как происходит построение процесса в идеале и что мы можем получить)
- Советы тестировщику в Agile
- Показатели или что от нас хочет Product Owner
- Что мы добавили в обычное SCRUM тестирование и какой получили результат
Выводы что дал SCRUM команде и как поменялась
Большинство клиентов, прежде чем покупать "тестирование как сервис" для своих проектов, хотят видеть реальные цифры пользы (вложение/затраты на сэкономленное время/ресурсы), которую им даст данная инвестиция в «качество». Клиенты привыкли слышать, что тестирование, словно по-волшебству, повысит качество.
Я хочу показать конкретные цифры: как визуализировать вот ту самую пользу и дать четкие числа, на основании которых люди, инвестирующие деньги в тестирование, смогут видеть практическую пользу тестирвоания, как ручного, так и автоматизированного. Мы поговорим о метриках в тестировании и KPI, что именно и как собирать, как отслеживать данные непрерывно, как анализировать тренд и презентовать его клиентам.
QA Fes 2016. Анастасия Асеева. Роль тестирования в DevopsQAFest
В своем докладе я расскажу, как мы внедряли devops в банке, а конкретнее какую роль в этом процессе сыграло тестирование. Также расскажу с какими проблемами столкнулись, и как мы их устраняли. И да, каких результатов смогли добиться уже через полгода. А самое интересное, покажу как мы смогли добиться того, чтоб у нас pull request долетал до боя за 3 часа со всеми этапами тестирования.
Доклад будет содержать большое количество лайфхаков и обзоров инструментария, который мы использовали.
Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
Способы организаций больших Java проектов по Автоматизированному тестированиюCOMAQA.BY
В процессе работы автоматизатора часто приходится сталкиваться с написанием новых фреймворков или модификации прежде написанных. И тут возникает ощущение, что "когда-то я уже это писал". В ходе доклада я расскажу как же решить известную задачу "не повторяться" в рамках большого проекта или кросс-проектно или почему работа автоматизатора часто требует навыков системного администрирования, программирования, "девопса".
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...QAFest
Доклад для ленивых тестировщиков, которые не хотят набивать свои шишки, а научится на чужом опыте:
- полезные инструменты и решения для тестирования;
- работа с сетью, внутренними и внешними сервисами;
- процессы и культура тестирования в отделе разработки
- silver bullet в конце доклада
Непрерывная интеграция и автотесты. Сравнительный анализ инструментовCOMAQA.BY
По-настоящему автоматизированными тесты можно назвать только тогда, когда из процесса тестирования полностью исключается человек. В идеале участие человека должно сводиться к просмотру отчетов о результатах автотестирования, которые регулярно приходят ему на почту.
Достичь этого можно только одним способом - с помощью инструментов непрерывной интеграции. Какой же инструмент лучше выбрать? Почему? Так ли этот выбор важен или можно просто взять любой из них и начать использовать?
Сравним самые популярные Java-совместимые инструменты CI и сделаем выводы!
Quality Assurance vs Quality Control - так в чем же заключается работа специа...COMAQA.BY
Поговорим о том, что такое Quality Assurance и что такое Quality Control. Узнаем в чем заключается принципиальная разница между этими двумя понятиями\подходами. Расскажем как можно и нужно строить карьеру тестировщика. Приведем пример мировой практики от Microsoft.
Techleads Meetup #1
"Как автотесты ускоряют релизы в OK.ru"
Никита Макаров, руководитель отдела тестирования (Одноклассники)
Описание:
начиная с 2012 года Одноклассники прошли огромный путь в области ускорения релизов.
Одним из факторов успеха была автоматизация тестирования, которую внедряли «с нуля».
В своем докладе я расскажу:
— о том как мы учили тестировщиков писать автотесты;
— сколотили команду автоматизаторов и построили инфраструктуру автоматизации тестирования;
— о наших ошибках, поражениях, полезных практиках и процессах.
Способы организаций больших Java проектов по Автоматизированному тестированиюCOMAQA.BY
В процессе работы автоматизатора часто приходится сталкиваться с написанием новых фреймворков или модификации прежде написанных. И тут возникает ощущение, что "когда-то я уже это писал". В ходе доклада я расскажу как же решить известную задачу "не повторяться" в рамках большого проекта или кросс-проектно или почему работа автоматизатора часто требует навыков системного администрирования, программирования, "девопса".
QA Fes 2016. Василий Сливка. 10 лучших практик для тестирования мобильных при...QAFest
Доклад для ленивых тестировщиков, которые не хотят набивать свои шишки, а научится на чужом опыте:
- полезные инструменты и решения для тестирования;
- работа с сетью, внутренними и внешними сервисами;
- процессы и культура тестирования в отделе разработки
- silver bullet в конце доклада
Непрерывная интеграция и автотесты. Сравнительный анализ инструментовCOMAQA.BY
По-настоящему автоматизированными тесты можно назвать только тогда, когда из процесса тестирования полностью исключается человек. В идеале участие человека должно сводиться к просмотру отчетов о результатах автотестирования, которые регулярно приходят ему на почту.
Достичь этого можно только одним способом - с помощью инструментов непрерывной интеграции. Какой же инструмент лучше выбрать? Почему? Так ли этот выбор важен или можно просто взять любой из них и начать использовать?
Сравним самые популярные Java-совместимые инструменты CI и сделаем выводы!
В этом докладе вы услышите историю о том, как можно построить процесс автоматизированного тестирования и непрерывной интеграции за короткий период времени. Мы поговорим о точках роста, развития и внедрения автоматизированного тестирования на уже существующем проекте. Вы узнаете, что с чего начинать автоматизированное тестирование и как выбрать "работающую" стратегию. После доклада вы захотите избавиться или значительно сократить ручное тестирование и ручной труд у себя на проекте. Вы откроете для себя целую систему, элементы который можно будет внедрять у себя, и которые будут работать.
Доклад будет интересен всем тестировщикам, разработчикам и менеджерам проектов.
Современный мир ускоряется, и от тестирования требуется быстрые и стабильные тесты. В этом мастер-классе предлагается уйти от UI автоматизации и перейти на уровень ниже "пирамиды тестирования", на уровень WEB API. Не обещаю теорию, но будет много практических кейсов. В качестве примера я возьму популярный веб сайт с открытым API и покажу как за относительно небольшое время можно создавать хорошие тесты! Причем тесты мы будем создавать совместно, и особых навыков программирования от участников здесь не потребуется, достаточно включить логику и желание освоить что-то новое.
Обсуждаем главы из “97 Things Every Programmer Should Know”SPB SQA Group
Ограничимся несколькими главами:
Правило туриста (The Boy Scout Rule);
Непрерывное обучение (Continuous Learning);
Не работайте сверхурочно (Hard Work Does not Pay Off);
Наблюдайте за пользователями (Ask «What Would the User Do?» (You Are not the User));
Пишите код так, как будто вы будете сопровождать его до конца жизни (Write Code as If You Had to Support It for the Rest of Your Life);
Хороший интерфейс: легко использовать правильно, сложно использовать неправильно (Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly);
Миф о гуру (The Guru Myth);
Не надейтесь на магию (Don’t Rely on «Magic Happens Here»).
Как надо правильно строить автоматизацию тестирования с нуля, что нужно применять, а то не нужно применять при проектировании архитектуры. Какие виды фреймворков бывают, что с ними надо делать. Все и много другое вы сможете найти в этой презентации
Out-of-the-box WebDriver API provides two main classes: WebDriver and WebElement. Webium library helps you to extend it to whatever deep UI object structure you need. You can describe basic elements (e.g. Button, Input), construct complex elements (e.g. Calendar) from small pieces and at the end put it all together into your Page Objects. Webium is free and open-source. In my speech I’ll present your how to use it effectively if you want to write Selenium tests in Python.
Об измерениях в разработке ПО слышали все. Но какая от польза от их внедрения? И какие необходимые условия внедрения?
Вашему вниманию будут представлены различные способы измерения качества продукта, как их можно использовать для улучшений рабочих процессов, определения проблем, поддержки контрактных обязательств, оценки достижения целей индивидуума, отдела или компании. Также вы узнаете, как выбрать и внедрить действительно нужные метрики.
При внедрении на сайт нового функционала могут «поломаться» метрики, передаваемые в Google Analytics. В результате вы получите некорректные данные и, чем позднее выявите ошибку, тем выше будет стоимость ее исправления. Поэтому веб-аналитикам приходится вручную тестировать метрики после обновлений на сайте. В среднем на проверку данных после небольшого релиза уходит до 2 часов.
Хорошая новость в том, что этот процесс можно автоматизировать, чтобы освободить ценное время аналитика на поиск инсайтов и точек роста.
Автотестированию метрик на сайте посвящена эта презентация, а также бесплатный вебинар, который вы можете посмотреть в записи https://www.owox.com/c/3f6.
Опыт совместной работы хостера (Webzilla) и клиента (CityADS) над достижением...Ontico
Для любого крупного проекта работа над uptime сервиса должна быть постоянной, непрерывной и многовекторной.
Каждый инцидент с доступностью проще всего “свалить” на поставщика услуг хостинга и провайдера. Однако, начиная с определенного уровня масштаба сервиса, такой подход уже начинает стоить бизнесу слишком много.
Данный доклад — это обзор работы над проблемами доступности на пути от клиента до хостера, проведенной с целью достижения доступности сервисов клиента выше 99,99% на примере интернет-компании с оборотом выше 1 млрд рублей.
Ключевая особенность доклада в том, что он максимально объективен в силу того, что каждый докладчик представляет свою сторону "баррикад".
В докладе будут рассмотрены вопросы:
+ Почему хостер — наименьшая из проблем?
+ Какие бывают источники проблем?
+ Как научиться видеть проблемы и построить необходимый базис для своевременного их обнаружения и решения?
+ Третий не лишний — почти всегда между хостером и вами есть еще один источник проблем.
+ Что учитывать в современных реалиях при выборе dedicated / colocation услуг?
+ Чем различаются хостеры, как их сравнить, что от них стоит ждать?
Как 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, выдерживающее значительные нагрузки.
...
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:
Понятные отчеты
Детальные логи теста
Скриншоты на ключевых шагах
Скриншоты на ошибках
Агрегированный отчет для менеджера
Встроенного репортинга инструмента
может быть недостаточно
30. 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 testing
Актуально для проектов “Test Automation as a Service”. Дать заказчику самому попробовать автоматизацию в процессе разработки
Сильные автоматизаторы часто хорошие программисты, и они зачастую уверены, что «круче» писать свой код, а не использовать встроенные возможности инструмента.
Я приведу пример, как такой подход навредил проекту.
Less custom code, more TA tool features
Используйте известные фреймфорки
KISS :-*
Документация – это «прививка», которая продлевает жизнь любому решению.
Почему же мы так редко ее пишем??
Документация – это «прививка», которая продлевает жизнь любому решению.
Почему же мы так редко ее пишем??
Мы поговорим о ситуации, когда авто-тесты тестируют не то, что должны, и почему это происходит.
Иногда – неправильно был выбран скоуп для автоматизации, и в итоге авто-тесты просто не приносят пользу.
Иногда – автоматизаторы неправильно интерпретировали ТС, и сместили фокус.
А иногда – в проекте просто был бюджет на автоматизацию, и автоматизировали «что-нибудь», не задумываясь, кому это будет нужно.
Одно из решений – это привлекать manual тестировщиков к автоматизации, или автоматизаторов к тест дизайну
Еще одно из решений – это изменить подход к написанию тест кейсов.
В любом случае – автоматизатор должен оставаться тестировщиком, и его главная цель должна быть ТЕСТИРОВАТЬ.
Понятные отчеты:
Детальные логи теста
Картинки на ключевых шагах и на ошибках
Понятные отчеты:
Детальные логи теста
Картинки на ключевых шагах и на ошибках
В своей компании, мы составили чеклист – список того, что необходимо проверить в любом проекте по автоматизации. На этапе завершения proof of concept, необходимо сделать ревью фрреймворка на соответсвие выделенных нами best practices.