TG Telegram Group & Channel
Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля | United States America (US)
Create: Update:

⚡️ Доступность в тестовой документации (2)

Формулировки

- В качестве проверочного вопроса можно использовать этот: “Как звучит текст теста?” Да, не все люди имеют ограничения по зрению, но я думаю, что проговаривание текста вслух может помочь увидеть проблемы в формулировках и в общей структуре.

- Все слова несут смысловую нагрузку. Исключаем слова вроде “успешно”, “правильно” и т. п., они не несут никакой полезности.

- Текст максимально простой. Настолько простой, насколько это можно. Из синонимов выбираем самый простой и короткий. Предложения тоже максимально короткие и несложные. Ориентируемся на уровень языка - A1-A2.

- В тексте есть не только шаги и результаты, но и указания, помогающие направить внимание в нужную сторону (если это нужно). Например, если результат теста - что в правом верхнем углу всплывает всплывашка на 5 секунд, хорошо бы, чтобы к моменту появление всплывашки внимание тестировщицы уже было направлено в правый верхний угол.

- Заголовки имеют единую структуру, содержат важные при поиске теста ключевые слова и отражают идею теста. При сортировке по алфавиту тесты, проверяющие одну функциональность, оказываются близко и по заголовкам можно понять, что было протестирование для фичи / функциональной области.

Простой пример:

<Название окна> - <Название параметра> - Ввести значение разными способами
<Название окна> - <Название параметра> - Ввести валидное значение
<Название окна> - <Название параметра> - Ввести невалидное значение
<Название окна> - <Название параметра> - Сохранить
<Название окна> - <Название параметра> - Значение по умолчанию
И т. д.

Форматирование

- Минимум форматирования. Я сама использую только два формата (помимо просто текста): выделение заголовков и выделение фрагментов “кода” (SQL запросы, логи и т.п.).

- Заголовки разделов выделены через форматирование заголовков, а не жирным шрифтом. Если заголовки имеют иерархию - это отражено в форматировании (заголовок 1, заголовок 2 и т. п.)

- Форматирование часто затрудняет читаемость, а не улучшает его. Например, моноширинные шрифты, курсив, декоративные шрифты (менее актуально для нас, но все же), CAPS LOCK, подчеркивание.

- Списки сделаны через форматирование (нумерованный / ненумерованный список), а не проставлением дефисов или тире.

- Для всех картинок прописан альтернативный текст.

- Текст линков содержательный (не просто “вот линк”).

Другое

- Как документ воспринимается, когда масштаб увеличен до 200%?

- Есть инструменты по проверке читаемости. Я не уверена, что их использование может дать релевантный результат в случае тест-кейсов или других рабочих текстов, но можно попробовать. Сама пока что не проверяла.

Если вдруг у вас будут еще идеи - набрасывайте! Запишу их в свой списочек.

#подпольный_евангелизм

⚡️ Доступность в тестовой документации (2)

Формулировки

- В качестве проверочного вопроса можно использовать этот: “Как звучит текст теста?” Да, не все люди имеют ограничения по зрению, но я думаю, что проговаривание текста вслух может помочь увидеть проблемы в формулировках и в общей структуре.

- Все слова несут смысловую нагрузку. Исключаем слова вроде “успешно”, “правильно” и т. п., они не несут никакой полезности.

- Текст максимально простой. Настолько простой, насколько это можно. Из синонимов выбираем самый простой и короткий. Предложения тоже максимально короткие и несложные. Ориентируемся на уровень языка - A1-A2.

- В тексте есть не только шаги и результаты, но и указания, помогающие направить внимание в нужную сторону (если это нужно). Например, если результат теста - что в правом верхнем углу всплывает всплывашка на 5 секунд, хорошо бы, чтобы к моменту появление всплывашки внимание тестировщицы уже было направлено в правый верхний угол.

- Заголовки имеют единую структуру, содержат важные при поиске теста ключевые слова и отражают идею теста. При сортировке по алфавиту тесты, проверяющие одну функциональность, оказываются близко и по заголовкам можно понять, что было протестирование для фичи / функциональной области.

Простой пример:

<Название окна> - <Название параметра> - Ввести значение разными способами
<Название окна> - <Название параметра> - Ввести валидное значение
<Название окна> - <Название параметра> - Ввести невалидное значение
<Название окна> - <Название параметра> - Сохранить
<Название окна> - <Название параметра> - Значение по умолчанию
И т. д.

Форматирование

- Минимум форматирования. Я сама использую только два формата (помимо просто текста): выделение заголовков и выделение фрагментов “кода” (SQL запросы, логи и т.п.).

- Заголовки разделов выделены через форматирование заголовков, а не жирным шрифтом. Если заголовки имеют иерархию - это отражено в форматировании (заголовок 1, заголовок 2 и т. п.)

- Форматирование часто затрудняет читаемость, а не улучшает его. Например, моноширинные шрифты, курсив, декоративные шрифты (менее актуально для нас, но все же), CAPS LOCK, подчеркивание.

- Списки сделаны через форматирование (нумерованный / ненумерованный список), а не проставлением дефисов или тире.

- Для всех картинок прописан альтернативный текст.

- Текст линков содержательный (не просто “вот линк”).

Другое

- Как документ воспринимается, когда масштаб увеличен до 200%?

- Есть инструменты по проверке читаемости. Я не уверена, что их использование может дать релевантный результат в случае тест-кейсов или других рабочих текстов, но можно попробовать. Сама пока что не проверяла.

Если вдруг у вас будут еще идеи - набрасывайте! Запишу их в свой списочек.

#подпольный_евангелизм
Please open Telegram to view this post
VIEW IN TELEGRAM


>>Click here to continue<<

Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля




Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)