Short QA ideas

2022-06-06 11:45:39 #тест_дизайн #стратегия_тестирования
Что стоит (и нет) указывать в комментарии к задаче?

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

Итак, что стоит/не стоит писать в комментах к задачам по итогам выполненного тестирования:

1) если есть TMS и там есть пройденный тест-ран, то прикладываем ссылку на него. Если есть только кейсы/сьюты, то ссылку на них. Важно: ссылка должна быть постоянной, а источник долговечным.

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

3) тестовые данные: если есть тестовые данные, на которых проверялась задача (кейсы/скрипты/запросы), то их тоже лучше приложить (так будет проще пройти аналогичные шаги тому, кто придёт читать коммент)

4) крайне не рекомендую писать что-то вроде "протестировано в соответствии с требованиями", это ничего не говорит о проведённом тестировании.

5) если есть примеры комментариев коллег, то лучше с ними ознакомиться, и/или спросить у лида (местного мудреца), как принято/ожидается

6) когда задача в проде, хорошо бы писать об этом в коммент что-то вроде "проверено на проде" и, например, прикладывать тестовый аккаунт, на котором проведены проверки, и/или скрин новой кнопки/ссылки.

Зачем это всё делать?
Когда что-то (всё) сломается, будет трудно вспомнить, проверялось ли это, на каком кейсе, с какими данными. Если в комменте это будет описано, будет легче сориентироваться.
Кроме того, рано или поздно фичу захотят переделать/доделать/выпилить, а может по ней понадобится провести регресс, и тогда можно будет взять старые проверки/данные и доработать их, а не писать с нуля.

Как ускорить данный процесс?
Можно записывать проверки/данные/скрипты в комментарий по ходу выполнения тестирования.
А можно завести шаблон и дополнять его лишь специфичными для данной задачи фрагментами. Открыть/Комментировать

2022-05-31 09:58:24 #python #почитать
Python: автоматизация тестов REST API (перевод Ольги Алифановой статей Bas Dijkstra)
или: Почему мне никто раньше не сказал, что это так просто?!

Если пропустили (как я), то вот тут совершенно прекрасный цикл переводов статей по теме автоматизации проверок API с python+requests+pytest:
* Создание тестов для REST API на Python с использованием запросов. Часть 1: базовые тесты
* Создание тестов для REST API на Python с использованием запросов. Часть 2: тесты, управляемые через данные
* Создание тестов для REST API на Python с использованием запросов. Часть 3: работа с XML
* Создание тестов для REST API на Python с использованием запросов. Часть 4: имитация ответов

Если хочется на англ и побольше, то вот тут есть блог автора оригинальных статей (спойлер: он автоматизирует не только на Python).

Поскольку меня в этой жизни только Python и интересует (нет), я нашла для себя интересными:
* Writing tests for GraphQL APIs in Python using requests
* TDDing my way to a Python singleton implementation Открыть/Комментировать

2022-05-30 10:12:54 #почитать #англ
The Ultimate QA testing Handbook

Global App Testing за подписку на их рассылку высылает The Ultimate QA testing Handbook (подписаться можно по ссылке).
Относительно полноты данного труда есть сомнения, но в нём точно можно почитать про разные позиции по актуальным вопросам (в частности, по автоматизации регресса, тестированию в условиях agile, краудтестингу). Открыть/Комментировать

2022-05-19 12:17:38 #почитать #полезное
Очередная подборка "про собесы"
(очень коротко, но полезно)

* статья про подходы к решению задач на собесе. В миллионе видосов нам рассказывают как тестировать карандаш, в отличие от них в статье описан универсальный подход (причём довольно подробно)
* выпуски подкаста Вроде в проде про подготовку к собесам для manual QA и QA auto (Java). Тут про: что могут спросить и что можно ответить Открыть/Комментировать

2022-05-18 10:13:33 #json #инструменты
JSONHero: мультитул для джейсона

Инструменты для работы с json-ами становятся всё удобнее. Вот, например, JSONHero.

Помимо крайне приятного интерфейса, у него есть:
* возможность загрузить json в формате файла, json url или обычный raw
* если у вас нет своего json-а, предлагаются примеры апишек
* если в значении в json-e есть картинка/гифка/код цвета и тд, то их можно посмотреть тут же (без перехода по урлу)
* удобный поиск по json-у
* возможность шарить страницу с вашим json-ом
* конечно, dark mode
* плагин для VS Code
* всё это добро open source, так что форкайтесь, сколько вашей душе угодно Открыть/Комментировать

2022-05-12 10:01:12 #инструменты #burp_suite
Burp Suite

Почему-то мы ещё не говорили про Burp Suite, а стоило бы.

В основном Burp Suite используется для security/penetration testing, но в то же время это proxy с разнообразными доп.функциями.

Дисклеймер: используйте Burp Suite только на тех доменах, на которых это разрешено. В остальных случаях это может быть незаконно.

Помимо платных версий, есть Community Edition, в которой имеется весь основной функционал.

Основные фичи Burp Suite:
* proxy (позволяет перехватывать, просматривать и изменять запросы/ответы)
* repeater (позволяет повторно отправлять запросы с разными наборами данных)
* intruder (позволяет автоматизировать кастомизированные атаки веб-приложений)

Полный список фич здесь. Среди них также:
* DOM Invader - This is a tool for finding DOM XSS vulnerabilities.
* Clickbandit - This is a tool for generating Clickjacking attacks.
* Mobile Assistant - This is a tool to facilitate testing of mobile apps with Burp Suite.
* Comparer - This is a handy utility for performing a visual "diff" between any two items of data, such as pairs of similar HTTP messages.

Несмотря на то, что звучит сложновато, если вы разобрались с Charles или аналогами, то с Burp Suite сложностей тоже не возникнет.

Чтобы быстро и качественно освоить Burp Suite, вот тут (это QA Crew #6) можно добыть запись Воркшопа "Чем полезен Burp Suite для тестировщика"/Анна Васильева (Ati.su).

Также вот статьи по теме:
* Burp Suite: Webpage Enumeration and Vulnerability Testing
* Тестирование на проникновение с помощью Burp Suite

Однако можно обойтись и официальной документацией - она подробная и актуальная.

Не менее крутое: есть абсолютно бесплатная Web Security Academy от создателей Burp Suite. По результатам можно получить сертификат. Открыть/Комментировать

2022-05-11 09:09:56 #devtools #инструменты
DevTools update (Chrome 101)

А вот и свеженький апдейт Девтулзов!
Что нового:
* активно развивают Recorder: появилась возможность экспортировать и импортировать пользовательские флоу в формате json
* экспериментальное: 2 новых режима в Lighthouse: timespan (анализирует страницу на отрезке времени, как правило, включающем взаимодействие пользователя с ней) и snapshot (анализирует страницу после взаимодействия с ней в текущем состоянии).
Подробное описание всех трёх режимов (с плюсами, ограничениями и кейсами) можно найти здесь. Сейчас основным режимом является Navigation (анализирует загрузку страницы).

Прим. Не забудьте, что экспериментальные функции включаются отдельно - в Настройках DevTools - далее Эксперименты.

Прим2. У DevTools есть демо страница. На ней можно, например, сгенерить отчёты в новых режимах Lighthouse. Также её используют для теста Recorder.

Подробнее об этих и остальных улучшениях DevTools тут. Открыть/Комментировать

2022-05-04 10:37:53 #тест_дизайн
Полезное из Contributors Guide to Writing a Good Bug и Bug Writing Guidelines (by Mozilla)

Уже писала тут, что Mozilla предлагает репортить баги, найденные в их продуктах.
Для этой цели у них есть Contributors Guide to Writing a Good Bug и Bug Writing Guidelines.
Многие из советов пригодятся и начинающим тестировщикам, и участвующим в бета-тестах, и тем, кто просто хочет отточить скилл написания баг-репортов.

Ниже привожу то, что мне показалось полезным (перевод вольный, с моими дополнениями).

1. Перед тем, как репортить баг, убедитесь, что он воспроизводится больше чем на одном устройстве с той же операционной системой, а также в новом профиле и в безопасном режиме (это не инкогнито, это режим, в котором отключены расширения и настройки)

2. При описании бага также стоит обратить внимание на:
* версию браузера,
* установленные расширения,
* воспроизводится ли баг повторно по описанным шагам,
* есть ли флоу для обхода проблемы
* работает ли функционал как запланировано (видимо, намекают на возможную проблему в бизнес-логике)

3. Настоятельно советуют: для каждого бага открываем отдельный баг-репорт

4. Если баг воспроизводится нестабильно, стоит это указать (тут понадобятся все известные детали того, как его воспроизвести)

5. Перепроверьте, актуальная ли у вас версия приложения (может баг уже пофиксили)

6. Summary (оно же заголовок/краткое описание):
* около 10 слов,
* должно быть коротким и отличать этот баг от остальных,
* должно описывать проблему, а не предлагаемое решение

7. Шаги воспроизведения - самая главная часть баг-репорта.
Важно указывать, каким конкретно способом вы взаимодействовали с приложением (например: не "открыть gmail в отдельном окне", а "кликнуть на такую-то иконку, зажать такие-то hot keys, вставить в адресную строку ссылку https://mail.google.com/")

8. В ожидаемом/фактическом результатах описываем наблюдения (открыто то-то, отображена такая-то ошибка), а не суждения типа "работает некорректно"/"не работает"

9. В зависимости от типа бага вероятнее всего потребуется предоставить доп.детали. Например, для проблем с использованием памяти в Firefox можно сгенерить репорт на вкладке about:memory. Там же (For specific types of bugs) есть советы на случай зависаний, чрезмерного использования CPU и проч.

10. Крайне желательно указать наиболее раннюю из версий, в которой воспроизводится баг.

11. Предлагается следующая структура репорта:
1) Summary (краткое описание/заголовок)
2) Component (часть приложения, в которой обнаружена проблема)
3) Version (наиболее ранняя из версий с багом)
4) Operating system
5) Description (в котором: overview, build id, additional builds and platforms)
6) Steps to reproduce
7) Actual results
8) Expected results

Там же рекомендуют статью Как эффективно сообщать об ошибках от Simon Tatham, в которой есть занятные примеры. Открыть/Комментировать

2022-04-29 15:55:03 #полезное
Видеокурс по тестированию

Снова принесла вам кое-что полезное! Анастасия Заречнева из Semrush, Максим Заречнев из ВКонтакте и Farida Rizaeva из ARRIVAL.robotics записали наикрутейший курс по тестированию и выложили его на Stepik БЕСПЛАТНО.
Курс только появился, поэтому отзывов ещё мало, но темы и подача точно хороши.

В курсе есть про:
* тестирование требований,
* тест-дизайн,
* особенности тестирования разных платформ,
* клиент-серверное взаимодействие
* и многое другое.
Помимо базовых тем, там есть ещё и про инструменты тестировщика (в том числе командную строку, Jmeter, Docker/ VM).

Есть и практическая часть - то есть вам не только расскажут, но и покажут куда тыкать и зачем.
Enjoy. А авторам спасибо Открыть/Комментировать

2022-04-27 09:42:14 #почитать #git #python
Smartiqa: уроки по git, полезные статьи, задачник и курс по python

Совершенно случайно обнаружился отличный источник инфы! Вот.

Что тут есть?
1. Курс по гиту (бесплатно, подробно, на русском, с заданиями и ответами, и я честно сюда подсматриваю, когда сомневаюсь в командах)
2. Курс по python (начальный уровень, тоже бесплатно)
3. Сборник задач по python с решениями
4. Блог с круто проработанными статьями. Как минимум есть такое:
* Собеседование на должность QA Automation Engineer. Вопросы и ответы (чтобы освежить знания и подсветить пробелы - самое то)
* Библиотека Requests: эффективные и простые HTTP-запросы в Python
* Тестирование производительности веб-приложений: 18 бесплатных инструментов

Материалы проекта Smartiqa были и остаются бесплатными, но им можно донатить. Открыть/Комментировать