📚 ProTestingInfo 🔷 Канал по тестированию 📚 – Telegram
📚 ProTestingInfo 🔷 Канал по тестированию 📚
14.1K subscribers
1.31K photos
200 videos
232 files
1.18K links
📌Информация для начинающих и для коллег в области QA, для личного закрепления знаний.
📌Теория, тесты, практика
Ментор-Консультация - 5тр/час
Курс
@info_course_protestinginfo
https://protestinginfo.ru
Вопросы @nadin_qa
ИП
РКН: https://clck.ru/3FWD9v
Download Telegram
REST.pdf
8.1 MB
+ сама шпаргалка

Размещено на канале: @protestinginfo
🔥29🤝6👍1👏1
Разбор вопросов из нельзяграма (подписаться на аккаунт Protestinginfo)

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

А точно ли это баг?
Я считаю, что это нормальное поведение, если под пустым json понимается, что нет тела ответа от сервера. На скрине отображено нормальное поведение, и все же хотелось бы, чтоб был 201 статус код, например, документация без тела ответа от сервера "Code - 201; Denoscription - 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
и жду ваши реакции❤️✍️🔥, реакции еще больше мотивируют делиться с полезной информацией🥰
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥48👍146🔥6🆒2
SQL.pdf
247.6 KB
А еще есть крутая шпаргалка, которую мне прислала коллега! 😏

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

Заметки тестировщика
🔥61❤‍🔥19👍91
В дискуссиях на тему soft skills периодически упоминают умение просить помощи у коллег.

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

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

Если пытаться найти решение самому:
- с помощью документации, google, ChatGPT и тд можно найти решение самому не отвлекая коллег
- образовательный эффект за счет глубокого погружения а проблему, нахождения вариантов решения, проб и ошибок
- НО: и здесь есть недостатки
- нет гарантии, что проблему удастся решить самому и и в итоге все равно придется обращаться к коллегам
- есть риск зарыться и потратить непозволительно большое время на поиск решения. То, на что с помощью коллеги ушло бы минут десять, при самостоятельном решении может занять час-полтора и больше в зависимости от проблемы
👍13🔥53🍌1
Как_задать_вопрос.pdf
721.1 KB
А также и это рекомендую почитать схема-шаблон правильного ответа, взято из видео

Сохранено на @protestinginfo
🔥219👨‍💻2👍1
Всем привет!
Статья требует вашего прочтения 😄

Читать:

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

На собесе порой спрашивают про TCP/IP.
🔥17👍73🤝21
📚 ProTestingInfo 🔷 Канал по тестированию 📚 pinned «Коллеги, буду благодарна вашим голосам для сторис - напоминаний на полезный контент: https://news.1rj.ru/str/boost/protestinginfo»
У меня тоже есть план набрать 11111 подписчиков и снова сделаю подарок-розыгрыш.😁
🆒15👀7👍53💯1
📚 ProTestingInfo 🔷 Канал по тестированию 📚 pinned «У меня тоже есть план набрать 11111 подписчиков и снова сделаю подарок-розыгрыш.😁»
​​Вопросы, которые любят задавать на собеседовании не только на роль BA/SA, но и на роль QA Engineer.
Сохраняйте полезный пост 😎 и необходимые ссылки.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👌31👨‍💻1
​​Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и продолжим тему про работу с базами данных и поговорим именно об SQL:

#вопросыссобеседования

Часть 7:

Данную тему очень часто затрагивают на собеседованиях и спрашивают как теорию, так и просят что-либо показать на практике, поэтому нашла пару статей👇🏼, где уже отмечены вопросы с ответами по теме sql:
📌 27 распространённых вопросов по SQL с собеседований и ответы на них
📌 Топ-30 вопросов по SQL на технических собеседованиях:
- Часть 1
- Часть 2
📌 20 вопросов и задач по SQL на собеседовании с ответами
📌 50 популярных вопросов и ответов на собеседовании по SQL Server

Также исходя из опыта и прочитав разные статьи выделю несколько вопросов, которые практически всегда задают на собеседовании:

📍Вопрос 1: Какие есть операторы SQL

Краткий ответ:
DDL (Data Definition Language, язык описания данных) - это группа операторов определения данных, в нее входят такие операторы как:
- CREATE
- ALTER
- DROP
DML (Data Manipulation Language, язык управления данными) - это группа операторов для манипуляции данными, в нее входят такие операторы как:
- SELECT
- INSERT
- UPDATE
- DELETE
DCL (Data Control Language, язык контролирования данных) - группа операторов определения доступа к данным, в нее входят такие операторы как:
- GRANT
- REVOKE
- DENY
TCL (Transaction Control Language, язык управления транзакциями) - группа операторов для управления транзакциями, в которую входят такие операторы как:
- BEGIN TRANSACTION
- COMMIT TRANSACTION
- ROLLBACK TRANSACTION
- SAVE TRANSACTION

📎Материалы по теме:
- Основные команды SQL, которые должен знать каждый программист

📍Вопрос 2: Какие есть типы соединения в SQL

Краткий ответ:
Для соединения двух таблиц используют оператор JOIN. Соединение может быть внутренним (INNER), внешним (OUTER), которое в свою очередь может быть левым (LEFT), правым (RIGHT) и полным (FULL).

Рассмотрим чуть подробней каждое из них:
- INNER JOIN - объединяет записи из двух таблиц по связующему полю, если оно содержит одинаковые значения в обеих таблицах
- FULL OUTER JOIN - возвращает все записи, для которых есть совпадение в любой из таблиц. Следовательно, он возвращает все строки из левой таблицы и все строки из правой таблицы
- LEFT JOIN - используется для возврата всех строк из левой (первой) таблицы и только совпадающих строк из правой (второй) таблицы, для которых выполняется условие соединения
- RIGHT JOIN - используется для возврата всех строк из правой (второй) таблицы и только совпадающих строк из левой (первой) таблицы, для которых выполняется условие соединения

📎Материалы по теме:
- Соединение таблиц – операция JOIN и ее виды
- SQL JOIN - соединение таблиц базы данных

📍Вопрос 3: Что такое SQL-ограничения (Constraints) и какие они бывают?

Краткий ответ:
Ограничения (constraints) используются для указания ограничения на тип данных таблицы. Они могут быть указаны при создании или изменении таблицы

Примеры ограничений:
- NOT NULL - значение не может быть NULL
- CHECK - значения столбца должны соответствовать заданным условиям
- DEFAULT - предоставляет столбцу значения по умолчанию
- UNIQUE - гарантирует уникальность значений в столбце
- INDEX — создаёт индексы в таблице для быстрого поиска/запросов
- PRIMARY KEY - требует, чтобы каждая запись в данном столбце была уникальной и не равнялась NULL
- FOREIGN KEY - требует, чтобы каждая запись в данном столбце уже существовала в определенном столбце из другой таблицы

📎Материалы по теме:
- SQL Создание ограничений
- Основы работы с ограничениями SQL

Источник: @ba_and_sa
#собеседование

‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования

p.s.Делитесь своими мыслями в комментариях и напишите, какие вопросы были у вас на собесах
👍14💯72👨‍💻2🆒2
Forwarded from Надежда Дудник
Закрепление знаний по SQL😄

Оператор UPDATE относится к…
Anonymous Quiz
52%
DML
25%
DDL
10%
DCL
12%
TCL
🌚10👌2🤣2🔥1
Forwarded from Надежда Дудник
LEFT JOIN возвращает все строки из левой таблицы и соответствующие строки из правой таблицы.
Какие значения будут возвращены, если нет соответствующих строк в правой таблице?
Anonymous Quiz
11%
NONE
3%
NUN
80%
NULL
6%
0
👍7🔥1👨‍💻1
Что НЕ является ограничением (constraint) в SQL?
Anonymous Quiz
10%
NOT NULL
7%
UNIQUE
9%
PRIMARY KEY
25%
IS NULL
23%
CHECK
13%
DEFAULT
13%
FOREIGN KEY
6👍2🌚2🔥1💯1😭1
Какие отношения между таблицами обеспечивает ограничение UNIQUE?

——— (между таблицами может существовать несколько видов отношений - их описание находится в комментарии этого теста)
Anonymous Quiz
68%
«один к одному»
18%
«один ко многим»
14%
«многие ко многим»
👍61💯1
И еще раз повторим и закрепим:

Есть две таблицы, A1 и A2. В обоих таблицах по пять строк. Запишем запрос: 🔷Select * from A1, A2. Сколько строк получается в итоговой таблице?
Anonymous Quiz
22%
5
58%
10
2%
15
1%
20
18%
25
😱8🔥2🌚21🆒1
Вопрос на собеседование:

К тебе на тест попадает 2 проекта. В одном проекте необходимо проверить корректность внесенных правок, на другом - протестировать новый функционал. Какой проект ты возьмешь в работу раньше?

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

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

1. Зависит от дедлайнов по каждому из проектов и от оценок на тестирование каждого;
2. По приоритету задачи проекта;
3. Если приоритет одинаков, то я буду проверять новую функциональность согласно видам тестирования связанные с изменением,
я считаю, что сперва new feature testing, а потом retest - проверка правок;
Вы можете иначе сказать🙃, но думаю будет дискуссия. Поясните почему?
Ответы:
1

Я бы сказал время, если ретест значит фича близка к релизу и ее нужно быстрее обработать чтобы уложится в срок/не затягивать релиз

Новый функционал обычно планируется к релизу позже

2

Я предпочту сначала ретест, чтобы если там все починено, мы могли раскатить на прод эту фичу и начать аб эксперимент)

3. Зависит от решения PM;
4. Начать с вопросов для интервьюера. Пусть даст нормальные входные данные.
«Каковы сроки на сдачу?» и др;

Ответы подписчиков из нельзяграма:
1

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


2

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


3

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


4

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


5

Почитала еще ответы, согласна с ними тоже. Возможно новый функционал мизерный, а проверка дефекта это объемный ретест. Но почему считаю, что даже небольшой новый функционал займет больше времени - это в любом случае изучение ТЗ, какие-то уточнения с аналитиком и разрабами, написание тестов и тестирование. А существующий дефект это ситуация с шагами и описанием, где нужно проверить воспроизводится или нет. Если это твой же дефект, проверка занимает меньше времени…


Пишите и ваши рассуждения. Сохраняйте пост.
👍20🔥21
Напоминаю, что у меня есть курс по тестам для закрепления знаний и по подготовке на собеседования, на курсе также разбираются основные вопросы на собеседования в записях вебинаров и в тестах, а также в вебинарах, которые планирую проводить.

Следующий поток в начале июля.
Весь прогресс коллег и дополнения к курсу буду показывать на канале

https://news.1rj.ru/str/info_course_protestinginfo

Основные темы для разбора в интерактивном формате:
▪️Основные понятия тестирования
▪️Классификация видов тестирования
▪️Тестовая документация
▪️Техники тест-дизайна
▪️Основы SQL-запросов
▪️Протоколы HTTP/HTTPS, + другие протоколы, cURL
▪️Тестирование API
▪️REST, SOAP, JSON, XML
▪️Протоколы
▪️DevTools
▪️Postman (создание коллекций, параметризация, сниппеты)
▪️Git в рамках тестирования

Вебинары в записи про собеседование, тестирование API, логирование, тестовая модель, техники тест-дизайна, процессы тестирования и брокеры сообщений.

Живые вебинары раз в месяц.

Доступ к чату с автором курса.

Обратная связь по проверке заданий по практике в зависимости от тарифа.

Чтоб узнать первыми о старте продаж и цену тарифов, заполните форму предзаписи.
👍83🔥1