📚 ProTestingInfo 🔷 Канал по тестированию 📚

📚 ProTestingInfo 🔷 Канал по тестированию 📚 pinned «У меня тоже есть план набрать 11111 подписчиков и снова сделаю подарок-розыгрыш.😁»

У меня тоже есть план набрать 11111 подписчиков и снова сделаю подарок-розыгрыш.😁

Мини - план на испытательном сроке🤣 выше читаем)

📚 ProTestingInfo 🔷 Канал по тестированию 📚 pinned «Коллеги, буду благодарна вашим голосам для сторис - напоминаний на полезный контент: https://t.me/boost/protestinginfo»

Всем привет!
Статья требует вашего прочтения 😄

Читать:

Сложно о простом. Модель OSI и TCP/IP

На собесе порой спрашивают про TCP/IP.

А также и это рекомендую почитать схема-шаблон правильного ответа, взято из видео

Сохранено на @protestinginfo

В дискуссиях на тему soft skills периодически упоминают умение просить помощи у коллег.

В случае сложностей возникает дилемма, как быть? Бежать за помощью немедленно? Пробовать решить проблему самому?

Если бежать за помощью немедленно:
- высокая вероятность быстро получить помощь и устранить проблему. Высокая потому что нет 100% гарантии, что у коллеги уже есть готовое решение. Иногда приходится обращаться к нескольким. Как правило проблема будет решена.
- НО: этот подход имеет и свои недостатки
- приходится отрывать коллег от работы
- не нулевая вероятность того, что никто не сможет помочь и проблему придется в итоге решать самому
- отсутствие образовательного эффекта, так как в целях экономии собственного времени коллеги не объясняют детали, а дают готовое решение

Если пытаться найти решение самому:
- с помощью документации, google, ChatGPT и тд можно найти решение самому не отвлекая коллег
- образовательный эффект за счет глубокого погружения а проблему, нахождения вариантов решения, проб и ошибок
- НО: и здесь есть недостатки
- нет гарантии, что проблему удастся решить самому и и в итоге все равно придется обращаться к коллегам
- есть риск зарыться и потратить непозволительно большое время на поиск решения. То, на что с помощью коллеги ушло бы минут десять, при самостоятельном решении может занять час-полтора и больше в зависимости от проблемы

А еще есть крутая шпаргалка, которую мне прислала коллега! 😏

Сохраняем, пользуемся и делимся с другими!
С вас реакция ❤️

Заметки тестировщика

Разбор вопросов из нельзяграма (подписаться на аккаунт Protestinginfo)

Подписчице задали такой вопрос на
Локализацию бага:
⁉️Тестировщик в Postman через post создаёт пользователя (email и пароль), а ему приходит 200 статус код и пустой json.

А точно ли это баг?
Я считаю, что это нормальное поведение, если под пустым json понимается, что нет тела ответа от сервера. На скрине отображено нормальное поведение, и все же хотелось бы, чтоб был 201 статус код, например, документация без тела ответа от сервера "Code - 201; Description - User has been registered and expects confirmation by e-mail"

Но если будет действительно пустое тело ответа от сервера как {} или ключи имеют значения null, то по сути это дефект, и здесь нужно провести локализацию бага.
Смотрим документацию и проверяем значения в таблице БД.

Помните ваша задача на собесе рассуждать, задавать вопросы интервьюеру.

Сперва я укажу ответы подписчиков:

▪️- Самый главный ответ, что дефект на бэкенде.
▪️- Обычно при создании пользователя приходит статус код 201.
▪️- Пустой json - это некорректный ответ от сервера.

Я скажу так, что эти ответы не относятся к локализации бага.

Было два ответа, относящиеся к локализации бага, и то, что как по мне понравится услышать интервьюеру.

- проверить данные в базе данных;
- проверить эндпойнт на корректность.

На помощь к ответу пришел Женя (канал Про Мир ИТ) и прочитайте его рассуждения.

У меня возникает два вопроса:
1. Какое апи?
2. Возвращается именно пустой json? Не пустой body, а именно json?

Если именно пустой json то вероятно да дефект.
Если просто пустое бади, то не факт.
Если это банальный REST то там жестких правил нету. Можно сделать POST запрос, где будет 200 статус код и пустое тело в ответе. И ничего криминального в этом не будет.

Я бы в первую очередь обратился к документации. Чтобы понять - а как должно быть? Прелесть апи в том, что по-любому документация есть. Даже если нет её в привычном понимании - есть реализованный код, в котором запрограммировано поведение, там указано и какой код ответа должен возвращаться и что должно возвращаться в теле ответа.

Если следовать мысли бест-практикс реализации restful, то здесь логичней 201 статус код и в теле ответа информация о созданном пользователе.

Статус код 201 в коде прописывается тут локализовать нечего.

Пустой json: идем в БД проверить, что запись создалась корректно. Если БД допускает null значения, то запись могла создаться с пустыми значениями. Если запись есть, но поля пустые - идем в логи и смотрим, что произошло в момент записи в БД.
Если запись корректна - то идём в логи смотреть что произошло когда апи "забирал" данные из БД.

🔷Запомните, что локализация бага - это процесс, направленный на анализ проблемы, которая возникает в приложении, на сервере, при интеграции двух сервисов и т.д..
🔺Наша задача выяснить причину возникновения данной проблемы.

Основные действия по локализации:
🔹- еще раз посмотреть имеющиеся требования на проекте;
🔹- в данном задании используется Postman, тогда просмотреть логи в console Postman;
🔵- проверить интеграцию с БД, просмотреть созданную запись пользователя в БД, и по-моему мнению, что была проблема в БД, вероятно, несоответствие типов данных или размера или длины значений данных;
🔹- присмотреть логи на сервере, или в других имеющихся инструментах по сбору логов на сетевые ошибки, недоступность или некорректная конфигурация систем;
🔹- также не исключаем: уточнить информацию на обновления кода в системе у разработчика / на обновления требований у аналитика - взаимодействовать с командой;
🔹- возможно, что здесь есть интеграция с другим сервисом и посмотреть доступность другого внешнего сервиса.

Работая инженером по тестированию важно научиться предугадывать ошибки, уметь читать и анализировать логи, тем самым навык локализации багов возрастет.

А также этот вопрос на проверку, вероятно, это не дефект, а вы начнете «копать» не в ту сторону 😁.
Добавляйте свои рассуждения.
А разбор вопросов буду продолжать.
@protestinginfo
и жду ваши реакции❤️✍️🔥, реакции еще больше мотивируют делиться с полезной информацией🥰

Для ознакомления:
Прочесть Детективную историю - Старый баг в MySQL.
От автора тренажера по SQL

https://sqltest.online/ru/

+ сама шпаргалка

Размещено на канале: @protestinginfo

Порой моим менти задают вопрос на собесе:
Назовите принципы REST (или ограничения для построения распределённых REST-приложений по Филдингу.)

Ответ:
Есть шесть принципов, на которых строится REST:
- клиент-серверная модель,
- отсутствие состояния,
- кэширование,
- единообразие интерфейса,
- многоуровневая система,
- код по требованию.

Так вот, перечислить, то легко, а вот пояснить сложно. А в Википедии заумно написано, что многим также сложно понять (см. пункт “Требования к архитектуре REST”).

Хочу порекомендовать просмотреть это
ВИДЕО, где четко и понятно рассказаны принципы REST автором канала Свят404.

01:08 - Client-Server
01:30 - Stateless
02:10 - Cache
02:33 - Uniform Interface
02:55 - Identification of resources
03:27 - Manipulation of resources through representations
03:54 - Self-descriptive messages
04:37 - Hypermedia as the engine of application state
05:24 - Layered System
06:20 - Code on Demand

+ посмотрите видео про клиент-сервер архитектуру простыми словами.

@protestinginfo

Коллеги, буду благодарна вашим голосам для сторис - напоминаний на полезный контент:

https://t.me/boost/protestinginfo

Всем привет!
Хочу порекомендовать прочитать статью на хабре, которая мне понравилась:

Методы тестирования веб-API, которые должен знать каждый: чек-листы для начинающих

Здесь вы ознакомитесь с:
- Разделением тестирования: фронтенд vs бэкенд;
- Спецификой тестирования API;
- Типами тестирования;
- Позитивными и негативными тестами;
- Тестированием API на производительность;
- Тестированием сценариев.


А также хочу напомнить про свою статью:
💙Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности
и посмотреть видео
Стратегия написания тест-кейсов по API

Локализация бага:

Задача на локализацию бага: к примеру пользователь вводит почту, а экран белый? Как быть, твои действия

ИЛИ

При открытии сайта отображен белый экран - ваши действия?

Я напишу свои рассуждения, а вы дополняйте.

Хочу предложить варианты решения на данный вопрос про локализацию бага:
Первым делом!
🐞- очистить кэш и куки
А потом уже другие варианты🐞:
🐞- перейти на страницу chrome://settings/system и выключить аппаратное ускорение.
🐞- установить необходимые сертификаты для работы
🐞- уточнить у разработчиков на изменение хостов или обратиться к разработке на изменение кода или эндпойнтов
🐞- проанализировать логи в console DevTools
🐞- просмотреть сетевые запросы в network Devtools
🐞- проверить интеграцию с БД
🐞- открыть «Просмотр кода страницы» и запустить любой .js файл, и затем обновить тестируемую страницу
🐞- просмотреть логи сервера
🐞- просмотреть логи проекта / пода в консоли опеншифта
🐞- проанализировать логи в кибане, sentry, graylog, grafana, если есть эти инструменты на проекте
🐞- коммуницировать с командой на наличие возможного обновления требований

Не заводите сразу дефект, постарайтесь разобраться, изучить логи, проверить интеграцию с БД или данные в таблицах БД, или интеграцию с другим сервисом, куда может сохраниться адрес электронной почты.

Главное помните, что на собесах ждут ваших рассуждений, а не точного верного ответа.
Главное не молчать, а генерировать идеи!

Разбор вопросов будет продолжаться на @protestinginfo

Такой вопрос я задавала в рефлексии на курсе по тестам, который стартанет в июле.

#собеседование

Расскажите правильный порядок следующих видов тестирования после раскатки сборки на стенд с новыми фичами и минорными дефектами.

К видам тестирования связанными изменениями относятся:
- Смоук-тестирование
- Регрессионное тестирование
- Ре-тест (повторное или подтверждающее тестирование)
- Санитарное тестирование
- Тестирование новой функциональности
А также тестирование сборки.

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

Такой мой ответ для собеса.
А какой ответ будет у вас?

#собеседование

Разбор вопросов и тестовых заданий … to continue…😀

Немножко про Firebase

Firebase – это платформа для разработки мобильных и веб-приложений от Google.
Firebase – предоставляет бэкенд-услуги, такие как аутентификация, база данных в реальном времени, хостинг, аналитика и etc.

Через Firebase можно просматривать различные данные:

☘️ Обновление баз данных в реальном времени (Firestore и Realtime Database)

☘️ Данные об аутентификации пользователей

☘️ Аналитические данные о поведении пользователей (Firebase Analytics)

☘️ Логи производительности и ошибок (Crashlytics)

☘️ Конфигурационные данные (Remote Config)

Я работаю с Firebase в контексте мобильной разработки. И чаще всего пользуюсь следующими инструментами:

🌿 Crashlytics: помогает удобно просматривать краши как во время тестирования, так и после релиза

🌿 Performance Monitoring: для анализа производительности приложения

🌿 Firebase Analytics: для тестирования событий аналитики

Плюсы и минусы Firebase:
Плюсы:
🌵 Легкость интеграции: Простота интеграции и быстрота развертывания

🌵 Масштабируемость: Поддержка масштабирования приложений с ростом числа пользователей

🌵 Реальное время: Мгновенное обновление данных в приложении благодаря базе данных в реальном времени

🌵 Широкий функционал: Множество инструментов для аналитики, аутентификации, хостинга и других задач.

Минусы:
🌵 Зависимость от Google: Потенциальная зависимость от экосистемы Google и изменений в их политике (особенно актуально для компаний из РФ)

🌵Стоимость: Бесплатный тариф ограничен, и при росте приложения стоимость услуг может значительно увеличиться

🌵Ограниченные возможности запросов: В некоторых случаях сложные запросы к базе данных могут быть ограничены по функционалу и скорости

Конечно же, на любое ПО есть разные аналоги, Firebase не исключение:

🪴 AWS Amplify: Платформа от Amazon, предоставляющая инструменты для создания и хостинга мобильных и веб-приложений

🪴 Microsoft Azure: Облачная платформа, предлагающая множество сервисов для разработки и развертывания приложений

🪴 Backendless: Бэкенд-платформа, предлагающая широкий спектр услуг, таких как базы данных, файловое хранилище и пользовательское управление

🪴 Parse: Открытый исходный код бэкенда для мобильных приложений, который можно хостить самостоятельно.

Надеюсь, данная заметка будет полезна хотя бы в контексте ознакомления с новыми инструментами)

Всем привет, кто еще не проходил тест «Web Testing», предлагаю повторить свои знания
(Не забыть почистить историю бота для того, чтобы ответить на тест)

t.me/QuizBot?start=Pg4wqbjK

Напоминаю про вебинар, связанный с разбором вопросов и общие тесты на платформе CoreApp:

https://coreapp.ai/app/player/lesson/672607b1de85a3e17dcf2169

3 июня я начинаю обучение на курсе
Автоматизация тестирования REST API (Advanced)
PYTHON
у Валеры Меньшикова, где можно узнать еще больше нового и закрепить свои знания по автоматизации тестирования REST API.
Валера Меньшиков - Lead Automation QA Engineer в OZONTECH.
Сейчас он занимается разработкой инструментов автоматизации, back-end сервисов для подготовки тестовых данных и авто-тестов на Python.
Я уже прошла два курса у него, поэтому рекомендую его курсы.
А сейчас выходит новый курс более расширенный с выгодной ценой (программа по ссылке выше).