Перевод статьи «Let’s be honest, in some places, QAs are not respected by other team members».
“Мы, разработчики, что-то создаем, а QA – ничего”. “Ненавижу тестировщиков и проджект-менеджеров”. “Почему QA так раздражают?”. “Любой может быть QA”… Этот список негативных комментариев можно продолжать, но про PM это правда (шутка). Кстати, я не обижаюсь, вернее, уже не обижаюсь. На самом деле должность QA-инженера, или как однажды разработчики сократили ее просто до “тестировщика”, часто недооценивают в некоторых компаниях. Особенно это заметно в тех редких случаях, когда разработчики тратят значительное количество времени на добавление в приложение нового функционала или вносят исправление или улучшение, а на проверку уходит всего несколько минут. Такое, конечно, иногда может случаться, однако мне кажется, что некоторые члены команды занижают значимость работы QA по нескольким основным причинам, которые будут рассмотрены далее.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Область тестирования не до конца понятна членам команды
Тестирование включает в себя несколько валидаций вне зависимости от того, насколько простым кажется вносимое изменение. Работа QA заключается в том, чтобы проверить специфику изменения и понять, какие еще области приложения оно может затронуть. Даже если конкретные изменения работают, QA должен удостовериться, что приложение функционирует так, как было задумано, выявить места, где есть ошибки и недоработки, и сообщить о них дизайнерам, разработчикам или проджект-менеджерам. QA-инженер также должен убедиться, что пользовательский опыт соответствует бизнес-целями и потребностями конечных пользователей. И это мы упомянули только очень важную ручную часть тестирования, а ведь еще нужно внедрять и поддерживать автотесты.
Рассмотрим простой пример: переименование нового фильтра, который отображает фильтры-теги при его выборе. Фильтр должен сохраняться при сохранении отчета.
В этом сценарии вам (PM, разработчику… кому угодно) может показаться, что протестировать его будет очень просто. Вы входите в приложение и проверяете, что фильтр был переименован – все просто! Однако на самом деле все гораздо сложнее. Для начала QA должен выполнить ручное тестирование, проверив, что:
- Фильтр был переименован корректно в соответствии с требованиями
- У метки-тега новое название
- Метка фильтра выглядит корректно в мобильном приложении и на десктопном разрешении, особенно если новое имя значительно длиннее
- При создании и сохранении отчета фильтр тоже сохраняется
- При повторном открытии отчета он будет отображать фильтр и данные, отфильтрованные по тем же критериям, что и при его сохранении
- Можно выбрать другой фильтр
Тестирование доступности (Accessibility testing):
- Могу ли я выбрать новый фильтр с клавиатуры, без использования мыши?
- Тестирование доступности можно выполнять с помощью таких инструментов, как например BrowserStack или Axe
Затем QA проанализирует, как новый фильтр может повлиять на работу приложения. Для этого он проведет исследовательское тестирование, основываясь на своем опыте и интуиции, без заранее подготовленных тест-кейсов.
QA автоматизирует тестирование
На следующем этапе QA переходит к автоматизированному тестированию. Автоматизацией можно заниматься на всех стадиях, как до, так и после передачи продукта в продакшн:
- Можно ли автоматизировать предыдущие ручные тесты?
- Стоит ли добавлять эти тесты в автоматизацию? Насколько важен и полезен этот фильтр или или другие фильтры на странице?
- Делали ли мы автотесты для подобного фильтра? Есть ли у нас автоматизация для всех фильтров на этой странице?
- Какие модульные тесты написаны для этого функционала?
- Есть ли у нас уникальные идентификаторы (id) для названий фильтров, поля выбора фильтра, выпадающего списка с фильтрами или для других типов фильтров?
- Если нет, давайте добавим id для автотестов или попросим разработчиков сделать их
- Уникальные id готовы?
- Если да, автоматизируем следующий сценарий:
///<reference types="cypress" />
describe("Medium Screen: Filters", () => {
before(() => {
cy.logInThroughApi("my-medium-post@gmail.com", Cypress.env("password"))
cy.visit("/where-my-filter-is")
})
after(() => {
cy.deleteReportThroughApi()
cy.logoutThroughApi()
})
it("should check new filter 'Medium' exists", () => {
cy.getBySelector("my-filter-name").should("exist")
cy.getBySelector("my-filter-name").should("have.text", "Medium")
})
Сценарий, который должен был бы написать QA-инженер:
/// <reference types="cypress" />
describe("Medium Screen: Filters", () => {
const filters_name = [{
name: "Age",
test-id: "age-filter"
},{
name: "Medium",
test-id: "medium-filter"
},{
name: "Author",
test-id: "author-filter"
}]
before(() => {
cy.logInThroughApi("my-medium-post@gmail.com", Cypress.env("password"))
cy.visit("/where-my-filter-is")
})
after(() => {
cy.deleteReportThroughApi()
cy.logoutThroughApi()
})
it("should check filters are correctly named", () => {
filters_name.forEach((item) => {
cy.getBySelector(item.name).should("have.text", item.name)
})
})
it("should check new filter 'Medium' is saved when report is saved", () => {
cy.getBySelector("my-filter-name").type("Medium articule{ENTER}")
cy.getBySelector("save-report").click()
cy.visit("/go-to-reports")
cy.getBySelector("retrieve-report").type("Medium articule{ENTER}")
cy.getBySelector("my-filter-name").should("be.visible")
})
})
// Note: лучше было бы использовать другой подход: создать отчет через API, затем открыть страницу отчетов, найти этот созданный отчет и затем проверить видимость тегов фильтров
Смотрите также: “Тестирование API в Cypress”
Как видите, в первом примере QA просто проверяет наличие и видимость названия фильтра. В то время как во втором подходе он протестировал также другие фильтры на странице и сделал проверку простого сценария пользовательского пути. Таким образом, этот фильтр проверяется также в интеграции с функционалом отчетов.
Смысл заключается в том, что QA не просто проверяет видимость элемента. Его задача — имитировать критичные пользовательские сценарии, чтобы убедиться, что всё работает так как должно, и элементы правильно отображаются на экране. Подготовка к тестированию требует времени. Тест-кейсы должны разрабатываются под каждый продукт индивидуально и с вниманием к деталям. Нужно провести исследовательское тестирование, понять, как работает фича, и на основе этого разработать хорошо структурированный тест-кейс. Требуется также проанализировать элементы в html страницы (DOM), чтобы понять, какие из них лучше всего использовать для проверок, чтобы автотесты были стабильные и не нагружали фреймворк.
QA должен глубоко разбираться во всех тонкостях продукта, иначе на него не смогут полагаться
QA-специалистам необходимо глубоко понимать продукт, который они тестируют. QA должен также хорошо разбираться в продукте, как PM или продукт-оунер (PO). Проблема заключается в том, что если вы недостаточно хорошо разбираетесь в тестируемом приложении, то другие члены команды не смогут вам доверять. Как QA-инженер может обеспечивать качество, если он не разбирается в продукте? Это частая ошибка среди QA, так как досконально разобраться действительно бывает нелегко. Как стать экспертом по продукту, если нужно одновременно быть и экспертом по QA, и по автоматизации и по CI/CD? Что ж, в этом я тоже пытаюсь разобраться.
Пропуск багов на продакшн
Когда баги все-таки попадают на прод, члены команды могут обвинить в этом QA, доверие подрывается и вся деятельность QA ставится под сомнение… Однако кто-нибудь задумывался о возможных причинах пропуска багов?
- Могли ли баги быть вызваны изменениями в требованиях, добавленными в последний момент?
- Учитывалось ли мнение QA при обсуждении влияния этих новых изменений на качество?
- Проводилось ли тестирование в условиях нехватки времени?
- Исправление было передано команде QA в последний момент?
- Достаточно ли четко были сформулированы требования?
- Были ли изменения в требованиях достаточно понятны?
- Хватило ли времени, чтобы составить полноценный тест-план?
Можно обсуждать эту интересную тему часами. Я обратила внимание на то, что такое отношение к QA-инженерам возникает обычно тогда, когда проджект-менеджеры не сильно разбираются в программном обеспечении и жизненном цикле разработки ПО. Причиной также могут быть ситуации, когда разработчики не обращают внимание на качество. Или когда в команде разработчики сеньоры, а тестировщики – джуны и поэтому своершают ошибки. Радует, что в последнее время я наблюдаю это не так часто. Например, в компаниях, которые нанимают больше senior QA, такое отношение встречается реже. Кроме того, разработчики становятся всё более квалифицированными в процессах обеспечения качества и тестирования, что приводит к большему уважению к тестированию, а следовательно, и к самим QA-инженерам.