Что-то на айтишном: тестировщик

— В IT часто говорят на смеси языков. Когда я впервые устроилась работать в IT-компанию, я редко понимала диалоги коллег, — вспоминает Ирина, — К тому времени я уже хорошо умела тестировать, но не привыкла общаться на этой смеси английского, русского и айтишного. Было очень сложно и обидно. Понимая эту «боль», хочу поделиться набором слов и выражений, которые помогут чувствовать себя на одной волне с опытными коллегами.

Как общается тестировщик

Слово, которое знакомо каждому тестировщику, — баг.

Баг — это несоответствие поведения приложения требованиям заказчика. Еще можно сказать, что баг — это неожиданное для пользователя, нежелательное поведение приложения или программы.

Помимо багов тестировщики часто предлагают вниманию команды «импрувменты» — предложения по улучшению сайта или программы.

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

Каждый день тебя ожидают митинги (они же миты), коллы, синки и дейли.

• Meeting — это рабочее совещание. Обычно они назначаются заранее и отмечены в календаре. Можно получить инвайт (приглашение) на митинг или пошарить линку (поделиться ссылкой) на митинг со своим коллегой.
• Call — созвон с одним или несколькими коллегами. Часто можно услышать «извини, у меня срочный колл, мне надо ответить».
• Sync — сокращение от synchronization. Это тот же митинг или колл. Обычно говорят «давай синканемся по этому поводу отдельно». Что означает «давай синхронизируем наши знания и понимание по этому вопросу».
• · Daily (сокращение от daily meeting) — ежедневное совещание команды. Как правило, проходит по утрам. Но бывает по-разному.

На митингах вы будете обсуждать борду, тикеты, апдейты

• Board — это рабочая доска или рабочее место каждого члена команды в отдельности и всей команды в целом. Чаще всего пользуются приложением Jira для того, чтобы трекать (отслеживать) свою ежедневную работу. В зависимости от проекта можно использовать, например, Scrum board или Kanban board. В любом случае доска выглядит как набор задач, ответственных и статусов.
• Ticket – это как раз и есть задача, выраженная в письменной форме. Тикеты выглядят как стикеры на доске. Они могут содержать очень большую задачу (эпик), или задачу поменьше (стори), или еще поменьше (таску). А могут содержать описание бага. Самые главные для тебя тикеты те, что имеют статус RFQA (Ready for QA).
• Update —это новости. Пошарить апдейты означает «поделиться новостями или статусом какой-то задачи».

Проверифайить тикет означает проверить его и убедиться, что все работает, как надо.

— Если, например, вы проверили баг-тикет, и все работает как надо, значит баг пофиксили (от слова fix — чинить). Если же после проверки видно, что баг все еще там, то можно реопнуть тикет (от слова reopen — открыть заново) и вернуть тикет разработчику.

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

Иногда мы тестируем какую-то интересную сторю (story). И изобретаем экзотический сценарий, при котором приложение ведет себя плохо (есть баги или какие-то всплывающие не к месту предупреждения). Тестировщику может казаться, что это ужасно и нужно срочно это пофиксить. Но бизнес-аналитик (он же BA) или продакт оунер (он же PO) может сказать «ничего страшного, это corner case — положите пока в backlog». Что-что?! — думаете вы. Какой-какой кейс?! Куда его положить?! На самом деле коллега сказал следующее: «Этот сценарий — редкость. Пользователь вряд ли встретит этот баг. Можно пока отложить его и поместить в копилку багов и задач, которые ожидают своей очереди».

«Баг или фича»

— Часто между разработчиком и тестировщиком возникает спор на тему «баг или фича». Если вы, к примеру, нашли неожиданное поведение приложения, то можно принять его за баг. Но девелопер может возразить, что все сделано по требованиям. В таком случае, чтобы разрешить спор, нужно руководствоваться аксептанс критериями (acceptance criteria) соответствующей стори. Ассеptance criteria — это набор требований, разработанных BA. Фича (feature) — это особенность приложения, какая-то опция, сделанная специально (не баг).

Когда какую-то новую функцию приложения уже доделали (дописали код, проверили ее), говорят, что фичу заимплементили (implemented).

Как все знать

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

Мемы по теме — в разделе Мемасная.