что нужно знать автоматизатор тестирования
ТОП-5 вопросов начинающего автоматизатора про автотесты
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Видеоверсию моих ответов можно посмотреть и послушать тут.
А пока мы не перешли к торжественной части, было бы круто, если бы вы помогли нам в нашем исследовании:
Каждый год мы изучаем технобренд крупных и не очень игроков российского IT-рынка. Выясняем, кого знают меньше или больше, куда пойдут работать охотнее и почему. Результатами обычно делимся прямо здесь, на Хабре.
Пожалуйста, пройдите этот опрос и помогите изучить рынок IT в 2021 году.
Вопрос 1. Мы пишем и прогоняем автотесты, а баги с прода все равно прилетают.
Начнем с того, что баги с прода продолжат прилетать в любом случае, и это совершенно нормально.
Пользователи могут совершать с вашим приложением невообразимые действия и проходить невероятные, непредсказуемые сценарии — открыли, перешли в другое приложение, заблокировали телефон, получили пуши, где-то полистали новости и решили вернуться в наше приложение. И вот тут-то баг его и поджидает. Частично такие кейсы можно автоматизировать — с помощью нагрузки, прерываний и выгрузки в фон и т.п. Но все возможные уникальные сценарии покрывать автотестами точно не стоит. Как минимум потому что ни один CI не выдержит такой загрузки, а время тестового прогона не будет того стоить.
Также могут быть девайс-зависимые баги, которые невозможно отловить автотестами, если вам не повезло тестировать именно на этом устройстве. Можно, конечно, попробовать настроить CI так, чтобы он создавал разные эмуляторы, или гонять автотесты на разных реальных девайсах, но это значительно увеличит сложность поддержки таких автотестов и скорее всего снизит их стабильность. И, опять же, это не будет стоить увеличенного времени на поддержку и прогоны, особенно с учетом, что находимые баги будут минорными.
Вопрос 2. Как сделать так, чтобы автотесты не заставляли всех страдать?
Чтобы автотесты не заставляли страдать всех вокруг, достаточно следовать некоторым правилам:
Правило 1. Писать понятный читаемый код, настроить отчеты.
Тесты должны быть понятны не только вам, но и другим тестировщикам и разработчикам. Если ваш тест упал, то человек не должен сидеть над ним полдня или сразу идти к автору автотеста с “помоги, посмотри почему он упал”, а должен сам понимать место и причину падения. Еще лучше, если у вас настроены человекочитаемые отчеты, в которых также видны шаги и место, где и почему упал тест.
Никому не хочется тратить время на то, чтобы понять, как автотест работает и что он там вообще проверяет — всё должно быть прозрачно.
Правило 2. Обязательное ревью.
Чтобы убедиться в том, что ваш тест действительно полезен и идеален, нужно, чтобы кто-то еще это подтвердил, и тогда можете спать спокойно.
У нас в hh для всех задач предусмотрено обязательное ревью. Для всех задач с автотестами предусмотрено обязательное ревью от QA. Это крайне важно, так как ревьювер может найти не только неправильный отступ, но и ошибки в логике, посоветовать добавить какие-либо дополнительные проверки, или указать на то, что вы запросто могли пропустить.
Правило 3. Сразу внедрять автотесты в ваш CI/CD
Очень важно, чтобы автотесты сразу приносили пользу, а не ждали лучших времен где-то в недрах кода. Чем быстрее все начнут привыкать, что их код теперь тестируется, тем проще всем станет жить. При этом важно не забывать, что выпускать автотесты нужно максимально стабильными. Перед тем, как вмержить свои тесты, лучше в прямом смысле 100 раз прогнать их на CI. И только убедившись на 100%, что тест не флакует, не падает неожиданно в разных местах, работает и работает как надо — сразу вперед!
Вопрос 3. Из-за чего тесты постоянно падают? Как можно им доверять?
Начнем с того, что какие-то автотесты в любом случае будут падать. Это совершенно нормально, так как если они в 100% случаев всегда зеленые, стоит задуматься — а проверяют ли они вообще что-то?
Но со своей стороны мы обязательно должны сделать максимум для того, чтобы падали они как можно реже. Для этого нужно научиться быстро понимать и устранять причины падений и улучшать слабые места.
За время работы с автотестами я выявила свой личный ТОП-4 проблем с автотестами:
1 — Кто-то что-то выкатил и все упало
Тут все просто — изменения в функционале должны идти рука об руку с правкой автотестов. На такие правки мы закладываем время при оценке и декомпозиции задачи. Когда разработчик изменяет что-то в функционале, который уже был покрыт автотестами, перед тем как вмержить свою ветку, он должен поправить автотесты, чтобы они продолжали проверять этот функционал. Очень важно наладить этот процесс, не игнорить тесты, а всегда поддерживать их актуальность.
2 — Тесты начали падать, но мы ничего не меняли
Тут интереснее. Разработчик ничего не менял, но в какой-то момент тесты начали падать. Возможно, что-то поменяли на бэке.
Почему наши UI-автотесты зависят от бэкенда?
Наши автотесты гоняются на тестовых стендах — это копия продового бэкенда (без продовой базы данных). Мы поддерживаем их актуальность — каждый день автотесты запускаются на актуальном бэкенде. Соответственно, если кто-то зарелизил что-то новое, наши автотесты об этом узнают и, как следствие, могут упасть. Мы в срочном порядке бежим смотреть: баг это или наша новая реальность, которую следует поддержать. И далее либо сообщаем команде о баге, либо правим тесты.
Тут важно заметить, что это случается не при каждом изменении на бэке. Всё-таки в основном, мы синхронизируемся командами по всем изменениям. Но реальность такова, что иногда какие-то моменты упускаются — кто-то не подумал, что может зааффектить мобильные приложения, например. Наши автотесты к такому чувствительны.
Каждый раз, когда такое случается, мы задумываемся о моках. Моки — это классно, если ими не злоупотреблять. Но всё-таки я думаю, что такая чувствительность автотестов к изменениям — это нормально, потому что там мы остаемся в курсе новых фич, которые влияют на наше приложение со стороны других команд. Плюс на моки тоже нужно выделять время на поддержку и актуализацию. Тут каждый сам выбирает, что ему больше хочется поддерживать.
3 — Баги
Моя любимая причина падения автотестов. Тут можно и без комментариев. Если ваш автотест нашел баг, то это очень хороший автотест, а вы — большой молодец.
4 — Флакование
А это самая нелюбимая причина. О ней поговорим далее.
Вопрос 4. Почему мои тесты флакуют?
Флакование как эмоциональные качели — ваши тесты то зеленые, то красные, всем то грустно, то радостно, и как с этим жить никто не знает. Чтобы отношения вашего приложения и автотестов были максимально здоровыми, советуем придерживаться нескольких правил о том, как избежать флакований и писать изначально более стабильные автотесты:
1. Уникальные тестовые данные
Для каждого автотеста должны создаваться новые уникальные тестовые данные, с которыми будет работать только этот тест. Нельзя надеяться на то, что на каком-то экране точно будет что-то, что мы сможем проверить и нам ок. Предсказуемость очень важна.
2. Не забывать дожидаться элементов на экране
Вы написали логичный тест, все четко по шагам, но тест не проходит и постоянно падает в разных местах. Скорее всего где-то он не успевает дождаться нужного элемента и тапает не туда, куда бы вам хотелось. Усугубляют ситуацию различные анимации, лоудеры загрузки и внезапные алерты.
Чтобы такого не случалось, перед каждым действием над элементом (тапы, свайпы и т.д.) или ассертом (проверкой, чеком) нужно дождаться, пока этот элемент точно появится на экране и будет доступен.
У Kaspresso для android есть встроенный механизм, который перед каждым действием под капотом дожидается элемент, делая ретраи на isVisible, и только потом совершает это действие. Благодаря этому, проблем с “тапами не туда” или “тапами раньше, чем нужно” в ваших автотестах больше не будет. Также этот вейтер можно настроить на нужное/необходимое вам количество времени, так как возможно дожидаться какой-то элемент по 10 секунд на экране — это уже баг.
В XCUITest на iOS также есть вейтеры из коробки, но проставлять их нужно вручную перед каждым действием. Либо стоит самим написать механизм, подобный каспрессовскому.
Главное не оставлять в коде вейты на конкретное количество секунд, так как это сильно увеличит время прохождения тестов. И взять за правило — прежде, чем что-то сделать с элементом, — убедитесь, что он есть на экране.
3. Настроить стабильную инфраструктуру
Если инфраструктура, на которой гоняются тесты, постоянно подводит, то стоит решать эту проблему как можно быстрее. Зависающие и тормозящие эмуляторы, падающие тестовые стенды — в такой атмосфере ваши прогоны тестов вряд ли будут зелеными, да и всем довольно быстро надоест разбирать причины их падений. Поэтому нужно обязательно выделить время и ресурсы команды на стабилизацию инфраструктуры. Если все оптимизировано по-максимуму, но все равно остаются проблемы, возможно вам стало не хватать существующего железа и пора лезть в бюджет за новым.
Вопрос 5. Что делать, когда тестов стало очень много?
В самом начале вы писали коротенькие простые автотесты — открой в приложении такой-то экран и проверь, что он отобразился. Затем вы начинаете автоматизировать более сложные сценарии, более сложные проверки. Количество тестов растет. Время прогона увеличивается. А когда что-то ломается, вместо одного теста у вас падает целых десять, и все с одинаковой ошибкой. При этом время упавшей сборки увеличилось в несколько раз, так как упавшие тесты еще и ретраились.
В такой ситуации важно не держаться за свои старые, пусть даже стабильные, тесты и уметь их отпускать. Удаляйте их, если такие же проверки появились в новом. Железо не резиновое, а тратить х2 времени на запуск приложения для каждого нового теста контрпродуктивно и не экономично.
Чтобы не закапываться в будущие объемные рефакторинги, может помочь правило — актуализируй старое прежде, чем писать новое. Если вы сразу начинаете этому правилу следовать, то такой проблемы у вас возникнуть не должно.
Вместо заключения:
Эта статья — заключительная из серии ответов на вопросы про автоматизацию. Но мы продолжим рассказывать про тестирование и автоматизацию в hh.ru, о том, как проходят наши релизы и еще много о чем полезном и интересном.
А чтобы не пропустить новые видео, статьи и прочие новости, подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube. Также вы можете задать вопросы нашим инженерам по любым темам в комментариях, в телеграм-чате с разработчиками hh или в личку.
Ищем тестировщиков в четыре разных направления:
Как стать автоматизатором тестирования?
Вчера, отвечая, кажется, в шестой раз на этот вопрос, твёрдо решил, что пришло время для написания статьи. Сразу отмечу – это исключительно моё видение, с которым, уверен, добрая половина мира автоматизаторов не согласится, – мой рецепт несколько сложнее, чем «почитать про тулзу», «поставить тулзу», «использовать тулзу», «написать в резюме, что умеешь пользоваться тулзой».
Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».
Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».
Итак, мы узнаём, что такое примитивы, классы, объекты, полиморфизм, инкапсуляция, интерфейсы, абстрактные классы, статические поля, циклы, массивы, листы, мапы, потоки и так далее… Это изучение будет продолжаться в целом всё время, даже когда вы уже автоматизируете тестирование. Но на базовом уровне – Junior Java Developer – вы должны (если выбрали Java) быть знакомы с языком и иметь соответствующие навыки, потому как первичная локализация возникшей проблемы лежит на ваших плечах. Забудьте про «а вот у меня сценарий, ошибка наигрывается непонятно как и непонятно почему» — ваша задача, чтобы разработчик знал, что тут вот рядом человек может найти баги даже не запуская приложение. Не поверите, как вдруг качество продукта возрастает, когда есть человек, который не просто слышит запах плохо пахнущего кода, но и может предложить решения по улучшению.
Мы плавно перешли к
2. Использование шаблонов проектирования для разработки тестового фреймворка.
ДА-ДА. Вы открыли, например, Selenium, — всякие примеры, скопировали бездумно, написали на получившемся «фрэймворке» 1000 тестов. Приходит заказчик к бизнесу, говорит «мне тут нужно кое-что переделать», бизнес приходит к разработчику — «нам тут нужно немного подстроиться под рынок», разработчик всё прекрасным образом запиливает, — 90% тестов падают. Приходят к автоматизатору «мы тут немного поменяли, надо привести тесты в порядок», а автоматизатор в ответ «тут работы на месяц»… Упс…
Архитектура фрэймворка, который вы пишите, должна не просто быть гибкой, а должна постоянно стремиться минимизировать время рефакторинга имеющихся тестов и написания новых. В идеале, если разработчик и автоматизатор одновременно садятся исправлять что-либо, то автоматизатор должен сделать всё быстрее и предоставить разработчику некую форму TDD.
В создании такой чудо-архитектуры нам помогают паттерны проектирования и их грамотное использование… Builder, Facade, Factory, Null Object, Singleton, Adapter и многие другие паттерны активно помогают в решении подобных задач. Грамотная архитектура тестового фреймворка – это счастье для вас, для разработчиков, для бизнеса…и в конечном счёте для пользователя. Помните, что экспоненциальный рост ресурсов поддержки тестов при линейном росте/изменении функционала свидетельствует о том, что вам пора дорабатывать архитектуру движка. С наиболее полным списком паттернов с примерами на Java можете ознакомиться здесь. Отдельно отмечу Page Object Pattern, но лучше, сначала познакомиться с классическими.
3. Использование библиотек
То, что плавно вливается в любые задачи, — внешние API, библиотеки, драйверы и прочие прелести. Selenium — тестируем Web, Robotium/Espresso — тестируем Android, Fest/Jemmy — тестируем Java Swing, JemmyFX — тестируем JavaFX, замечательные Apache HttpComponents — делаем запросы и тестируем множество API, GSON — помогает приводить json к объектной модели и обратно и так до бесконечности… Библиотек прекрасных много написано почти под любую задачу — про некоторые из них можно почитать здесь. Не стоит бояться того, что их много — вы уже достаточно знаете, чтобы выбрать то, что вам подходит/нравится/вписывается в архитектуру. Например, под тестирование Java Swing приложений я использую JUnit, Fest, Mockito и широкие возможности java.lang.reflect — этого набора мне более чем хватает.
Будьте готовы к частому посещению stackoverflow и подобных ресурсов на ранних этапах. Будьте готовы к тому, что иногда надо будет заглянуть в исходники. И самое главное — не бойтесь не разобраться.
5***. Написание утилит и собственных библиотек
Тут звёздочки… У вас уже всё замечательно на проекте, регресс покрыт, тесты гоняются, разработчики спокойны и могут спокойно рефакторить архитектуру, не боясь сломать имеющийся функционал. Но, например, для того, чтобы что-то сэмулировать руками, разработчику приходится проделывать из месяца в месяц одно и то же действие руками. Напишите для него утилиту, оптимизирующую эти процессы, включите туда всякие невалидные сценарии, разрекламируйте на уровне компании, — пусть все начнут пользоваться… Это ускорит работу и, как ни странно, уменьшит количество багов, так как у разработчика появится больше времени на то, чтобы проверить побольше сценариев, прежде чем коммитить измненения в ветку. Оглядитесь по сторонам и вы увидите так много процессов, которые можно автоматизировать, что не будете знать, за что взяться.
Пишите достаточно абстрактные библиотеки, могущие быть использованными на разных проектах в вашей компании, да и просто в вашей работе в будущем.
P.S.
К бизнесу, руководителям, специалистам по подбору персонала:
Профессиональный автоматизатор тестирования в конечном счёте экономит деньги компании, я бы даже сказал, в краткосрочной перспективе. Смотрим сравнение очень близкое к реальности здесь.
Как стать тестировщиком ПО: пошаговая инструкция
Рассказываем, какие книги читать и какие технологии осваивать, чтобы стать тестировщиком ПО.
Тестировщик ПО (или QA-инженер) — распространенная отправная точка для тех, кто хочет начать карьеру в IT-индустрии, и просто востребованная профессия. Мы расскажем, где новичкам набраться полезных навыков и знаний, а также заработать заветные строчки для резюме и проекты для портфолио.
Чем занимаются QA-инженеры
Тестировщики ПО помогают делать продукты — приложения, сайты, программы, автомобили — такими, чтобы ими можно было пользоваться. Они определяют, какие элементы системы функционируют некорректно или не так удобны, как хотелось бы, находят причины этого — ошибки в коде, дизайне или логике — и отдают на исправление. Все это делается для того, чтобы конечные пользователи получили стабильный, надежный и удобный продукт.
Какие навыки нужны начинающему тестировщику
Поскольку тестирование применимо к самым разным областям, то для работы тестировщику могут понадобиться различные знания. Однако что-то общее есть во всех случаях: нужно, во-первых, знать теорию тестирования, ну а уже дальше — обладать некоторым объемом знаний по тестируемой системе и используемым в ней технологиям.
С теорией все довольно понятно: потенциальный работодатель будет хотеть от вас знаний о том, что такое тестирование, зачем оно нужно в цикле разработки и какое место в ней занимает. Также хорошо бы знать основные методологии разработки (AGILE, SCRUM и прочие страшные слова) — просто для того, чтобы вы могли работать в команде, которая функционирует по определенным правилам. Также неплохо знать, как грамотно написать дефект, что такое тест-кейсы и как их нужно составлять, что такое чек-листы, когда лучше использовать кейсы, а когда проще ограничиться чек-листом.
Если теория тестирования применима ко всем областям, то технические навыки, которые вам понадобятся, зависят от области, в которой вы решили работать. Скажем, если вы хотите заниматься тестированием в области веб-приложений, то очень полезно знать, как работает браузер и из чего состоит веб-страница. И вряд ли это вам пригодится, если вы будете заниматься тестированием бортовых систем самолета.
Впрочем, самые популярные направления разработки сейчас — это именно веб и мобильные платформы. С вебом уже разобрались, а для тестирования мобильных устройств нужно знать особенности построения мобильных приложений, их жизненные циклы и отличия от десктопных приложений, особенности Android и iOS, ну и хорошо бы также ознакомиться с руководствами по дизайну приложений для мобильных устройств от разработчиков обеих систем.
Наконец, практически любая современная программа будет использовать базы данных, так что вам нужно будет узнать, что это такое, и научиться писать простые SQL-запросы.
Нужно ли тестировщику уметь программировать
Вопрос, при выяснении которого сломано немало копий: нужно ли тестировщику уметь программировать. Здесь существуют разные мнения, но все сходятся в том, что умение программировать точно не помешает. На старте оно может и не понадобиться, но будет несомненным плюсом. Навыки программирования могут пригодиться как для понимая того, что происходит в тестируемом приложении, так и для автоматизации каких-то рутинных задач, даже если вы не идете именно в автоматизированное тестирование. Если же вас интересует область автоматизации тестирования, то тут ответ однозначен: вам нужно учить какой-нибудь язык программирования. Если вы уже работаете, то хороший вариант — учить тот язык, на котором в вашей компании ведется разработка. Если еще нет — учите любой из популярных сегодня языков.
Если уж мы говорим про языки, то тестировщику очень полезно знать еще один язык — английский. Хотя бы на уровне чтения документации. Без этого можно работать, но множество материалов сейчас на английском, и его знание может очень помочь.
Как учиться начинающему тестировщику ПО
Учиться лучше так, как удобнее лично вам: по книгам, по статьям, по видеокурсам — или по всему сразу. К счастью, про тестирование очень много материалов в любой форме, так что с поиском информации проблем возникнуть не должно.
Есть множество блогов от известных тестировщиков, есть статьи по тестированию на тематических ресурсах, YouTube полон видеокурсов, в том числе от крупных компаний, есть множество докладов с конференций по тестированию, которые может быть полезно посмотреть. Кстати, на конференциях часто бывают доклады именно для начинающих тестировщиков.
Кроме того, есть образовательные платформы вроде Coursera или Udemy с обучающими курсами, в том числе бесплатными.
Можете начать погружение в тему с книг — приведем четверку самых, на наш взгляд, полезных:
Некоторым из них уже по 20 лет, а написаны они не очень простым языком, но по-прежнему актуальны — особенно как база для начинающих.
Если решите записаться на один из множества платных курсов для начинающих тестировщиков, помните: не все они одинаково полезны, и не всегда в них есть что-то, чего нет в бесплатных.
Пожалуй, основное отличие платных — наличие преподавателя, который сможет ответить на ваши вопросы. Помимо прочего, многие IT-компании открывают собственные школы QA-инженеров и затем принимают самых способных учеников в штат. Обратите на них внимание, если вам хочется попасть к какому-то конкретному работодателю.
Как начать карьеру тестировщика
Когда поймете, что готовы перейти к реальным проектам, выберите какой-нибудь сайт или приложение и попробуйте его протестировать. Подготовьте тест-кейсы, составьте чек-листы для проверки работоспособности, подумайте, как бы вы проследили взаимодействие продукта с его серверной частью — бэкендом.
Первые реальные проекты лучше искать на платформах для краудтестинга. Там компании предлагают всем желающим протестировать их продукт на определенном устройстве и ОС. Скорее всего, работать придется за идею, то есть бесплатно, зато вы наберетесь опыта и посмотрите, как опытные QA-инженеры ведут дефекты.
Неплохой старт для начинающего тестировщика — проект с открытыми исходным кодом и баг-трекером. Это уже не только практика, но и неплохое дополнение к вашему резюме.
Наконец, не забывайте про стажировки в IT-компаниях. На много денег поначалу рассчитывать не стоит, однако если вы проявите себя, есть шанс получить приглашение на работу или рекомендацию для будущих собеседований.
Бета-тестеры и тестировщики ПО
Еще один вариант для старта карьеры — это бета-тестирование. В этом случае вы будете проверять работу программы с точки зрения конечных пользователей. Основная задача бета-тестеров — найти максимальное количество ошибок, а также определить, насколько продукт удобен.
Бета-тестерам не приходится писать скрипты и взаимодействовать с изнанкой программ, так что их работа проще и не требует глубоких знаний, поэтому вы сможете совмещать бета-тестинг с освоением теории. Такая работа развивает мышление тестировщика, учит искать в программе ошибки, позволяет придумывать и проверять неочевидные пользовательские сценарии. Это хорошая практика, которая сделает ваши резюме и портфолио еще привлекательнее.
Крупным IT-компаниям — разработчикам игр, приложений для ПК и мобильных устройств, чьими продуктами пользуются миллионы людей, бывает сложно проработать все пользовательские сценарии. Так что не удивляйтесь: «Лаборатория Касперского» тоже ищет бета-тестеров. Хотите стать одним из них? От вас потребуется только компьютер, который поддерживает актуальную версию антивируса. Желательно установить на него виртуальную машину (например, Hyper-V или VMware), чтобы не превращать в тестовый полигон собственный ПК. Минимальные характеристики для комфортной работы — 4 Гбайт оперативной памяти, а также процессор с двумя, а лучше четырьмя физическими ядрами.
Если хотите попробовать себя в роли тестировщика — пробуйте, это полезная и востребованная профессия, да и порог входа в нее не такой уж высокий. В общем, дерзайте! Ну и смело жмите сюда, если хотите получить опыт бета-тестирования в Kaspersky.