Когда начинаешь погружаться в тестирование, создается ощущение, что видов этого самого тестирования десятки, если не сотни, и все они постоянно используются в реальной работе. Из-за этого у многих возникает ложное ощущение, что для работы тестировщиком нужно разбираться во всех этих подходах и уметь применять каждый из них. Но более чем за шесть лет работы в тестировании я понял одну вещь: теория этой работы сильно отличается от практики.
Чаще всего используется ограниченный набор видов тестирования, которые закрывают большую часть задач. Причем это не абстрактные академические термины, а конкретные подходы и практики, с которыми вы сталкиваетесь почти каждый день.
В этой статье рассмотрим пять видов тестирования, которые применяются чаще всего. Заодно разберем, как они выглядят в реальной работе, когда используются и какие ошибки чаще всего с ними связаны.
Автор: Антон Дуенин, автор YouTube-канала «Горящий Тестер».
Исследовательское тестирование
Исследовательское тестирование — это тестирование без заранее подготовленных сценариев. У вас нет тест-кейсов, нет четкого списка шагов, которые нужно пройти. Есть только ваш опыт, интуиция и продукт. Главная задача здесь — понять, как система работает и где может сломаться.
На практике это выглядит максимально просто: вы открываете приложение и начинаете с ним взаимодействовать. Нажимаете кнопки, вводите разные данные, пробуете нестандартные сценарии, комбинируете действия. В каком-то смысле это напоминает игру «а что будет, если…».
Как это используется в работе
Чаще всего такой подход применяется в двух ситуациях. Первая — как уже сказано, у вас еще нет подробной документации или тест-кейсов. Например, пришла новая фича, и нужно быстро понять, как она вообще работает.
Вторая — когда хочется выйти за рамки заранее описанных сценариев. Даже если тест-кейсы есть, они почти всегда покрывают только ожидаемое поведение системы. Но реальные пользователи делают ошибки, вводят странные данные, нажимают кнопки «не в том порядке». Именно здесь исследовательское тестирование представляет наибольшую ценность.
Эффективность исследовательского тестирования
Главное преимущество этого подхода — способность находить неожиданные баги. Когда вы не ограничены сценариями, вы начинаете проверять продукт более свободно и за счет этого натыкаетесь на ситуации, которые никто заранее не продумал.
Иногда это довольно забавные кейсы. Например, в интерфейсе может быть кнопка, про которую просто забыли — она есть, но ее очень давно никто не трогал и не менял, и как-то получилось, что она не попала в тест-кейсы. В рамках исследовательского тестирования внезапно выясняется, что эта кнопка уже сто лет не работает и никто этого не замечал.
Исследовательское тестирование хорошо работает для новых членов команды. Когда человек только приходит в проект, у него еще нет устоявшихся ожиданий о том, как должен работать продукт, глаз еще не замылился, как у коллег. За счет этого он смотрит на приложение более свежим взглядом и часто находит баги там, где остальные их уже в упор не замечают.
Ограничения
Несмотря на свою полезность, исследовательское тестирование нельзя считать универсальным решением.
Во-первых, оно плохо воспроизводимо. Если один раз у вас случился чрезвычайно удачный прогон исследовательского тестирования, в котором вы нашли кучу серьезных проблем, то не факт, что в следующей итерации вы не пропустите другие критические проблемы в том же функционале.
Во-вторых, результат сильно зависит от опыта тестировщика. Один человек найдет десятки проблем, а другой — почти ничего, просто потому что они по-разному взаимодействуют с продуктом, каждый в силу собственной профессиональной насмотренности.
В-третьих, есть риск пропустить базовые сценарии. Увлекаясь исследованием, легко забыть проверить что-то очевидное.
Ключевая проблема одна — если у вас нет четкого плана, то и уверенности в покрытии и качестве тестов тоже не может быть.
Мобильная ферма Selectel
Начните тестировать на реальных устройствах за 2 минуты – откуда угодно.
Smoke-тестирование
Smoke-тестирование — это самая базовая и быстрая проверка по принципу «Оно вообще работает или совсем сломано?». Смысл в том, чтобы не тратить время на детальное тестирование, если система в принципе не функционирует. Это первый фильтр, который позволяет отсеять очевидно нерабочие сборки или фичи.
На практике smoke-тест — это несколько простых действий без особой глубины, которые проверяют ключевой сценарий. Например, открывается ли приложение, можно ли в нем залогиниться, добавить товар в корзину и совершить оплату.
Когда применяется
Обычно smoke-тестирование делают перед основным тестированием. Прежде чем открывать тест-кейсы и тратить время на детальную проверку, имеет смысл быстро пройтись по самым важным сценариям. Причем проводиться оно может на любом уровне: для тестирования одной функции в коде, одной конкретной фичи, одного модуля или всего приложения.
Потому что иначе тестировщик может оказаться в ситуации, когда он потратил два дня на тестирование каких-то не самых важных вещей, а потом выяснил, что ключевой сценарий вообще не работает. А чтобы его починить, придется перелопатить вообще весь код. Значит, все его время было потрачено впустую, ведь после фикса придется заново проходить те же тесты, потому что код изменился.
Почему smoke-тестирование часто пропускают
Частая причина — доверие к разработчику или к процессу. Кажется, что «ну базово точно работает, разработчик же не мог просто залить код на тест без проверки его работоспособности», поэтому можно сразу переходить к более сложным сценариям. В условиях спешки это особенно типично — хочется быстрее закрыть задачу.
Но на практике даже самые очевидные вещи иногда ломаются. Разработчик мог проверить не весь сценарий или вообще не проверить ничего, рассчитывая на собственный опыт. Или локально у него действительно все работает, но на реальном стенде что-то, что было сложно предсказать, идет не так. И чем раньше это обнаружится, тем меньше времени потратит команда.
Главная ценность smoke-тестирования — экономия времени. Несколько минут на базовую проверку могут сэкономить часы работы, если окажется, что система изначально в нерабочем состоянии.
Бонус для прохождения собеседования
На собеседованиях любят задавать вопрос: чем smoke-тестирование отличается от sanity-тестирования? Ответ во многом зависит от личного мнения тестировщика. Кто-то говорит, что sanity шире, чем smoke. Кто-то уверен, что sanity проводится только на проде.
Лучший вариант в данной ситуации — ссылка на авторитетный источник, а именно на глоссарий ISTQB. Ответ в этом случае будет такой: smoke-тестирование ничем не отличается от sanity-тестирования. Это синонимы.
Тестирование совместимости
Тестирование совместимости – это проверка того, как продукт ведет себя в разных условиях. В теории звучит очевидно, но на практике возникает много проблем. Очень легко протестировать фичу в одном окружении и предположить, что точно так же она будет работать везде. Однако это не так.
Что именно и как проверяется
Речь идет о разных вариантах окружения, в которых может работать продукт. Это могут быть разные устройства, браузеры, экраны или настройки отображения, разные операционные системы или их разные версии. Даже если визуально устройства выглядят одинаково, поведение системы может отличаться.
Типичная ситуация: вы протестировали фичу у себя на телефоне — все работает корректно, багов нет. Но потом оказывается, что у другого пользователя или на другом устройстве что-то идет не так.
Пример из моего опыта. Передо мной стоят два монитора. Один — с разрешением FullHD, другой — 4К. При этом диагональ у обоих мониторов одинаковая и выглядят они почти идентично. Если открывать приложение на 4К-мониторе — все отлично, верстка выглядит как надо и никаких проблем нет. Но если открыть то же приложение на соседнем FullHD-мониторе, то в одном из маленьких текстовых полей появляются два огромных неактивных скролла, которые ломают вообще всю верстку страницы.
Ситуация достаточно уникальна — я встречал такое лишь раз и больше с подобными проблемами за шесть лет не сталкивался. Но вот баги на разных девайсах или браузерах всплывают намного чаще.
Почему важно тестировать совместимость
Проблема в том, что пользователь всегда работает в своем собственном, порой непредсказуемом окружении, а не в вашем, где все отлажено. И если тестирование ограничивается одной конфигурацией, есть риск пропустить ошибки, которые проявятся уже в продакшене.
Часто это именно те баги, которые сложно воспроизвести, потому что нужного девайса нет в наличии или никто не подумал о том, что на другой версии операционки часть фич работала иначе. Ну или банально никто не вспомнил, что наше приложение вообще-то еще и на планшетах устанавливают, а там с ним совсем беда.
Самая распространенная ошибка — протестировать на одном устройстве и считать задачу закрытой. Создается ложное ощущение, что все работает корректно, хотя на самом деле проверка была слишком узкой.
Как избежать проблем
Лучшая практика — собирать аналитику по тому, с каких девайсов и на каких окружениях пользователи приходят в ваше приложение и тестировать в первую очередь на тех, которые согласно этой аналитике находятся в топе. Если 99% ваших юзеров заходят через Safari, то и тестировать в первую очередь надо через Safari, а не через Google Chrome, который просто вам больше нравится.
Та же история с девайсами — если большинство пользователей используют Android-приложение, то и тестам Android-версии нужно уделить больше внимания, чем iOS.
Где взять девайсы
К сожалению, не всегда проблема с устройствами решается так легко, как в примерах выше. В реальности вполне возможна ситуация, когда для разных тестов вам нужны абсолютно разные модели, а в наличии их просто физически нет ни в офисе компании, ни уж тем более на удаленке.
В таких ситуациях может помочь ферма мобильных устройств Selectel. Там доступны более 200 реальных смартфонов iOS и Android для удаленного подключения и тестирования на них. Подробный гайд по использованию фермы мобильных устройств вы найдете в этой статье.
Регрессионное тестирование
Регрессионное тестирование (или регресс) — это проверка того, что после изменений в системе ничего не сломалось. Любая доработка, даже самая небольшая, может повлиять на уже существующую функциональность. Добавили новую фичу, поправили баг, изменили логику — в каком-то другом месте система начала работать неправильно. Задача регрессионного тестирования — такие ситуации отлавливать.
Регресс проверяет только те части приложения, которые в теории не должны были быть задеты изменениями. Если тестируется функционал, о котором известно, что он был изменен в рамках текущего релиза или задачи — это уже не регресс.
Когда и как проводится
Регресс возникает практически постоянно: после фикса бага нужно проверить, что он действительно исправлен, и при этом не появились новые проблемы (то есть провести регресс соседних фич). А после добавления новой функциональности необходимо убедиться, что старые сценарии по-прежнему работают. То есть это не разовая активность, а регулярная часть процесса.
На практике это означает, что тестировщику приходится снова проходить уже знакомые сценарии: то, что вчера работало, сегодня нужно проверить еще раз. И так после каждого значимого изменения. Это может быть как полный прогон всех сценариев, так и частичный — в зависимости от того, что именно менялось.
Основная сложность
Главная проблема регрессионного тестирования — его объем. С течением времени система растет, сценариев становится все больше, и проверять их вручную становится сложнее и дольше.
Поэтому критически важно научиться правильно планировать регресс: оценивать риски, расставлять приоритеты, определять наиболее вероятные места возникновения багов и выстраивать процессы так, чтобы всегда выделялось время на достаточный объем регрессионного тестирования. Обычно такими вещами занимаются лиды тестирования на проекте, но общее понимание принципов формирования регресса пригодится любому тестировщику.
При этом пропуск регрессии — одна из самых частых причин появления багов в продакшене. Почему без него нельзя? В некоторых ситуациях можно соблазниться и сократить объем проверок, особенно если изменения кажутся незначительными. Но часто именно такие изменения и дают неожиданные побочные эффекты.
Регрессионное тестирование — это та часть процесса, которая защищает продукт от постепенной деградации и появления «неожиданных» багов там, где мы «ничего не трогали».
Приемочное тестирование на проде
Приемочное тестирование — это проверки, которые происходят уже после выката изменений в продакшен. Формально тестирование, конечно, должно завершаться до релиза. Но на практике почти всегда появляется необходимость в дополнительной проверке. Иногда это плановая активность, иногда — реакция на проблемы, которые начали возникать сразу после релиза.
На разных проектах его называют по-разному: пост-релизное тестирование, smoke на проде, приемочное тестирование, релизное тестирование. Название большого значения не имеет, важна суть: на этом этапе продукт оказывается в реальном окружении, с реальными пользователями и нагрузкой. И именно здесь могут проявиться проблемы, которые не были видны раньше.
Что происходит на практике
Типичный сценарий — после релиза начинают всплывать баги в огромных количествах. Чаще всего это происходит из-за того, что во время релиза что-то пошло не так. Например, новая версия фронта дошла до прода, а новая версия бэка — нет, и теперь на проде лежат две несовместимые друг с другом части приложения, которые и рисуют кучу ошибок в логах.
Или при разработке и выкатке на прод не учли какие-то особенности и зависимости прод-окружения, и ваше приложение не может нормально взаимодействовать со сторонними интеграциями. Например, при оплате ваше приложение, как и на тестовом стенде, ожидает ответ на свой запрос от test.bank.ru, а получает ответ от bank.ru и возвращает ошибку.
Часто это сопровождается срочными исправлениями (хотфиксами), откатами релизов, повторными проверками, общей напряженностью и суетливостью в команде.
Отличительные черты приемочного тестирования
Продакшен — это единственная среда, где продукт используется по-настоящему. Как бы хорошо ни было проведено тестирование до релиза, полностью воспроизвести реальные условия невозможно. Поэтому приемочное тестирование на проде — это своего рода последний уровень проверки.
Однако не стоит забывать про главную особенность этого этапа — цена ошибки здесь очень высока. Если баг найден на этапе разработки — это локальная проблема. Но если проблема выявлена после релиза, это уже влияет на пользователей, репутацию и заработок компании. Именно поэтому любые недоработки, пропущенные ранее, на этом этапе ощущаются особенно болезненно.
Хорошо, если у вас есть возможность выкатить релиз на прод так, чтобы сначала его увидели только сотрудники вашей компании, спокойно проверили, что все в порядке, и только после этого раскатили релиз на всех остальных пользователей.
Вывод
Несмотря на большое количество терминов и классификаций, в реальной работе тестировщика большая часть задач сводится к ограниченному набору практик:
исследовательское тестирование помогает находить неожиданные проблемы;
smoke-тестирование — быстро понять, работает ли система в принципе;
тестирование совместимости — проверить поведение в разных условиях и на разных девайсах;
регрессионное — убедиться, что изменения не сломали старый функционал;
приемочное тестирование — поймать то, что проявилось уже после выкатки релиза на прод.
Важно не просто знать эти виды тестирования, а понимать, когда и зачем их применять. Ошибки чаще всего возникают не из-за отсутствия сложных техник, а из-за пропуска базовых проверок или неверных предположений о том, как работает система. Все эти виды тестирования не существуют отдельно друг от друга — они используются вместе и дополняют друг друга в рамках одного процесса.