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

Здравствуйте, где можно посмотреть чек-лист к проверкам API

Я также разбираю вопросы на собеседования по тестированию на своем курсе по тестам. И мне его хочется улучшить, и те кто сейчас на курсе, и те кто не на курсе важно ваше мнение, проголосуйте, пожалуйста, https://t.me/info_course_protestinginfo

Продолжаем разбирать вопросы из списка Какой сценарий тестирования приносит больше результатов: Позитивный или негативный? 👩‍💻Пример встречного вопроса: Какие «результаты» имеются ввиду? Задавайте на собесе уточняющие вопросы для того чтобы дать свой конкретный ответ Допустим, ответ от интервьюера: Результат того, что приложение будет точно протестированным и дать актуальную информацию по продукту команде или заинтересованным лицам. Поэтому здесь больше ответ идет на позитивное тестирование. Если ответ про ожидаемые результаты, то при негативном тестировании их будет больше, и надежность приложения может быть оценена только с помощью эффективно разработанных негативных сценариев (взято из статьи) Запомните на собесе важны ваши рассуждения, правильного ответа может и не быть, так как это спорный вопрос. 👨‍💻Еще пример ответа: Позитивные сценарии - happy path тестирование. Мы знаем, что должно произойти, мы создаем эти ситуации согласно требованиям, и мы наблюдаем ожидаемый результат. Негативное тестирование — это поиск и создание ситуаций, при которых происходит отклонение от „happy path” и наблюдается непредусмотренный результат. Это отклонение от предусмотренных сценариев и поиск непредусмотренных 👩‍💻Я спросила у чата GPT, ответ таков: Сценарий тестирования (тест-кейс) может быть как позитивным, так и негативным, и каждый из них приносит результаты, важные для обеспечения качества программного обеспечения. Оба типа сценариев тестирования важны, но они приносят разные результаты: Позитивные сценарии помогают убедиться, что система выполняет свои основные функции правильно и соответствует ожиданиям пользователей. Негативные сценарии выявляют потенциальные проблемы и уязвимости, которые могут возникнуть при некорректном использовании или в непредвиденных ситуациях. Таким образом, нельзя однозначно сказать, какой тип тестирования приносит больше результатов, так как они служат разным целям. Комплексный подход, включающий как позитивное, так и негативное тестирование, обеспечит наилучшее качество и надежность программного обеспечения. Предлагайте свои рассуждения. Продолжаем дальше разбирать вопросы сперва в нельзяграме.

Друзья, сегодня в рамках рубрики про айтишный английский разбираем слова, связанные с программным обеспечением. Их оказалось так много, что пришлось разбить на два поста. 😎 Достаем словарики и записываем 27 слов, связанных с программным обеспечением. ✍️ 🟢 a compiler — компилятор 🟢 a database — база данных 🟢 a debugger — отладчик 🟢 a desktop application/app — приложение для настольного компьютера 🟢 a device driver — драйвер устройства 🟢 a graphical user interface (GUI) — графический пользовательский интерфейс 🟢 a kernel — ядро (например, операционной системы) 🟢 a mobile application/app — мобильное приложение 🟢 a plug-in (plugin) — плагин, расширение, дополнительный программный модуль 🟢 a programming language — язык программирования 🟢 a query — запрос 🟢 a scroll bar — полоса прокрутки 🟢 a snapshot — снимок состояния системы 🟢 a spreadsheet — электронная таблица 🟢 a status bar — строка состояния 🟢 a template — шаблон 🟢 a version control system (VCS) — система контроля версий 🟢 a web application, a web app — веб-приложение 🟢 a word processor — текстовый процессор 🟢 a text editor — текстовый редактор 🟢 a utility — утилита (служебная программа) 🟢 acceptance testing — приемочное тестирование 🟢 an algorithm — алгоритм 🟢 an array — массив 🟢 an encoding — кодировка 🟢 an enterprise application — корпоративное приложение 🟢 an executable (file) — исполняемый файл Сохраняйте пост себе в избранное и пишите в комментариях, какие слова были вам незнакомы. Cтавь реакцию: 🔥 — если все слова знакомы 👍 — если знаешь больше половины слов 👀 — если узнал много нового #английскийдляпрограммистов

Делитесь опытом😅😁

Напоминаю, что у меня есть курс по тестам для закрепления знаний и по подготовке на собеседования, на курсе также разбираются основные вопросы на собеседования в записях вебинаров и в тестах, а также в вебинарах, которые планирую проводить. Следующий поток в начале июля. Весь прогресс коллег и дополнения к курсу буду показывать на канале https://t.me/info_course_protestinginfo Основные темы для разбора в интерактивном формате: ▪️Основные понятия тестирования ▪️Классификация видов тестирования ▪️Тестовая документация ▪️Техники тест-дизайна ▪️Основы SQL-запросов ▪️Протоколы HTTP/HTTPS, + другие протоколы, cURL ▪️Тестирование API ▪️REST, SOAP, JSON, XML ▪️Протоколы ▪️DevTools ▪️Postman (создание коллекций, параметризация, сниппеты) ▪️Git в рамках тестирования ➕ Вебинары в записи про собеседование, тестирование API, логирование, тестовая модель, техники тест-дизайна, процессы тестирования и брокеры сообщений. ➕Живые вебинары раз в месяц. ➕ Доступ к чату с автором курса. ➕Обратная связь по проверке заданий по практике в зависимости от тарифа. Чтоб узнать первыми о старте продаж и цену тарифов, заполните форму предзаписи.

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

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

2

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

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

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

2

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

3

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

4

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

5

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

Пишите и ваши рассуждения. Сохраняйте пост.

🐹 Вы всё ещё тапаете? А мы уже всё автоматизировали! Встречаемся завтра, 14 июня в 20:00 по московскому времени, чтобы автоматизировать клики в Hamster Kombat, используя современные инструменты для автоматизации тестирования. Итак: – Настраиваем рабочее место: устанавливаем IDEA, Android Studio, Appium Server & Inspector – Запускаем простейший скрипт в классическом стеке: Java, Selenide, Appium – Учимся имитировать клики, ввод текста (и другие возможности) в приложении Hamster Kombat (господи прости) и готово 🤑. Ссылку на комнату мы опубликуем завтра в 19:50 МСК в нашем чате. Добавляй напоминание в календарь, чтобы не пропустить событие недели 💥