С чего начать изучение автоматизации тестирования
Перейти к содержимому

С чего начать изучение автоматизации тестирования

  • автор:

Путь тестировщика: с чего начинать изучение автоматизации

Шесть лет назад Роман Печерский из Ижевска прошёл курсы для функциональных тестировщиков и начал работать QA-инженером. Спустя несколько месяцев он впервые столкнулся с автоматизацией тестирования и понял, что хочет развиваться в эту сторону.

Сейчас Роман руководит командой автоматизаторов, а также учебным центром по автоматизированному тестированию в ижевском EPAM. Он рассказал, с чего начинал изучать автоматизацию, как развивался, с какими проблемами имел дело и какими лайфхаками пользовался.

Как я познакомился с автоматизацией

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

Кто-то из коллег по проекту рассказал мне про Selenium IDE – инструмент для автоматизации действий Firefox-браузера. Помню, как написал свой первый автотест с помощью метода Record and Play: включил запись, начал нажимать кнопки, вводить текст в поисковую строку и кликать по ссылкам. Получился набор сохранённых действий, который можно было запускать и сразу видеть результат.

Знакомства с Selenium IDE и этих лекций мне вполне хватило, чтобы решить ту проектную задачу и начать делать первые шаги в сторону в автоматизации.

Как я учился автоматизации

Вскоре я начал самостоятельно изучать Java – один из самых популярных языков для автоматизации тестирования – и пробовать писать несложные автотесты в Eclipse, например, для тестирования login-формы приложений.

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

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

Вот что помогало мне преодолевать трудности:

• Понимание, зачем это нужно

Несмотря на то что учёба была сложной и временами даже скучной, я чётко осознавал, какие возможности она мне откроет. Именно поэтому всё свободное время я посвящал автоматизации. Вместо прогулок по городу – автоматизация, вместо посиделок в баре с коллегами – автоматизация, вместо вечернего сериала – автоматизация.

• Поддержка коллег

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

• Чувство соперничества

Ощущение, что я могу стать самым отстающим студентом в группе, также подстёгивало меня двигаться вперёд.

Когда курсы закончились, я начал работать на проекте, чередуя обязанности функционального тестировщика и автоматизатора. Через несколько месяцев присоединился к новому проекту – уже в роли тимлида. QA-команда состояла всего из двух человек – меня и функционального тестировщика, которому я объяснял основы автоматизации.

Как я начал обучать автоматизации

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

Постепенно моя команда выросла до 10 автоматизаторов. К тому времени я полностью отошёл от ручного тестирования и занимался комплексным системным автотестированием веб-приложений. Затем начал помогать команде с созданием архитектурных решений для тестов и стал проектным координатором.

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

Недавно я сам прошёл небольшой курс – по JavaScript – и подключился к новому проекту. Раньше я никогда не сталкивался с JS. Мне потребовалось около месяца, чтобы начать более-менее уверенно чувствовать себя в работе с новым языком.

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

• Начните с практики – создайте собственный автотест

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

Я считаю, что начинать нужно с простых вещей. Создайте несложный автотест сами. Чтобы было интереснее, попробуйте решить какую-нибудь жизненную задачу. Например, напишите скрипт, автоматизирующий передачу показаний счётчиков воды на сайт водоканала. Сегодня это можно сделать с помощью Katalon Studio, который пришёл на смену Selenium IDE. Такие задания подогревают интерес к изучению автоматизации. Затем можно будет переходить к изучению теории и специфики автоматизации, а также начать осваивать язык программирования в связке с Selenium WebDriver.

• Расставьте приоритеты

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

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

• Начните учиться самостоятельно или пройдите курсы

Курсы – хороший вариант для тех, кто вообще не имеет представления о том, с чего начать, или хочет систематизировать свои знания. Онлайн-курсы можно найти на Otus, Stepik, GeekBrains, Lynda, JavaRush. Если говорить об офлайн-обучении, его могут организовывать разные IT-компании вашего города: учебный центр EPAM, например, работает в шести российских городах.

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

1. Введение в теорию автоматизации;
2. Изучение основ языка программирования (например, Java);
3. Написание собственных автотестов.

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

Вот минимальный набор знаний, которые вы должны освоить, чтобы начать работать на реальных проектах:

• Понимание основных понятий тестирования: тест-кейсы, дефекты и т.д.;
• Понимание, что можно автоматизировать, а что нет;
• Знание основ языка программирования (Java, JavaScript, Python, C#);
• Умение работать с Selenium WebDriver;
• Умение писать локаторы для элементов;
• Знание одного-двух юнит-фреймворков.

• Как можно больше интересуйтесь

Новичков в автоматизации чаще всего отпугивают ошибки в коде. Они запускают код, видят, как что-то идёт не так, и впадают в ступор. Что делать в такой ситуации? Попробовать найти решение в интернете, например, на том же Stack Overflow. Ещё один вариант – попросить помощи у более опытных коллег. Они тоже когда-то были на вашем месте и делали такие же ошибки. Обсуждая какую-либо задачу с опытными автоматизаторами, вы расширяете свой профессиональный кругозор.

• Не стойте на месте

Чтобы поддерживать себя в форме, нужно постоянно находиться на технологическом острие. Вводите в работу новые фреймворки и библиотеки, разберитесь с Continuous Integration, углубите знания языка программирования или освойте новый, читайте тематические статьи и блоги:

За пять с половиной лет, что я работаю с автоматизацией, я ни разу не пожалел, что выбрал это направление. Мне нравилось выполнять и задачи ручного тестирования, но я понимал, что рано или поздно упрусь в потолок. Потолок для мануальщика наступает, когда он тестирует разные виды приложений – веб, десктопные, мобильные – настолько профессионально, что работа перестает подбрасывать новые вызовы и превращается в рутину. Чтобы не стоять на месте и развиваться дальше, необходимо получить какой-то новый навык. Можно заняться автоматизацией функционального или нагрузочного тестирования, можно переключиться на тестирование безопасности или, например, разобраться в базах данных. Ещё можно посмотреть в сторону DevOps, бизнес-анализа или проектного менеджмента.

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

  • Блог компании EPAM
  • Тестирование IT-систем
  • Учебный процесс в IT
  • Карьера в IT-индустрии

С чего начать изучение автоматизации тестирования?

На данный момент я работаю QA и чувствую некий простой в моем развитии.
Поэтому я решил начать изучения автоматизированного тестирования. Для этого мне нужно будет изучить основы какого-то языка программирования, изучить инструменты.

Я посмотрел некоторые статьи в интернете, посмотрел вакансии — в них фигурируют такие технологии как: PhantomJS, WebDriver, Capycabra, ZombieJS, JUnit и многие другие.
Так вот, я немного запутался.

Может кто-то подсказать связку из ЯП и инструмента(ов), с помощью которых можно эффективно автоматизировать тестирование веб-приложений ?
Понимаю, что вопрос, возможно, звучит глупо, но с таким количеством возможных решений не знаешь за что браться.

�� Подобається Сподобалось 0

До обраного В обраному 1

С чего начать изучение автоматизированного тестирования? HOW TO START LEARNING ABOUT AUTOMATED TESTING?

Если вы работаете специалистом по ручному функциональному тестированию уже несколько лет, и поняли, что хотите стать специалистом по автоматизированному тестированию, то в первую очередь перед вами возникнет вопрос: С чего начать изучение автоматизированного тестирования?. Начать стоит с приведенных ниже вопросов и ответов на них: If you have been working with manual functional testing for several years and realized that you want to become an expert in automated testing, the first question is: Where to start learning about automated testing? It is worth starting with answering the following questions:

1) Какие типы проектов автоматизировать? 1)What types of project to automate?

Это очень важный вопрос. Ведь автоматизированное тестирование веб-приложений отличается от автоматизированного тестирования, например, мобильных приложений. Поэтому первый совет, лучше всего взять проект, над которым вы работаете сейчас или, например, ваш самый любимый проект на текущем месте работе и потренироваться на нем. Будет намного легче. Во-первых, если вы работаете (или работали) над проектом, то наверняка у вас есть тест-кейсы, по которым можно начать автоматизацию. Во-вторых, вы знаете этот проект «от и до», и легко ориентируетесь в нем. В-третьих, если это ваш любимый проект, или вы тестируете его в последнее время, то вам будет актуально и интересно делать авто тесты на нем. Изучать что-то новое это не всегда просто. Для этого потребуется много сил и терпения. Ведь если выы занимаетесь ручным тестированием веб-приложений последние годы, а решите изучать автоматизированное тестирование на десктопных приложениях, которые не имеют отношения к вашей работе или, если возьметесь изучать автоматизированное тестирование на проекте, который не нравится, товам будет сложно и скорей всего инициатива изучить автоматизированное тестирование потерпит неудачу. Поэтому выберите актуальный и интересный для вас проект и тогда будет намного интересней изучать автоматизированное тестирование. It is a very important question. The automated testing of web applications is different from the automated testing of mobile applications, for example. Therefore the first advice is to take the project you are working on now or, for example, your favorite project and train on it. This will make things easier. First, if you are working (or were working) on the project, you likely have the test cases, with which you can start the automation. Second, you know this project thoroughly. Third, if it is your favorite project or the one you are testing now, it will be interesting and relevant for you to run the auto tests on it. Learning something new is always hard. It requires a lot of persistence and patience. Is you have been working with manual testing of the web applications in the recent years and decide to learn the automated testing of desktop applications that are not relevant for your work or use the project that you do not like for this purpose, it will be difficult for you and you are more likely to fail. Therefore, choosing a relevant and interesting project will make learning the automated testing much more interesting.

2) Язык программирования? 2) Programming language?

Далее, важно понять и выбрать язык программирования для автоматизации. Это еще один важный шаг. Вы должны понимать, что изучать язык и инструменты программирования придется, и никуда от этого не деться. Да, сейчас многие инструменты для автоматизации упрощают эту работу. Большая часть работы выполняется за вас автоматически. На многих форумах и сайтах пишут, что и писать программный код необходимости нет, инструмент все сделает за вас. Это правда, но лишь отчасти. Автоматизировано, посредством инструментов, можно создавать только простые и тривиальные тесты. Но серьезную работу и сложные вещи вам придется выполнять вручную. Поэтому подумайте, если вы сомневаетесь и для вас все языки выглядят одинаково, то возьмите тот язык программирования, на котором разрабатывают коллеги. Так будет проще. Когда ваши тесты будут падать, вы сможете проконсультироваться у них или спросить совет, как лучше написать тест. Then it is important to understand and choose the programming language for the automation. This is another important step. You should realize that you will inevitably have to learn the coding language and tools. Obviously, nowadays many automation instruments simplify this job. A large share of job is made automatically for you. Many forums and websites say that it is not necessary to write the code and the tool will do everything for you. However, this is only partially true. Only simple and trivial tests can be made by tools. You will have to make serious and complicated things manually. Therefore, if you have doubts and all languages look the same for you, select the coding language your colleagues use for development. This will make things easier. When your tests will be failing, you will be able to consult with them and ask for an advice on what is a better way to code the test.

3) Инструмент автоматизации? 3) Automation tool?

После того, как вы определились с проектом для автоматизации и языком программирования, остался последний важный вопрос, какой инструмент для авто тестов выбрать? Исходя из п.1 и п.2, открывайте поисковик и начинайте искать подходящий инструмент. Выбор инструмента в первую очередь зависит от того, какие приложения вы хотите автоматизировать, а во вторую на чем. Поэтому ищите, читайте форумы и выбирайте. Старайтесь сделать свой выбор на бесплатный инструмент (вдруг вы выберете платный, заплатите, а он вам не подойдет?). Затем постарайтесь выбрать тот инструмент, по которому есть какая-то документация и форумы. Вероятно, в первое время работы с этим инструментом, вы будете очень часто заглядывать в поисковик, смотреть видео или читать форумы по нему. И если выбранный инструмент не популярный, то будет очень сложно. После того, как вы определись и ответили для себя по каждому из вопросов, то садитесь за работу и автоматизируйте. Первое время будет сразу и сложно, и интересно. Главное не сдавайтесь и автоматизируйте. Если у вас в компании уже внедрено автоматизированное тестирование, то вам будет легче отвечать на эти вопросы. Просто подойдите к специалисту в данном вопросе и спросите его совет. Как и с чего начать. After you have selected the automation project and the coding language, one important question remain — which tool to choose for auto tests? Based on p.1 and p.2, google for the most suitable tool. The choice of tool mainly depends on what apps you want to automate. Therefore, you should search, read the forums and choose. Try to choose a free tool (what if you choose a paid one, pay for it and it will not suit you?) Then try to choose the tool, on which there are some documents and forums. Probably, at first you will often google, watch the videos or read the forums. If the chosen tool is not very common, it will be very complicated. After you have made your choice and answered all the question, start working and automate. At first it will be both complicated and interesting. The most important thing is to not give up and continue to automate. If automated testing is already introduced in your company, you will find it easier to answer these questions. Just approach an expert and ask for an advice. How and where to start.

Автоматизация тестирования: подготовка стратегии и подводные камни внедрения

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

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

С чего начать формировать стратегию

Думаю, всем доводилось получать сообщения от пользователей о багах, не обнаруженных автотестами. На самом деле, невнимательны бывают и пользователи, и мы с вами не всегда идеально понимаем нюансы бизнеса, для которого разрабатываем продукт, или не можем покрыть все сценарии. Например, был такой случай на одном из тестовых окружений. Тест переходил по ссылке и проверял, чтобы новая страница открывалась, причем только сам факт этого. Однако открытие страницы с надписью «У вас нет прав для просмотра» тоже проходило как успешный сценарий, хотя таковым не являлось. В итоге проблема есть, но тест успешен. В любом случае процесс можно улучшить, и автотесты — мощный инструмент для этого.

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

Дальше — в зависимости от частоты выполнения того или иного типа тестирования, необходимости и рисков. Поэтому следующими автоматизируют smoke-тесты, затем переходят к функциональным или регрессионным. Потом можно внедрять автоматизированное тестирование на уровне Continuous Delivery, но всему свое время.

Шаг 1. Выбираем функционал для автоматизации

Если уже есть написанные заранее тест-кейсы — это хорошо, на их основе мы и будем строить анализ. Если тест-кейсов нет, что ж, пора их написать.

Обратим внимание на следующие пункты.

Можно ли в принципе автоматизировать те или иные сценарии и целесообразно ли это? Например, запись в базе появится через полчаса-час после добавления, есть ли смысл автотесту ждать этого? В принципе подождать можно, но ускорим ли мы в этом случае процесс тестирования в целом? А ведь обычно в этом и заключена едва ли не основная цель автоматизации. Получается, заменять ручное тестирование в таком процессе нужно, только если мы хотим полностью избавить наших Manual QA от необходимости смотреть в эту сторону.

А если сценарий простой, а проверка разовая, надо ли тратить время на ее автоматизацию? Теоретически да, особенно если клиент требует «автоматизировать абсолютно всё!». Но учтите, что это неизбежно влечет дополнительные расходы. Готовы ли вы к ним в текущем проекте? Может, стоит внимательно посмотреть на нечто более важное?

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

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

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

Нужно ли автоматизировать простые тесты? Почему бы и нет! Может, следует перелопатить данные в JSON из 500 строк. Когда-то мне самой пришлось за день до релиза сравнивать JSON с данными, разбросанными по Excel-файлу. Не скажу, что проверка была слишком сложной, но при максимальной концентрации мне на нее понадобилось семь часов. Конечно, после того случая мы автоматизировали процесс!

А сложные, с математическими расчетами? Однозначно! Это обеспечит необходимую точность в подсчетах и исключит человеческий фактор.

В комментариях вы можете дополнить список!

Шаг 2. Давайте убедимся, что существующие тест-кейсы готовы к автоматизации

Что значит готовы к автоматизации? Начнем с оформления.

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

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

При дальнейшей проверке тест-кейсов рекомендую обратить внимание на следующие моменты:

  • Если тест-кейсы пишут мануальщики. Зачастую тест-кейсы пишут они. Здорово, если мануальщики при этом имеют общее представление об автоматизации. Это позволит проанализировать ее возможность и целесообразность для конкретного сценария и осмысленно проставить отметку об автоматизации. Я неоднократно сталкивалась с ситуациями, когда мануальщики вовсе забывали проставлять этот атрибут и тест-кейсы терялись из фильтров. Или по привычке ставили его для всех тест-кейсов подряд. При необходимости всегда можно проконсультироваться с опытным коллегой-автоматизатором.
  • Если тест-кейсы пишут автоматизаторы. В таком случае тест-кейсы могут быть написаны сугубо техническим языком, а пользовательский сценарий не будет понятен. Например, я сталкивалась с тестом, состоявшим из нескольких увесистых запросов: «выполни запрос 1», «выполни запрос 2». Опять же, если запрос вернул данные — это хорошо или плохо? Когда тест считается пройденным? Возможно, когда-то обсуждали, но через полгода этого уже никто не помнит. В целом это удобно, но разобраться, что именно проверяется, не вникнув в детали самого запроса, бывает сложно. Проверьте, понятны ли вам сценарии, или они все-таки требуют разъяснения.
  • Детализация сценариев. Сценарии должны быть расписаны детально. Чтобы при дальнейшей автоматизации было очевидно, что нужно сделать, куда нажать и что проверить. Например, при выполнении сценария по работе с документом в конце остается шаг «сохраните документ». Этот шаг неоднозначен, поскольку это действие выполняется несколькими различными способами. Выбор одного из них может в корне изменить поведение автотеста, который в результате проверит не то, что было задумано. Мы ведь этого не хотим, правда? Старайтесь не заставлять другого человека додумывать, что вы имели в виду.
  • Актуальность тестов. Тесты необходимо поддерживать в актуальном состоянии. Да, это сложно, но без этого не обойтись. Хорошая практика — сообщать автоматизаторам об изменениях до того, как их автотесты упадут. Например, мы знаем, что поменяется UI или где-то всплывет дополнительное окно. При ручном тестировании на такое можно даже не обратить внимания: мы же слышали о предстоящих изменениях и понимаем, что все хорошо. Остается нажать ОК и двинуться дальше. Но вот автотест точно ничего подобного не ожидает и начнет бить тревогу.

Шаг 3. Определитесь с данными, которые автотесты будут использовать

Зачастую автотесты сами генерируют данные для проверки и удаляют их после выполнения.

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

Почему так? «Реальные данные» имеют особенности: например, они могут быть импортированы в систему, сформированы другим путем, иметь более сложную логику — то, что будет сложно повторить для чистоты сценария.

Еще один нюанс — данные меняются часто. Если это ваш случай, давайте рассмотрим другой подход.

В какой-то момент в кейсах мы стали добавлять критерии к данным, которые нужно использовать. Они могут быть простыми: например, надо взять пользователя, который зарегистрировался в системе более года назад. Один из вариантов решения — запрос в базу с теми же критериями, для автотестов он даже удобнее. Такой подход подойдёт, если тест нужно выполнить на разных окружениях, где данные отличаются. Но есть и минус: если данные достаточно сложные, то есть критериев много (пользователь, зарегистрированный год назад, который не делал покупок товаров определенной категории в течение последних 3 месяцев), то будет сложно или даже невозможно их достать таким образом. Вероятно, проще будет подбирать данные вручную и подставлять хардкодом.

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

Шаг 4. Оптимизируйте проверки

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

Я на собственном опыте убедилась, что попытка ускорить проверку может неприятно отразиться на качестве. Например, отправлять запросы не через пользовательский интерфейс, а напрямую через API: тут есть где развернуться, и работа, конечно, пойдет быстрее. Но при таком подходе не проверяется UI, и это чревато последствиями. Юзеры использовать API не будут, а проблемы с интерфейсом заметят сразу — для пользовательских задач они станут однозначным блокером. Но если такая идея пришла вам в голову, возможно, пора разделить и скомбинировать проверки. Дальше спокойно продумывайте покрытие и оптимизируйте процесс в свое удовольствие.

Вместо заключения. Краткий список рекомендаций

Давайте подведем итоги и повторим, о чем следует помнить, запуская автоматизацию тестирования в проекте:

  • убедитесь, что определили и обозначили все сценарии, которые целесообразно автоматизировать;
  • комбинируйте проверки и пытайтесь обеспечить достаточное покрытие в плане функционала и данных;
  • не выпускайте из виду пользовательские сценарии.

И главное помнить: цель любых тестов — найти проблемы, чтобы выпустить качественный продукт. Пусть автотесты будут «зелеными», а пользователи — довольными.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *