Повний посібник з англійської для QA-інженерів

Англійська мова для інженерів

Забезпечення якості є в основному комунікаційною дисципліною. Інженер з контролю якості, який виявляє критичну помилку, але не може описати її достатньо чітко, щоб розробник міг відтворити її, не виконав повністю свою роботу. План тестування, який є неоднозначним або неповним, призводить до пропущених найкращих випадків і спірних результатів тестування. Критерії прийняття, написані неясною мовою, стають джерелом нескінченних «це помилка або функція?» дебатів в кінці спринту. У QA, англійська точність не є м'якою вмінням - це основна інженерна компетентність.

Англійська мова, необхідна для QA, охоплює кілька форматів: структуровану, засновану на доказах мову звітів про помилки; процедурну, покрокову мову тестових випадків; спільну мову планування спринту і критерії прийняття; технічний словник автоматизації тестування; і переконливу мову захисту стандартів якості в розмовах з менеджерами продуктів і розробниками. Кожен формат має свої власні правила.

Інженери QA також виробляють деякі з найбільш читаних документів в організації продукту. Добре написаний звіт про помилку читають розробник, який його виправив, розробник, який переглянув виправлення, інженер з контролю якості, який перевірив виправлення, і будь- хто, хто пізніше шукає пов’ язані з цим проблеми. Плани тестування посилаються протягом всього циклу випуску. Книги виконання для вручну проведеного тестування регресії використовуються декількома членами команди. Інвестиції в лист явно виплачують дивіденди протягом всього життєвого циклу продукту.

Цей посібник містить ключові реєстри і словниковий запас професійного спілкування з QA англійською мовою. Не важливо, чи пишете ви свій перший звіт про помилку або готуєтеся до інтерв’ ю з QA у міжнародній компанії з технологій, ці розділи допоможуть вам спілкуватися з точністю і професіоналізмом, яких вимагає забезпечення якості.

Розділ 1: Запис звітування про вади

Хороший звіт про помилку — це такий, який розробник може підібрати, негайно зрозуміти і відтворити без запитання подальших питань. Це вимагає певної структури і певного рівня деталізації - не надто нечіткого, не настільки довгого, щоб ключова інформація була захована.

Структура звіту про помилку

Стандартний звіт про помилку містить: Заголовок, Середовище, Кроки для відтворення, Очікуваний результат, Фактичний результат, Серйозність, Пріоритет і Долучення (знімки екрана, журнали, відео). Кожен розділ має свої мовні конвенції.

Заголовок повинен бути коротким, фактичним описом симптому, а не гіпотетичної причини. Погана заголовка: « Не вдалося увійти ». Правильна заголовка: « Форма входу надіслана з порожнім полем електронної пошти — не показано помилки перевірки ». У заголовку слід вказати: що це за компонент, яку дію було виконано, і який був несподіваний результат.

Кроки до відтворення

Кроки для відтворення написані як пронумеровані інструкції в імперативному настрої, з достатньою кількістю деталей, щоб хтось, хто ніколи не використовував функцію, міг точно їх виконати: "1. Перейти до /settings/account. 2. Натисніть « Змінити пароль ». 3. Введіть новий пароль у поле « Новий пароль ». 4. Залиште поле « Підтвердити пароль » порожнім. 5. Натисніть « Зберегти зміни ». Використовуйте імперативи теперішнього часу: « Клацання », « Ввести », « Навігація », « Вибір », « Перевірити ». Не пишіть « Я клацнув » (минулий час) або « Ви повинні клацнути » (інструкція другої особи з « має »).

Очікувана проти. Фактичний результат

Розділи «Очевидний результат» і «Фактичний результат» повинні бути паралельними за структурою — обидва описують один і той же момент часу, але один говорить, що повинно статися, а інший говорить, що відбувається. Написати у теперішньому часі: Очікувалося: « Під полем Підтвердити пароль буде показано повідомлення про помилку « Паролі не збігаються ». » Форму не надсилається.» Actual: « Помилка не показана. Форма успішно надсилається. Пароль буде збережено без перевірки поля підтвердження. « Ця паралельна структура робить розбіжність очевидною на перший погляд.

Екологія та репродуктивність

Вкажіть: назву і версію переглядача, версію і назву операційної системи, версію або номер збірки програми, будь- які відповідні налаштування (тип користувача, яким було здійснено входження до системи, які прапорці можливостей увімкнено). Визначте стан відтворюваності: « Відтворено 5/ 5 разів » або « З перервами — відтворено 3/ 10 разів під час завантаження сторінки ». Якщо ви визначили умови, які впливають на відтворюваність, зауважте їх: « Відбувається лише під час входу до системи як користувач адміністратора, відтворення неможливе за допомогою облікового запису звичайного користувача. »

Розділ 2: Серйозність та пріоритет мови

Серйозність і пріоритет часто плутають, але в професійному QA вони мають різні значення. Серйозність описує технічний вплив вади на систему. Пріоритет описує невідкладність виправлення. Косметичне невідповідність в інтерфейсі користувача має низький ступінь тяжкості, але може мати високий пріоритет, якщо воно відбувається на домашній сторінці великого випуску продукту. Вада, яка призвела до пошкодження даних у інструменті, доступному лише для адміністраторів, може мати високий ступінь важкості, але низький пріоритет, якщо цим інструментом користуються лише п’ ять осіб, і вони мають варіант розв’ язання проблеми.

Рівень важкості

Стандартна шкала тяжкості (більшість команд використовують варіант цієї шкали): Критична — програма зазнає аварії, дані втрачено або пошкоджено, або основний шлях користувача повністю заблоковано без можливості обходу (« Потік платежу викидає помилку 500 — користувачі не можуть завершити покупку. »). Висока — значна функціональність пошкоджена, але існує обхідне рішення або вплив обмежений підмножиною користувачів. Середня — функція поводиться неправильно, але вплив на неї незначний або обмеження є простим. Низька — косметичні проблеми, незначні невідповідності UX або проблеми з незначним впливом на користувача.

Під час присвоєння ступеня тяжкості, обґрунтуйте його: « Серйозність: Критична — це значення стосується всіх користувачів, які намагаються увійти до системи. Немає доступного рішення.» / «Складність: Середня — функція експорту створює неправильно форматований CSV, але користувачі можуть вручну переформатувати вивід.»

Мова оригіналу в оригіналі

На зустрічах з розгляду помилок використовується мова на кшталт: «Давайте пріоритизувати цю — вона на критичному шляху для випуску.» / «Я б стверджував, що це має бути P2, а не P3 — ми бачимо, що це впливає на 15% наших активних користувачів на основі журналів помилок.» / «Чи можемо ми відкласти це до наступного спринту? Це відоме обмеження, а не регресія." / "Це потрібно виправити перед тим, як ми перейдемо на дійсний режим — це порушує наші вимоги до відповідності GDPR." Словник триажу — це словник переговорів — ви закликаєте до позиції, використовуючи докази.

Розділ 3: Тестовий план документації англійською

План тестування — це документ, який описує обсяг, підхід, ресурси і розклад тестування можливості або випуску. Його читають інженери QA, розробники, менеджери продуктів, а іноді й старше керівництво перед основним випуском. Це має бути зрозуміло для всіх цих аудиторій.

Конвенції з тестування планових мов

У планах тестування використовується формальна, мова третьої особи (або пасивний голос у британській конвенції): «Наступний план тестування охоплює модуль автентифікації користувача для випуску 2.4.0.» Розділи обсягу визначають, що входить в обсяг і явно, що виходить за його межі — розділ «за межами обсягу» важливий, тому що він встановлює очікування: «За межами обсягу: тестування продуктивності під навантаженням. Це буде розглянуто в окремій ініціативі тестування продуктивності. Розділи підходу описують методологію тестування: « Ручне дослідне тестування буде використано для виявлення краю випадку. Регресійне тестування буде виконано за допомогою існуючого автоматизованого пакету Cypress

Тестова мова

Індивідуальні тестові випадки в плані тестування або інструменті керування тестуванням мають певну структуру: ІД тестового випадку, Заголовок, Попередні умови, Кроки, Очікуваний результат і стан «Пройшов/Не пройшов». Заголовки використовують формат « Перевірити, що [система] [робить X] за умови [умова] ». Приклади: « Перевірити, чи буде показано повідомлення про помилку у формі реєстрації, якщо буде введено неправильний формат електронної пошти ». / « Перевірити, чи буде скасовано сеанс, якщо користувач вийде з системи ». « Перевірити що » є типовим префіксом — він точніше, ніж « Перевірити що » або « Перевірити що », оскільки він свідчить про те, що ви перевіряєте існуючу специфікацію.

Розділ 4: Критерії прийняття мови

Критерії прийняття визначають, що означає « виконано » для історії користувача. Погано написані критерії прийняття є найпоширенішим джерелом суперечок щодо обсягу, невдалих оглядів спринту і аргументів «це помилка або функція?». Написання чітких, перевіряних критеріїв прийняття є одним з найцінніших навичок, які інженер з контролю якості може внести в гнучку команду.

Формування мовлення

Стандартним форматом критеріїв прийняття є « Вказано- Коли- Тоді » (також відомий як синтаксис Gherkin): Вказано [передумову], Коли [виконується дія], Тоді [виникає очікуваний результат]. Цей формат вимагає можливості перевірки, оскільки кожен критерій має вказувати точно, в якому стані має бути система. Приклад: « Якщо користувач, який зареєстрований за допомогою плану Стандарт, спробує експортувати більше 100 записів, програма покаже повідомлення про помилку « Обмеження експорту досягнуто — перейдіть на план Професіонал, щоб експортувати більше 100 записів », і не почне експортування. » Ключове слово « І » розширює умову « Дано », « Коли » або « Тоді ».

Запис тестових критеріїв

Критерії прийняття мають бути перевіряними — ви повинні мати змогу відповісти на питання « чи пройшов тест або не пройшов? » так або ні. Не перевіряти: « Сторінка має завантажуватися швидко ». Перевіряти: « Сторінка має завантажуватися менше ніж за 3 секунди за з’ єднання 4G для 95% користувачів ». Не перевіряти: « Форма має бути простою у використанні ». Перевірятися: « Форма має показувати вбудовані помилки перевірки для кожного поля, має автоматично фокусувати перше неправильне поле під час спроби надсилання, і не має вимагати перезавантаження сторінки. »

Поширені червоні прапори у критеріях прийняття: « має бути » (суб’ єктивне) потрібно замінити на « має бути »; « тощо » ніколи не приймається — перелічте, що ви маєте на увазі; « і так далі » — та ж проблема; відсотки або кількості без базових ліній — « має обробляти високий трафік » потрібно вказати, що означає « високий ».

Розділ 5: TDD & BDD Vocabulary (англійською)

Розробка з використанням тестів (TDD) і розробка з використанням поведінки (BDD) є методологіями розробки з власним словником, який інженерам QA потрібно розуміти і обговорювати вільно, як при роботі з розробниками, так і при презентації зацікавленим сторонам.

Мова ТДД

TDD слідує за циклом Червоний- Зелений- Перефактор: ви пишете тест, який зазнає невдачі (Червоний), пишете мінімальний код, який дозволить вам пройти тест (Зелений), а потім покращуєте код без зміни його поведінки (Перефактор). Мова: « Я спочатку напишу тест на невдачу для краю, а потім реалізую виправлення ». / « Тести зелені — зараз я переробляю, щоб прибрати реалізацію ». / « Ми отримали 94% покриття тесту — відкриті шляхи є гілками помилок у процесорі платежу ». Типи тестів у TDD: « тест одиниці » (тестує одну функцію або клас у окремому режимі), « тест інтеграції » (тестує, як багато компонентів працюють разом), « тест « від початку до кінця » (тестує повний потік користувача у реальному середовищі).

Мова БДД

BDD розширює формат Given-When-Then в реальний виконуваний тестовий код за допомогою таких фреймворків, як Cucumber, SpecFlow або Jest з конвенціями BDD. Словник: « файл можливостей » (опис можливостей, написаний у Gherkin, який можна прочитати), « визначення кроків » (код, який реалізує кожен крок « Дано/ Коли/ Тоді »), « сценарій » (один випадок тестування у файлі можливостей), « контур сценарію » (параметризований сценарій з декількома наборами даних). « Жива документація » стосується ідеї, що тести BDD слугують як оновлена документація поведінки системи. « Три друзі » — це сеанс співпраці між розробником, відділом контролю якості і власником продукту, у ході якого перед початком реалізації буде узгоджено критерії прийняття.

Розділ 6: Зв'язок з дефектами життєвого циклу

Дефект (або помилка) проходить через життєвий цикл від виявлення до розв'язання, і кожен етап генерує комунікацію між QA, розробниками і менеджерами продукту. Зрозуміти словник кожного стану і переходи між ними є важливим для ефективного керування дефектами в таких інструментах, як Jira, Azure DevOps або Linear.

Дефектний державний словник

Стани стандартного життєвого циклу пошкоджень: Новий (щойно створено, ще не сортовано), Відкритий (підтверджено і призначено), У процесі (розробник активно працює над ним), У перегляді (виправлення було реалізовано, очікується перегляд коду), Виправлено (розробник вважає, що виправлення завершено), У тестуванні (QA перевіряє виправлення), Перевірено (QA підтвердив, що виправлення працює), Закритий (розв’ язано і перевірено), Відновлено (QA виявив, що виправлення не завершено), Відкладено (рішень не виправляти у поточній версії), Не буде виправлено (рішень не виправляти взагалі).

При повторному відкритті дефекту: «Повернення до відкриття — виправлення вирішує повідомлені кроки, але основна проблема зберігається, коли користувач отримує доступ до тієї ж функціональності через API безпосередньо. Нові кроки для відтворення: [кроки].» Під час закриття як Не буде виправлено: « Закриття як Не буде виправлено — поведінка відповідає існуючій системі для застарілої облікового запису. Документовано на сторінці відомих обмежень»

Перевірка та регресія мови

Після того, як розробник позначає ваду як Виправлена, QA перевіряє її: «Перевірено виправлено на збірці 2.3.1 в стадії. Перевірено на відповідність початковим крокам відтворення і трьом додатковим межам — всі пройшли. » Коли виправлення вводить нову проблему: « Виправлення для # 1234 вирішує початкову проблему, але вводить регресію у пов’ язану функціональність пошуку — що призвело до появи нової вади # 1289. » Мова тестування регресії: « Запуск повного набору регресій перед випуском. » / « Цільова регресія потоку виводу — зосередження уваги на областях, змінених у цьому випуску. »

Розділ 7: Автоматизація тестування лексики

Автоматизація тестування є все більш центральною частиною ролі QA, а словник охоплює кілька шарів: піраміду тестування, специфічний фреймворковий словник (Selenium, Cypress, Playwright, Jest), інтеграцію CI і мову підтримки і надійності тестування.

Тестування мови пірамід

Піраміда тестування (одиницю → інтеграцію → повний цикл) є фундаментальною концепцією з певним словником. « Нам слід змінити баланс нашого набору тестів — у нас занадто багато повільних тестів E2E і недостатньо тестів одиниць. Піраміда тестування говорить про протилежне.» / «Ця бізнес-логіка повинна бути покрита на рівні блоку, а не на рівні E2E — блокові тести швидші і менш крихкі.» / «Наш набір тестів має занадто багато крихких тестів end-to-end, які ламаються при незначних змінах інтерфейсу користувача — ми повинні насміхатися з шару API для більшості сценаріїв»

Специфічний словниковий запас

Словник Cypress: « cy. intercept () для викликів API, що затримують », « нетипові команди, » « вилучення тестів, » « beforeEach hook. » Словник Playwright: « модель об’ єкта сторінки, » « фіксації, » « паралельне виконання тестів, » « відстеження. Словник Jest: « насмішка », « шпигунство », « тестування знімків ». Загальний словник автоматизації: « стратегія вибору (як тести знаходять елементи — перевагу надають атрибутам data- testid, а не крихким селекторам CSS), « фрагментарність тестів » (тестування, що іноді зазнають невдачі), « вилучення тестів » (кожен тест встановлює свій власний стан), « налаштування і розбирання » (код, який виконується перед і після тестів).

Комунікація про автоматизацію тестування: «Тест Cypress для потоку оплати є нерівним — він затримується на кроці оплати 20% часу. Мені потрібно додати правильну умову очікування замість використання cy.wait(2000)." / "Я реалізував об'єктну модель сторінки для сторінок автентифікації — це робить тести більш підтримуваними і зменшує дублювання." / "Тестовий набір тепер працює паралельно на 4 робочих місцях — загальний час виконання зменшився з 18 хвилин до 5 хвилин."

Найбільш корисні слова та фрази для інженерів QA

Рекомендований шлях навчання для інженерів QA

1. 1-й

   Вправи з написання звітів про вади

   Найважливіша навичка написання QA. Навчіться писати звіти про вади, які розробники зможуть негайно відтворити без питань про подальші дії.

2. 2-й

   Тестування та вправи лабораторії контролю якості

   Всеосяжний словник QA і вправи зі сценаріями, що охоплюють весь спектр тестування.

3. 3-й

   Вправи з мови TDD & BDD

   Формат Given-When-Then, написання критеріїв прийняття, і словник тест-орієнтованого розвитку.

4. 4-й

   Набір словників для тестування та контролю якості

   Основна термінологія для тестування програмного забезпечення — життєвий цикл дефектів, типи тестів, методики тестування.

5. П'ять

   Документація Типи вправ

   Плани тестування, звіти про тестування та інші формати документації та угоди щодо контролю якості.

6. 6-й

   Словник Agile & Scrum

   Планування спринту, сортування помилок і мова контролю якості в гнучких командах доставки.

7. Сім

   Технічні вправи з письма

   Ширші технічні навички написання документації для QA — плани тестування, runbooks і документація процесу.

8. 8-й

   Інженер-конструктор АТ «Інститут інженерних систем»

   Практика для інтерв'ю QA - питання методології тестування, питання, засновані на сценарії, і обговорення автоматизації.

Вправи для інженерів QA

Вправляйтеся у словниковому запасі і моделях спілкування, які описано у цьому підручнику, за допомогою таких груп вправ: