В статье рассматривается отличительные особенности кроссбраузерного тестирования и их автоматизация.
Ключевые слова: кроссбраузерное тестирование, кроссплатформенное тестирование, функциональное тестирование, багтрекинговая система, метки, cross browser testing, дефекты.
Для проведения кроссбраузерного/кроссплатформенного тестирования используется определенный набор клиентского программного обеспечения. При этом зачастую и функциональное тестирование, и кроссбраузерное/кроссплатформенное тестирование проводится в рамках системного теста одновременно. При проведение системного теста программного обеспечения важно понимать отличительные особенности между функциональным дефектом системы и кроссбраузерным/кроссплатформенным. Грамотное определение вида дефекта и последующее его оформление в багтрекинговой системе помогут эффективно организовать работу команды тестирования и разработки.
Кроссплатформенный/кроссбраузерный дефект проявляется визуально и может быть обнаружен как при тестировании основного набора тестов, так и в рамках кроссплатворменного/кроссбраузерного тестирования.
Основные характеристики такого дефекта следующие:
искажение отображения того или иного элемента на странице частичное или полное (иконки, кнопки, таблицы, строки таблиц, меню, атрибуты, формы создания или формы балкового изменения объектов, всплывающие окна, вызов окон других компонент и др., как в режиме редактирования, так и в режиме просмотра) особенно затрагиваются в этом случае так называемые «кастомные» страницы компонент;
затруднение работы с элементами пользовательского интерфейса (невозможно заполнить значение из выпадающего списка для референсного/листового атрибута, невозможность редактирования в режиме ‘In-gread’, исчезновение' кнопок и других элементов пользовательского интерфейса, которое с примененными к пользователю не связано с правами, другое) [3].
Некоторые кнопки или части пользовательского интерфейса видны только под специальными ролями пользователей. И тут не следует путать их с кроссбраузерными/кроссплатформенными дефектами.
Любые дефекты на back end не могут быть кроссплатформенным/кроссбраузерным дефектом. Сюда относятся вычисление значений калькулируемых, поиск путей (именно поиск, а не их последующе отображение через визуальный компонент) и т.п [5].
Чтобы понять является ли дефект россплатформенным/кроссбраузерным рекомендуется выполнить шаги по исключению дефекта из функциональных:
– дефект касается только искаженного отображения пользовательского интерфейса;
– если тестирование проводится под локализацией, то следует отключить сначала локализацию и проверить отображение;
– если тестирование проводится под основным браузером, то проверить как ведет себя система под другими браузерами;
– если тестирование проводилось в рамках кроссплатформенного/кроссбраузерного тестирования, то нужно проверить как ведет себя система под другими браузерами;
– тестирование проводится под основной UI темой.
Если функциональный дефект никаким образом не мешает выполнить кроссплатформенное/кроссбраузерное тестирование, то на статус тестового сценария из набора кроссплатформенного кроссбраузерного тестирования он не влияет, но их обязательно нужно слинковать к соответсвующим тестовым сценариям в багтреккинговой системе.
Если проблема воспроизводится на всех конфигурациях ОС+Браузер, то дефект считается функциональным. Если проблема воспроизвелась на некоторых конфигурациях ОС+Браузер, то дефект считается кроссплатформенным/кроссбраузерным.
Для определения статуса тестового сценария в багтреккинговой системе при кроссплатформенном/кроссбраузерном тестировании рекомендуется использовать следующую таблицу ниже [2]:
|
Статус |
Описание |
|
Blocked |
Блокировать сценарий может только функциональный дефект, который мешает провести кроссплатформенное/кроссбраузерное тестирование. Крайне редко возможны случаи, когда страница не открывается для конкретно проверяемой конфигурации и тогда блокирующим дефектом будет кроссплатформенный/кроссбраузерный дефект. |
|
Failed |
Ставится только в случае, если имеется кроссплатформенный/кроссбраузерный дефект приоритета Critical, Major (или имеются дефекты приоритетов Normal и Low и их суммарное количество на один тест кейс превышает 10) особенно если он создан на сочетание Основная операционная система+Основной браузер |
|
Passed With Minor Defects |
Ставится в случае, если имеется кроссплатформенный/кроссбраузерный дефект приоритетов Normal и Low и их суммарное количество на один тест кейс не превышает 10. |
|
Passed |
Ставится в случае, если кроссплатформенных/кроссбраузерных дефектов не обнаружено (даже если есть неблокирующие функциональные дефекты) |
Тестировщик выбирает тестовый сценарий и просматривает UI каждой страницы под разным окружением параллельно для экономии времени и прохождения пререквизитов и одинаковых шагов один раз. Таким образом одноименные тестовые сценарии под каждое окружение будут в статусе ‘In Progress’, а затем одновременно сменят статус на актуальный. Статусы на каждом окружении могут быть разными. Основные шаги проводятся в Ubuntu/MacOS: клики кнопок, которые фатально (то есть назад не вернуться без повторного прохождения кейса с начала) меняют состояние страницы.
Таким образом, распределение дефектов на соответствующий вид (функциональный или кроссплатформенный/кроссбраузерный), а также адекватное назначение ему статуса позволит эффективно приоритезировать работу команды разработки и распределить усилия команды тестирования. А применение LambdaTest [1], представляющее собой облако для кроссбраузерного тестирования, в котором возможно параллельно запускать несколько тест-кейсов Selenium на нескольких комбинациях из устройств и браузеров, позволит существенно снизить затраты на создание собственной «лаборатории» для кроссбраузерного тестирования и тестирования на различных устройствах.
Литература:
- S.Scacca. How To Make Cross-Browser Testing More Efficient With LambdaTest [Электроный ресурс].— URL: https://www.smashingmagazine.com/2020/02/cross-browser-testing-efficient-lambdatest/ (дата обращения: 27.04.2021).
- N. Barskar and C. Patidar, A Survey on Cross Browser Inconsistencies in Web Application// International Journal of Computer Applications, vol. 137, nº 4, pp. 37–41, 2016.
- V. Garousi, M. Felderer and T. Hacaloğlu, “What We Know about Software Test Maturity and Test Process Improvement,”IEEE Software, vol. 35, nº 1, pp. 84–92, 2017.
- Selenium Testing Online For Browser Test Automation [Электроный ресурс] — URL: https://www.lambdatest.com/selenium-automation (дата обращения: 20.04.2021).
- Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация: пер. с англ. / Рэшка Д., Дастин Э., Пол Дж.; пер. Молодцова Е., Павлов М. — М.: Лори, 2019. — с.120.
