QA AK

В новом видео рассказываю про нюансы своей профессии. Актуально для тех кто рассматривает переход в тестирование. ссылка

#отзыв

У Артема Русова на канале недавно вышел пост со ссылкой на репозиторий с тестовыми заданиями. Я посмотрел одно на тестирование API и решил разобрать. Видео с решением уже на моем YouTube канале: >>> ссылка <<<

Новая викторина, друзья. В этот раз вопросы на знание SQL. В качестве примера используется СУБД PostgreSQL и таблица films.

Продолжаю отвечать на вопрос "где брать опыт после курсов по тестированию". 🔍🕵️‍♂️ Спонтанно принял участие в соревновательной сессии тестирования от ребят Pro-test.Studio. Объявление о соревновании увидел в JUNOHub. Сначала хотел посмотреть, что называется одним глазком, а потом не заметил, как втянулся 🙂 В чем суть. Ребята предлагают в течении полутора суток протестировать сервис партнеров на тестовом окружении. Сервис настоящий и понятный в плане-бизнес логики. А для поднятия мотивации, в качестве формата выбрано соревнование по принципу "кто найдет больше всех багов, тот и победил". Баги заводятся в Trello и проходят модерацию, после чего участнику присваиваются баллы, для того чтобы в конце определить победителей. Учитывая, что документации с требованиями к сервису нет и руководствоваться следует логикой и здравым смыслом, данный ивент хорошо прокачивает исследовательское тестирование и позволяет попрактиковаться в применении техник тест-дизайна. + Можно увидеть какие баги завели другие участники и перенять чужой опыт. Ребята обещают проводить подобные соревнования еще и заранее сообщать о них тут: ссылка. Поэтому тем кто ищет практику или просто хочет принять участие для развлечения, советую мониторить события на этом канале.

Что делать, если после тестирования на проде нашлись баги? 🪲🐞 Ситуация, в которой может оказаться любой тестировщик. Вы выполнили регресс, отдали продукт, а затем в нем обнаружились баги. Пользователи стали заводить обращения с проблемами в ключевом функционале. Разберем эту неприятную ситуацию. 1️⃣ Стоит разделить чувство вины и ответственность. Не нужно себя винить и сомневаться в своей компетентности. Это не продуктивно и точно никак не поможет вам в работе. Ошибки допускают все. Как минимум, кроме вас их допустили разработчики, и они вылились в дефекты, которые не были обнаружены в ходе тестирования. Но и списывать это на принцип "исчерпывающее тестирование невозможно и баги будут находиться всегда" тоже не стоит. Нужно признать, что причиной пропуска багов в ключевом функционале является наличие проблем в процессе тестирования. 2️⃣ Важна не ошибка, а реакция на нее. Подобная ситуация - это сигнал к тому, что имеющиеся тесты не справляются со своей задачей. Поэтому нужно разобраться почему. Исследуйте баги, попробуйте их локализовать и выявить причины возникновения. Затем соотнесите их с имеющимися в регрессе тестами, которые покрывают требования к фиче, где возникли проблемы. Причины, почему тесты не позволили обнаружить баги, могут быть разными: 🔺 проблемная область в целом не тестировались 🔺 нет достаточного понимания работы фичи, из-за чего требования к ней покрыты не полностью 🔺 тесты есть, но тестовые данные в них отличаются от реальных и выявить проблему не смогли 🔺 ошибка у пользователя возникает на другом окружении, на котором тесты не проводились 🔺 ... Затем, когда причины будут ясны, принимайте соответствующие меры. Изучите дополнительно работу компонента, где обнаружились баги, восполнив тем самым пробелы в знаниях и понимании ее работы. Пересмотрите и модифицируйте уже имеющиеся тесты, с учетом полученных данных. И обязательно дополните набор тестами проблемных кейсов, которые будете выполнять для проверки исправлений и последующих регрессий. Если вы заинтересованы в профессиональном росте и в улучшении качества продукта, используйте подобную ситуацию как реальную обратную связь, касающуюся эффективности ваших тестов и реагируйте, предпринимая адекватные меры для ее улучшения.

Записал свой первый shorts, посвященный важности тестирования граничных значений диапазона. Вспомнил старый баг из Ultimate Mortal Kombat 3 для Sega и решил использовать в качестве примера: часть 1 часть 2

Записал небольшой tutorial о том как скачать лог запросов в формате har при тестировании веба: ссылка Кстати, подписывайтесь на мой Youtube-канал. На нем я тоже выкладываю полезный контент по теме тестирования и планирую нарастить активность.

Использование USING в запросах с JOIN. На собеседованиях, которые мы проводили и о которых я писал в более раннем посте, у нас были задачки на выполнение SQL запросов, требующие, в том числе, умение применять JOIN. За все время только 1 из кандидатов, при указании условия соединения использовал USING. Пожалуй, на основе такой (пусть и скромной) статистики стоит рассказать про него. При использовании оператора JOIN, если нам требуется сопоставить строки из разных таблиц на основе связанных столбцов, мы можем указать условия, используя ON или USING. В ON мы в явном виде указываем логическое выражение. Пример: выведем имя, фамилию и диагноз пациентов из таблиц patients и admissions. select patients.first_name, patients.last_name, admissions.diagnosis FROM patients JOIN admissions ON patients.patient_id = admissions.patient_id При использовании же USING достаточно указать в скобках столбцы, по которым будет происходить объединение. В нашем примере это будет выглядеть так: SELECT first_name, last_name, diagnosis, FROM patients JOIN admissions USING(patient_id) Т.е USING(patient_id) = ON patients.patient_id = admissions.patient_id Таким образом запись будет выглядеть короче и написание запроса будет занимать меньше времени + не будут выводиться одинаковые (избыточные) столбцы, для запроса вида SELECT * . Однако важно помнить, что указывать в скобках можно только столбцы с одинаковым именем. Поэтому соединить doctors и admissions по столбцам doctor_id и attending_doctor_id можно только используя ON. А как использовать USING при объединении более 2 таблиц? Дополним пример выше еще одним оператором JOIN для вывода столбца province_name из таблицы province_names: SELECT first_name, last_name, diagnosis, province_name FROM patients JOIN admissions USING(patient_id) JOIN province_names USING(province_id) Используйте USING в задачах на собеседованиях и выделяйтесь на фоне конкурентов. Почитать документацию можно здесь: ссылка А потренироваться в написании запросов можно здесь: ссылка

При проведении собеседований на позицию Junior QA в разных компаниях часто используются типовые вопросы. Недавно нашел на LinkedIn классный пример чит-листа от @p1nkx1, содержащего такие вопросы + сжатые ответы на них: ---> Ссылка <--- Кратко и емко. Советую пройтись по нему при подготовке к предстоящему собеседованию.

Привет, коллеги! Если вам нравится контент на этом канале, призываю вас его поддержать (оставить голос можно если у вас есть Телеграм Премиум): https://t.me/QA_AKlimenko?boost Спасибо!

Вопрос на собеседовании: "чем отличается метод POST от метода PUT"? Существуют сетевые стандарты, которые устанавливают принципы и правила взаимодействия между участниками сети. Для HTTP протокола одним из стандартов является rfc9110. Согласно ему, по умолчанию, методы предназначаются для выполнения следующих действий с ресурсом: POST - Perform resource-specific processing on the request content. PUT - Replace all current representations of the target resource with the request content. Если с методом PUT в данном описании все понятно - он используется для замены представления ресурса содержимым запроса (например, для обновления объекта), то по методу POST даются дополнительные разъяснения. For example, POST is used for the following functions (among others): - Providing a block of data, such as the fields entered into an HTML form, to a data-handling process; - Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles; - Creating a new resource that has yet to be identified by the origin server; and - Appending data to a resource's existing representation(s). Т.е метод POST передает данные из запроса для их последующей обработки ресурсом. В примерах идет речь о создании нового ресурса или добавлении данных к существующему представлению ресурса. Однако углубившись в стандарт можно увидеть что PUT тоже может применяться для создания ресурса: The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message content. В чем же тогда различие? Ответ кроется в свойствах методов, указанных в этом же стандарте. Метод - PUT является идемпотентным. A request method is considered idempotent if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent. Т.е многократное выполнение PUT будет эквивалентно единоразовому. Сколько бы раз мы не послали один и тот же PUT запрос, эффект на ресурс будет одинаковым. А вот POST таковым не является, что означает различие в результатах при многократном выполнение одного и того же запроса. Пример: POST /add_row HTTP/1.1 POST /add_row HTTP/1.1 -> Adds a 2nd row POST /add_row HTTP/1.1 -> Adds a 3rd row - POST всякий раз будет добавлять новую строку. Поэтому, подытожив, отличия заключаются в: 1. В назначении методов: POST применяется для создания/добавления новых ресурсов, PUT также может применяться для создания ресурса и для обновления его представления. 2. В идемпотентности: PUT идемпотентен, а POST нет. Но в конце обязательно стоит внести ремарку о том, что разработчики могут не следовать никакой спецификации при разработке API, и использовать методы для любых целей. Поэтому мы можем видеть встретить API, где, например, POST используется для обновления объекта.

💻📔 На что обратить внимание при выборе курса по тестированию? Школ и обучающих платформ много, а курсов еще больше. Как выбрать курс в таком многообразии? Поделюсь критериями, которыми я советую руководствоваться при выборе курса по тестированию. 1️⃣ Возможность задавать вопросы преподавателям/менторам и своевременно получать обратную связь. По своему опыту и опыту, обращавшихся ко мне менти, скажу, что у вас обязательно будут возникать вопросы по изучаемому материалу и домашним заданиям. Например, популярный вопрос, который я встречал у учащихся, после изучения use case и тест-кейсов: "В чем их отличие и когда следует составлять тот или иной вид документации". И подобных вопросов у вас будет много. Плюс вопросы по оформлению, организационного характера... Если все они будут оставаться без ответа, у вас будет оставаться неопределенность, вы будете не уверены в правильности выполняемой работы и как следствие в своих знаниях. Поэтому важно чтобы в команде курса были те, кто готов и будет оперативно отвечать на ваши вопросы. 2️⃣ Как можно больше практики. Выполняя практическую работу вы также будете сталкиваться с множество вопросов, подводными камнями, совершать ошибки и их исправлять. Все это будет способствовать усвоению теории и углублению понимания. Иначе, без достаточного количества практики, изученная теория будет быстро забываться. 3️⃣ Наличие реальных проектов, на которых вы будете оттачивать хард скиллы. Идеальный вариант, когда к школе обращается компания для заказа тестирования своего продукта. Вы получите приближенный к боевому опыт, под руководством опытного куратора, что будет ценнее работы с учебной площадкой/тренажером, который имитирует и отдаленно похож на реальный продукт и в котором специально были заложены баги. 4️⃣ Маленький размер учебной группы (не более 10 человек). Чем больше в группе будет учащихся, тем меньше внимания вы сможете получить. Также в огромных группах время ответа на ваши вопросы и проверки домашнего задания будет затягиваться и может занимать несколько дней. 5️⃣ Учебная программа не растянута по времени и состоит из тем напрямую относящихся к предмету. Лучше выбрать курс протяженностью в несколько месяцев, который будут содержать материал именно по тестированию, а также технологиям и инструментам которыми вам предстоит пользоваться в рамках него, чем многолетнее обучение с кучей модулей, которые будут относиться к IT, но не иметь прямого отношения к тестированию. Информацию об этом и не только важно и нужно узнавать у консультантов перед принятием решения о покупке курса. Также ее следует сопоставлять с реальным положением дел и в этом вам могут помочь отзывы, оставленные учащимися и выпускниками. Посмотреть их можно, например, здесь: ссылка