Чего нам всем не хватает для старта? Опыта, и представления как выглядит профессия Qa инженер- изнутри. Хочется в своей голове разложить все по полочкам, прийти к пониманию. тк изучение занудной теории, к сожалению не приближают к заветному пониманию. В этом плане мне помог Яндекс- практикум, ( не реклама!) У них есть бесплатная часть, можно ее пройти и понять как выглядит профессия изнутри, какими инструментами пользуется тестеровщик, прийти к пониманию, " А мое ли это?" Оставлю сылку под описанием https://practicum.yandex.ru/profile/qa-engineer/ Всем добра😊

решила оставить ссылки на блогеров, по IT-тематике, есть интересные интервью, люди делятся своим опытом в хождение в IT, либо есть интервью прям с мастодонтами 😁советую окружить себя миром айтишки, и слушать в свободное время хоть фоном https://www.youtube.com/@itbeard https://www.youtube.com/@myobrecheny https://www.youtube.com/@digital_ninja https://www.youtube.com/@mvlikhachev https://www.youtube.com/@larchanka
https://youtu.be/cvup0pW6WOk

Что нужно знать начинающему джуну? Конечно же теорию , предлагаю повторить : Этапы жизненного цикла ПРОДУКТА ПО : (или как его еще называют SDLC – Software development lifecycle) 1. Требования . На этом этапе Заказчик встречается с командой разработчика, обсуждает требования, обсуждают сам продукт, как должен работать, на каких платформах ,сроки. Действующие лица: Руководитель, Бизнес-аналитик. 2. Проектирования. Делится на Frontend ( графическая часть продукта, то что видит пользователь) Backend ( серверная часть, БД, то что польз. не видит) Действующие лица: заказчик, руководитель,аналитик дизайнер, разработчик. 3. Разработка. Действующие лица:Разработчик и DevOps. Они разворачивают БД, стенды,сетевое окружение, сервера, используя рпзличные языки программирования . На данном этапе идет разработка Ftontend и Backend. 4. Тестирование. На этом этапе происходит тестирование самого функционала. если обнаруживается отхождение от бизнес-логике (которая изначально была заложена в продукт) Или нарушение работы продукта , то происходит возврат продукта на стадию разработки. Если все хорошо, то происходит переход на стадию релиза- 5. Релиз. На этом этапе происходит загрузка рабочего кода, на пользовательский сервер. production.Действующие лица: Разработчик и DevOps. 6. Поддержка Service desk.Осуществляется поддержка конечного пользователя средствам чата или эл. почты.Если заключен договор обслуживания, то дейст лица будет разраб и тестер, если нет, то рабочий готовый продукт отдается в руки заказчика, тогда дейст лицо будет сам заказчик

Жизненный цикл процесса тестирования ( этот процесс направленный на тестирование Прог продукта) 1. Анализ требований - мы анализируем наши требования на логичность и отсутствие противоречий друг к другу. 2. Тестовое планирования на данном этапе, мы составляем план, в котором будут указаны: а. сроки b. способы c. методы тестирования. 3. Написание тестовых сценариев на этом этапе производим написание тестовых сценариев программного продукта, а так же вариантов комбинаций исходных данных и действий.
4. Подготовка тестовой среды. На этом этапе происходит подготовка стендов ( сервера) для тестирования. Что такое стенд? Это то чем будет пользоваться наши тестировщики, с актуальной версией продукта, в этом нам помогают DevOps. Это может происходить локально, удаленно или же на специализированных сервисах. 5. Выполнение тестов. На данном этапе происходит сам процесс тестирования программного продукта, используя тестовые сценарии, написанные нами ранее. 6.Завершающая фаза Если в результате тестирования, тесты выполнены успешно, то передаем функционал в релиз, если нет, то возвращаем в разработку, для дальнейшего исправления дефектов.

Что же такое Тестирование – это исследование поведения программного продукта, основной целью которого является выявление багов. Баг (дефект) - это отклонение ожидаемого результата от фактического. Тестировщик – это специалист, который обеспечивает качество продукта, проверяет, чтоб он работал правильно, соответствовал требованиям заказчика, и не было отклонения от бизнес логики продукта.

Привет Друзья! В данной статье, мы обсудим самые важные принципы тестирования, которыми должен руководствоваться каждый тестировщик!

Выделяют 7 основных фундаментальных принципов тестирования, которые помогут Вам понять сам подход к процессу тестирования и сформировать понимание как же выстраивать стратегию тестирования

1.Тестирование демонстрирует наличие дефектов. Тестирование снижает вероятность дефектов, которые находятся в программном продукте, если вы не нашли их - это не значит, что их нет. 2. Исчерпывающее тестирование. Вы никогда не сможете проверить все варианты вводимых данных, на это уйдет бесконечность. Поэтому необходимо проверить только ожидаемые комбинации и использовать парное тестирование. 3. Ранее тестирование. Для того чтоб найти дефекты как можно раньше, нужно начать тестрование на момент составления спецификации, на логичность и не противоречивость; тестировать код; Если мы нашли дефекты на ранних этапах, это значит, что затраты на устранения, будут минимальны; Если после выхода в релиз, то затраты могут быть максимальны. к примеру это банк и были ошибочно переведены денежные средства или клиент потерял их по нашей вине.

4. Скопление дефектов. Так называемый принцип 80% на 20% (принцип Парето). 80% дефектов находится в в 20% функционала продукта, и наоборот. Необходимо предусмотреть каким функционалом будет пользоваться конечный пользователь, и уделить ему особое внимание. Например, которые требуют ввода данных в поля , и где есть логика зависимости заполнения полей. 5. Парадокс пестицида. Если каждый раз использовать один и тот же сценарий снова и снова, то со временем, этот набор тестов перестанет выявлять новые баги. Ведь после каждого нахождения багов, разработчики будут их исправлять, и при след тестирован. скорее всего уже не будут обнаружены. Поэтому важно каждый раз менять тестовые сценарии. 6. Тестирование зависит от контента. Например, банковский софт,в котором критически важна безопасность тестируется иначе чем новостной портал и портал прогноза погоды. 7. Заблуждение об отсутсвие ошибок. Отсутсвие дефектов не всегда означает готовность продукта к релизу. Продукт должен быть удобен и удовлетворять ожидания и потребности пользователя.

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

Поговорим о Классификация багов, и какие бывают приоритеты в баг-репортах
Баги — очень разные. Их различают по степени влияния на систему — серьёзности (severity):
Блокирующий (Blocker), на жаргоне — «блокер». Ни один элемент системы не работает: никто не может ей пользоваться.
На сайте интернет-магазина нельзя сделать покупку. Продукт не выполняет свою задачу.
Критический (Critical). Важная часть системы не работает: пользоваться можно, но вероятность сбоя — высокая.
В интернет-магазине не работает кнопка «Купить» после авторизации в личном кабинете. Без авторизации всё работает — магазин ещё может принимать заказы.
Высокий (Major). Система работает, но не так, как нужно. Пользоваться можно, элементы активны, но выполняют не то, что задумано.
В интернет-магазине по кнопке «Купить» выдают скидку 3% на покупку. Приятно, но это не то, что планировали маркетологи. Кнопка работает неправильно.
Низкий (Minor). С системой всё в порядке, но работать неудобно. Например, дефект в дизайне.
В интернет-магазине в разделе «Товары» не работает вертикальная сортировка. Это не мешает пользователям делать заказ — ошибка не такая серьёзная.
Незначительный / Тривиальный (Trivial). Баг, который не влияет на работу программы. Например, ошибка в тексте.
На сайте интернет-магазина раздел «Чайники» назван «Чайник». Исправить ошибку совсем легко.

Шпаргалка по составлению баг-репорта

Обязательные элементы баг-репорта — окружение и версия приложения. Окружение — это среда, в которой произошла ошибка: информация об операционной системе, браузере и типе устройства. А версия приложения — «номер партии» продукта. Тестировщик описывает окружение при заведении баг-репорта. Порядок описания такой:
Версия приложения — укажи версию продукта.
Браузер — укажи версию и название браузера, в котором тестировалось веб-приложение.
ОС — укажи версию операционной системы: Windows, macOS, Linux, Android, iOS. Если ты тестируешь приложение на компьютере или ноутбуке, то устройство указывать не нужно. Если ты тестируешь на мобильном устройстве, нужно дополнительно указать:
тип устройства, на котором обнаружена проблема. Например: смартфон, планшет или электронные часы;
ПРИМЕР: На MacBook Pro с операционной системой MacOS 10.14.6 установили браузер Google Chrome версии v. 77.0.3865.75. Тебе нужно проверить тестовую версию приложения Яндекс.Еда с номером 222.32.1. Будет выглядить след образом:

Версия приложения: 222.32.1, браузер: Google Chrome v. 77.0.3865.75, ОС: macOS 10.14.6

Друзья, есть гугл-таблица, по ментором и менти, можно найти своего наставника,подготовиться к собесу, получить опыт, разобрать свои знания с наставникам по полочкам https://docs.google.com/spreadsheets/d/1Ql4F7iIEa4_PdlJbpShHdV3W9We4kZQjN6Uv9AFsYyA/htmlview#gid=1009536141

Шпаргалка-окружение

Замечательная книга! Учебный и теоретический материал подан настолько легко, что запомнить и понять не составит особого труда. Савин полностью показывает профессию тесетровщика со всех сторон, и самое главное ты начинаешь нырять во всё это.
Да, какие-то методы устарели, однако в целом книга очень познавательна и актуально по сей день. Много от кого слышала о ней, а сегодня делюсь ею с вами 😊Приятного прочтения .

Как правило, когда вас спрашивают на собеседовании о видах тестирования, собеседующий имеет в виду классификацию по уровню функционального тестирования, а это : Функциональное тестирование - отвечает на вопрос, что должен делать наш продукт? Задача проверить, что все функции приложения работают как положено и отвечают требованием заказчика.
Например: кнопочка «login» должна быть желтого цвета. Проверяем, она желтая? Она нажимается? Выполняет ли свою функцию и можем ли мы залогиниться? Выполняет ПО, свою основную функцию или не выполняет. Вот это ключевое что мы проверяем.

И разберем какие бывают виды виды функционального тестирования: -Дымовое тестирование (smoke test)- проводится после появления нового билда (некая промежуточная версия ПО). Отвечает на вопрос: готово ли приложения для выполнения своих основных функций? Например: можем ли мы залогиниться, отправить товар в корзину, провести оплату;- максимально всё поверхностное без детализации.Часто автоматизируется.

Тестирование критического пути. - направлено для проверки функциональности, тестируем типичные функции пользователя,его типичные задачи . Плюс ко всему позволяет выявить самые быстро находимые дефекты и исправить приложение в более сжатые сроки. Например: Заходим на сайт aliexpress, можем ли мы залогиниться; вбить интересующий товар в поисковик; добавить в корзину; в избранное СМОЖЕМ ЛИ К ПРОЦЕССУ ПОДКЛЮЧИТЬ ФИЛЬТР, по определенному параметру данного товара. / хотим отправить письмо по мail , меняем штрифт, жирность, размер, цвет. и т.д. Здесь мы проверяем основную массу требований к продукту,все ли с ним ок. Часто используется для вэб-проектов.

Расширенное тестирование (extended) Проверяем нестандартное использование приложение. Например: вводить некорректные логин / пароль в поле, или оставить их пустыми и нажать - авторизация. Подгрузка файлов недопустимых размеров или форматов. На собеседование за основу можно взять три основных вида : smoke test; критического пути; расширенное тестирование.

Какие бывают виды нефункционального тестирования: 1. Тестирование производительности (performance testing) 2. Инсталляционное тестирование (installation testing) 3. Проверка удобства (Usability) 4. Тестирование безопасности (security testing) 5.Тестирование локализации ( L10N) и интернационализации(L18N) 6. Тестирование доступности (accessibility

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

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