Всем привет👋 Меня зовут Александр и я тут делюсь знаниями, опытом и рассказываю только полезную информацию про обеспечение качества продуктов (QA) и конечно же контроль качества (QC). ✅

Это может быть полезно для тестировщиков, которые хотят развиваться в профессии, а не сидеть внутри одной команды 🧑‍💻

Подписывайтесь, чтобы не пропустить новые статьи 🖥

Уровни развития тестировщика Junior ➡️ Head of QA

Junior - самый начальный уровень. Как правило отвечает за небольшую часть функционала продукта. Из-за недостаточного опыта, задает много вопросов и самостоятельно не принимает решений. Занимается только ручным тестированием.

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

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

ℹ️ Рассмотрим менеджерские позиции:
Lead QA - это специалист, который отвечает за координацию и управление процессом тестирования. Он обычно руководит небольшой группой тестировщиков, создает тестовые планы и сценарии, отслеживает результаты тестирования и вносит рекомендации по улучшению процесса. Чаще всего на каждом проекте свой Lead QA.

Head of QA (руководитель отдела качества) - это более высокий уровень должности, чем Lead QA. Он отвечает за стратегическое планирование и управление всем отделом тестирования в компании. Head of QA обычно принимает ключевые решения по развитию и улучшению процессов тестирования, управляет бюджетом отдела, устанавливает стандарты качества и нанимает и обучает персонал. Находится над всеми проектами в компании и управляет лидами.

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

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

📋 Обеспечение качества программных продуктов (SQA) – это не просто тестирование, а комплексный процесс, интегрированный в жизненный цикл разработки. Его цель – гарантировать, что продукт соответствует всем требованиям и ожиданиям пользователей.

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

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

Я для себя составил чек лист, по которому сверяюсь на пути к качеству. 

♻️ 1. Процессы (workflow):

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

📑 2. Документирование:

- Используйте документацию для написания тест-кейсов.
- При отсутствии документации, собирайте информацию у аналитиков, бизнес-подразделений и т.д.
Цель - знать как должно быть, чтобы определять баги и корректно проверять работоспособность продукта.

➗ 3. Разделение:

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

🧑‍🔧 4. Автоматизация:

Автоматизируйте рутинные задачи тестирования, например, регресс, ключевые сценарии, API. Тем самым вы освободите время тестировщиков для более сложных и полезных задач.

📊 5. Аналитика:

- Собирайте и анализируйте метрики качества.
- Используйте полученные данные для выявления проблемных зон и оптимизации процесса тестирования.
- Отслеживайте прогресс и демонстрируйте влияние SQA на качество продукта.

Что дальше? - нужно использовать только те инструменты, которые необходимы продукту.

Например, если у вас внутреннее приложение, то совсем не обязательно тратить время на нагрузочное тестирование

Обычно в командах используют ручное тестирование ( функциональное, регрессионное, юзабилити-тестирование и тд).
Когда становится много рутинной работы, внедряют автоматизированное тестирование.
Для высоконагруженных приложений необходимо проводить нагрузочное тестирование.
А для микро-сервисной архитектуры используют API тесты
Так же не стоит забывать про кросс-браузерное и кросс-платформенное тестирование.

❕ Еще важно создать культуру качества в команде: поощрять инициативы, делиться знаниями, непрерывно совершенствоваться.
Помните, что SQA – это не разовая акция, а непрерывный процесс.
Постоянно совершенствуя его, вы сможете добиться высокого качества программных продуктов и завоевать доверие пользователей.

Чек-лист, представленный в этой статье, является лишь отправной точкой.
Его можно адаптировать под ваши конкретные задачи и проекты.

Главное – не останавливаться на достигнутом и всегда стремиться к улучшению! ✨

🌐 Выкатываем сложные фичи без проблем: практический пример

Ситуация:

Бизнес ставит задачу: реализовать личный кабинет пользователя. В документе с требованиями подробно описаны функции кабинета и их назначение.

Обычный подход:

Аналитик создает задачу на разработку в виде эпика, в который вносятся все подзадачи, связанные с личным кабинетом.

🔴 Проблема:

При таком подходе тестирование откладывается до момента завершения всех подзадач. Это приводит к:

Затягиванию сроков: Тестирование большого количества задач занимает много времени.

Множеству ошибок: На этапе тестирования выявляется множество ошибок, требующих доработки. Не всегда очевидно к какой подзадаче относится баг.

Изменениям в ТЗ: В процессе разработки могут меняться требования, что приводит к необходимости корректировки задач.

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

Решение:

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

Ошибка:

Ошибка заключается в том, что на этапе создания задачи не учитывают особенности тестирования и выкатки в продакшн.

Не нужно искать виновных:

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

Другие возможные причины:

Отсутствие тестировщика на этапе постановки задачи: Подключение тестировщика на этом этапе могло бы помочь выявить проблемы с тестированием на ранней стадии.

Человеческий фактор: Ошибки и недочеты неизбежны в любой работе.

🟢 Как избежать проблем:

Документирование постановки задач: Необходимо задокументировать процесс постановки задач на основе требований бизнеса.

Разделение фичи на этапы: Разбивайте большие фичи на независимые части или этапы, каждый из которых оформляется как отдельный эпик.

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

Поэтапная выкатка: Выкатывайте этапы фичи по очереди, а не все сразу. Не обязательно, но желательно.

Преимущества:

Сокращение времени разработки: Тестирование и выкатка этапов по отдельности позволяет быстрее выпустить продукт.

Снижение количества ошибок: Выявление и исправление ошибок на ранних этапах

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

Вывод:

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

🔍 Почему так сложно найти тестировщика?

Я провел более 100 собеседований на позицию тестировщика. На самом деле гораздо больше, просто в какой-то момент я уже потерял счет.

Занятие это, скажу не благодарное, тратится куча времени, но работу за меня никто не делает. И сотрудника не взял, и в дедлайн не успел. Шутка конечно, но в каждой шутке есть доля правды.

Когда уже опускались руки, в заявке на подбор я указал, что нам нужен не просто тестировщик, а тестировщик с опытом работы в веб-разработке. Обязательные требования – это знание DevTools, HTML и CSS. Тестирование фронт-энда и бэк-энда 50/50.

Казалось бы, это же самое легкое, но в результате, если пишут, что знают DevTools, то они просто знают, что это такое, и не факт, что приходилось этим пользоваться. Интересно, чем еще можно тестировать фронт-энд. Я не говорю уже про HTML и CSS.

🟢 Проведя еще десяток таких собеседований, я разделил тестировщиков на группы.

1. Тестировщики из банковской сферы:

Герои бэк-энда из маленькой команды, которая отвечает за одну кнопку/API.
Чем они там занимаются, толком не ясно, но знаний даже по API я не увидел.

2. Мобильные тестировщики:

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

3. "Войти в АйТи":

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

4. Элита тестирования:

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

Но эти ребята нам тоже не подходят:

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

Во-вторых, просят космические зарплаты.
Например, один на полном серьезе запросил 500к на руки, а остальные с годом опыта – в среднем 250-350к. Избаловали их, видимо, вакансии на hh.

🔴 Ни одна из категорий нам особо не подходит и остается только бесконечно искать баланс цена-качество или брать любого более менее адекватного и самим его обучать. Теряется много драгоценного времени, которого как обычно нет.

Если вы узнали себя в одной из моих групп, ставьте лайк. 👍 В следующий раз выложу вопросы, которые я задаю на собеседовании и расскажу что нужно изучать, чтобы вы без проблем могли устроиться в любую компанию.
А если вы уже в поиске работы, имеете опыт работы в веб разработке, то присылайте резюме uzao-rec@ya.ru ✉️

Вопросы, которые я задаю на техническом собеседовании:

➡️ Общие вопросы:

1. Для чего нужно тестирование ?
2. Жизненный цикл бага ?
3. Чем отличается серьезность бага от приоритета?
4. Из чего состоит баг репорт?
5. Какие инструменты использует тестировщик в своей работе ?
6. Задача: Протестировать лифт обозначая виды тестирования
7. Задача: Пришла задача на тестирование, кроме заголовка ничего нет, какие ваши действия?

➡️ Верстка:

8. Какие инструменты используют для тестирования верстки ?
9. Чем отличается padding от margin ?
10. Что произойдет, если div указать атрибут title="текст" ?
11. Чем отличается попап и тултип?
12. Задача: Как посмотреть свойства css у тултипа?
13. Задача: Пришел новый дизайн карточек товара на выдаче, тестировщик уже сравнил с макетом. Реализация устроила. Но какие дополнительные проверки необходимо провести, чтобы полностью протестировать верстку.

➡️ DevTools:

14. Расскажи возможности вкладки Elements (html, styles, Event listeners...)
15. Вкладка Console - Что делать если есть ошибка?
16. Вкладка Network ( Headers, Payload, Preview, Response, Initiator )
17. Вкладка Application - разница между Local Storage и Session Storage и разница между Куки - кэш

➡️ API:

18. Какие бывают протоколы передачи данных ?
19. Какие есть методы HTTP запросов ?
20. Что такое DNS ?
21. Чем отличается PUT и PATCH ?
22. Какой запрос сможет с большей вероятностью перегрузить сервер? GET или POST?
23. Какие бывают коды ответов ?
24. Какой ответ будет при успешной регистрации пользователя или добавлении нового товара?
25. Задача: Что произойдет если в адресной строке браузера ввести адрес сайта и перейти ?
26. Задача: Что происходит, когда на сайте в поиск начинают вводить текст и появляются подсказки ?

➡️ SQL

27. Какие программы используют для тестирования db ?
28. Чем отличается LEFT JOIN от RIGTH JOIN ?
29. Задача: (Рандомные задачи с использованием JOIN и сортировкой)

➡️ Тест дизайн:

30. Что такое тест дизайн ?
31. Техники тест дизайна ?
32. Как часто необходимо проводить регрессионное тестирование ?
33. Как определяется возраст дефекта ?

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

Нужен ли тестировщику свой pet-проект ❔

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

Это нужно для развития своих навыков, обучения и даже заработка.

🟢 Что касается тестировщиков, то одна из ветвей развития, это повышение качества тестирования. Когда тестировщик знает как разрабатывается продукт, то он лучше его протестирует.

Так же pet-проект можно использовать для портфолио, он выгодно будет отличать вас перед другими кандидатами.

🟢 Так как it сфера быстро развивается, то нужно привыкнуть к тому, что необходимо постоянно учиться. А на своем проекте, можно закреплять все на практике.

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

➡️ Войти в айти!!!

В последние годы в интернете распространяется реклама курсов «Войти в айти», где рассказывают, что айти это просто, ненужно ничего знать и достаточно только купить курс.

Они утверждают что профессия тестировщик идеально подходит для мам в декрете, школьников, пенсионеров и вообще всех!

Но стоит ли этому верить ? Давайте разберемся, какова же реальность профессии тестировщика.

А что если я скажу, что тестировщик - далеко не самая простая работа в IT ?

🟢 На самом деле, это одна из самых комплексных и требовательных специальностей. Тестировщик должен обладать:

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

Знаниями в области разработки: понимание принципов работы ПО, знание языков программирования и основ тестирования - все это необходимо для эффективной работы.

Навыками коммуникации: тестировщик должен уметь чётко и ясно формулировать свои мысли, как устно, так и письменно, взаимодействовать с разработчиками, аналитиками и другими членами команды.

Постоянным стремлением к обучению: мир IT стремительно развивается, и тестировщик должен быть в курсе всех новинок, изучать новые технологии и подходы к работе.

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

🟢 Можно ли стать тестировщиком без опыта и знаний?

Теоретически - да, но этот путь будет очень непростым. Вам потребуется самостоятельно освоить обширный объем информации, пройти множество бесплатных и платных курсов, практиковаться на тестовых проектах и участвовать в open-source сообществах.

🟢 Готовы ли вы к этому?

Подумайте, сколько времени и сил вы готовы потратить на обучение?

Сейчас на рынке бардак. Так как волна курсов давно была запущена, много тестировщиков с опытом несколько лет, но при этом с нулевым уровнем знаний.

Всему конечно можно научиться, но все ли готовы тратить по несколько часов в день на учебу ? Многие к этому не готовы из-за разных обстоятельств. Например, кому-то тяжело дается учеба, у кого-то семья и домашние обязанности, разные хобби и так далее. Продолжать можно бесконечно.

Таким образом, прежде чем решиться "войти в айти" и стать тестировщиком, необходимо понимать все тонкости и сложности этой профессии. Учеба, практика, постоянное развитие и обучение - вот то, что необходимо для успешной работы.