Привет, заводчане! В этой статье вы найдете реальные технические советы по особенностям общения с бездушными ИИ моделями, в частности я расскажу про GPT 4o и свежую 5, но эти советы также применимы и к другим AI.

‼️Сразу внесу ясность: рекомендации предназначены для личных пет-проектов и
не призывают нарушать политику конфиденциальности вашей компании!

Я инженер по тестированию и уже около года поддерживаю работу своей песочницы по практике тестирования и подготовке к собеседованию на позицию Full Stack QA. Опыт вайбкодинга повлёк за собой понимания работы JS, CSS и HTML, если говорить конкретно про веб-проект. Благодаря такому проекту и подходу вайбкодинга, я собрал технические инструкции и заметки как выжать максимум из ответа ИИ моделей, здесь будет больше технических особенностей работы с моделями, нежели готовые промпты. Ниже указал 12 советов, которые упростят вам написание кода, разработку своего проекта, изучение нового стека или учебную практику.

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

Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано...

Вам задают простой вопрос, почему вы пропустили баг на прод? Это обычный разбор полетов после релиза и нужно учится на своих ошибках, прежде чем стартанет следующий горящий релиз! И нам необходимо объяснить причину, которая скрывается не только в процессах тестирование, но и в процессах всей команды.

Привет, Хабр! Меня часто спрашивают, где можно попрактиковаться в тестировании сервиса? Чтобы не просто найти баги на проде, а провести полный регресс после внесения изменений? Я называю это тестированием с обратной связью. И однажды, устав отвечать на такие вопросы, я решил спроектировать сайт-песочницу. Там не только можно попробовать свои силы, но и найти много информации для начинающих тестировщиков. 

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

• Функциональное тестирование

• Написание чек‑листов

• Анализ документации

• Заведение багов

Вопросов здесь много! Во‑первых, написали не по порядку, сначала идёт анализ документации. Но если серьёзно, то такой список навыков не подходит. Это уровень не джуна, а студента в первый месяц обучения.

Навыки в резюме — это умения, знания и владение программами, которые позиционируют соискателя как профессионала.

Как вы считаете, написание данных проверок исчерпывающе или в этом есть смысл, с учетом дефицита времени у QA инженеров?

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

И что же делать? Можно как вариант объединить баги шрифтов, размеров и прозрачности с одного экрана в одну задачу на исправление, и тогда приоритет у правки возрастет. Дополнительно хочу подсветить, что мы можем столкнуться с изменением одного экрана, который влияет на связанный функционал в остальных частях МП (если это старый UI баг).

Всем привет! Меня зовут Иван, третий год в тестировании. На данный момент нахожусь на мобильном проекте финтеха. Сегодня покажу ленивый чек-лист для тестирования маски и полей ввода. Заезженный номер телефона поберегите для себя, а мы тестируем реквизиты счёта!

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

У нас есть три поля на одной странице "Номер счёта", "БИК", "Наименование банка".

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

Зачем нужна данная карта для QA?

Качество покрытия материала: матрица трассировки вам о чем‑нибудь говорит? Если да, то данный формат разбивает и систематизирует необходимые знания на модули, что позволяет убедиться в качестве и полноте покрытия ваших знаний.

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

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

Лучшее запоминание материала: Мы запоминаем благодаря ассоциативной памяти и нейронным связям. Если вы читали книгу Тони Бьюзена «Интеллект‑карты», то, вероятно, согласитесь со мной.

Отработка навыка: Навык использования mind‑map необходим в работе. Поэтому подготовка к собеседованию или проверке знаний с использованием карты позволит вам заранее ознакомиться с ней, что благоприятно скажется на вашем умении и полноте вашего резюме.

Привет, Хабр! Меня зовут Иван, я Full Stack QA. Сегодня поговорим про альтернативы ChatGPT, которые работают на территории РФ без костылей и совершенно бесплатно.

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

Главное правило ручного тестировщика - для начала нагугли проблему спроси у GPT и только после обращайся с вопросом к ментору.

🤖 Первый аналог - Coze.com | Открыть модель

Первый ИИ работает в телеграм-боте и всегда будет у вас под рукой...

Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA.

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

Первый риск: Идея попадает к аналитику

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

Второй риск: разработка по тех. требованиям

Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.

Сегодня мы поделимся навыком тестирования сайтов и веб-приложений с помощью Cypress. Автоматизируем поиск книг по тестированию и добавим их в избранное на сайте Литрес!

Что нам необходимо для установки и запуска автотестов:

1. Браузер Chrome актуальной версии;
2. Редактор кода VS Code;
3. Терминал или Командная строка (PowerShell) по умолчанию есть на macOS и Windows;
4. Доступ к терминалу есть также внутри программы VS Code;
5. Node.js и Cypress мы установим через Терминал (Командную строку).

На компьютер необходимо установить 3 программы (Chrome, VS Code и Node.js)
Остальные установки будут происходить внутри Терминала на вашем компьютере.

Теперь мы можем сделать вывод, что автоматизация - это ручные тесты, переведённые в автоматический процесс. И если нет ручных, то нет и автотестов.

Хочешь кататься, люби и саночки возить - это как раз про проектирование тест-кейсов. Мы конечно говорим не про автоматизаторов, которые пишут автотесты по ТК от ручных тестировщиков. Мы говорим про QA, который одновременно выполняет роль manual и automation engineer в команде.

Сегодня мы будем писать на Java

⚠️ Для того чтобы Яндекс не поставил капчу на наш парсинг сайта, нам необходимо сначала зайти на любую страницу, к примеру google translate и только после мы загружаем https://music.yandex.ru/home. Задача избежать прямого посещения сайта.

Шаг 1 Откроем https://music.yandex.ru/home в инкогнито
Шаг 2 Нажимаем на крестик для закрытия страницы онбординга

Привет, Хабр! Меня зовут Иван, я в тестировании более 2-х лет. Начинал свой путь с курса Яндекс Практикума (подробнее в тг канале). Продолжаем разбирать вопросы и технические задания на собеседовании QA manual. Перед прочтением этой статьи рекомендую ознакомиться с моей предыдущей работой Какие вопросы я задаю на собеседовании QA Junior+

3. Протестировать карандаш для различных видов тестирования.

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

- Требований нет.

1 шаг. Исследовательское тестирование на основе косвенных требований.

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

✏️ Форма влияет на функционал и на удобство использования. Круглый скатится со стола, с гранями не должен "резать" руку, три грани слишком крупно и подойдет не для всех пользователей. Есть ли ластик на карандаше и выполняет он свою прямую функцию?

✏️ Цвет не влияет на функционал (говорим не про цвет графита, а про визуальную часть). Цвет не должен нести лишнюю информацию, кроме как визуального акцента или бренда компании;

✏️ Запах не должен быть специфичным;

Привет Хабр! Меня зовут Иван, сегодня поговорим о вопросах на собеседованиях Джуну+ (от 6 месяцев работы) и узнаем как ответить на них не как ChatGPT. Я как инженер по ручному и автоматизированному тестированию провожу собеседования на роль Junior+ QA (с дальнейшим ростом в автоматизаторы). Делюсь своим списком вопросов и ответов, которые я ожидаю услышать.

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

База для Junior QA

1. Что такое тестирование?

Сравнение ожидаемого результата с фактическим результатом ПО. Тестирование это не поиск багов!

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

Всем привет, меня зовут Иван, я инженер по тестированию (Manual and Automation). В ремесле более 2-х лет. В этой статье мы рассмотрим методы черного, серого и белого ящиков, а так же как JavaScript может быть использован для перехода от метода черного ящика к серому и белому.

Со мной сегодня senior фронтенд-разработчик, Алексей - специалист с большим опытом, он научит вас дебажить код в Devtools и ставить точку останова. Даст советы для QA как стать самостоятельнее и определять ошибки в коде с базовыми знаниями JavaScript. Ссылка на канал Алексея "Рассказ фронтендера"

Для чего нам нужна точка останова и как это связано с методами тестирования?

Что такое метод тестирования? Это метод подхода к тестированию: можно подойти к тестированию закрытыми глазами с тест-дизайном "Исследовательское тестирование", а можно изучить, что происходит под капотом и уже как механик капаться в грязи в чужом коде. Точка останова это один из гаечных ключей, которые помогут проверить код и его реализацию в проекте.

Всем привет, это моя первая статья по тестированию. До этого я писал от лица Scrum-мастера, а теперь уже и от лица QA. В тестировании я уже более 2-х лет. Работал на двух проектах одновременно, и было супер весело менять проект на протяжении дня: утром ты тестируешь веб-сервис, а вечером со студентами делаешь тест-план по мобильному приложению. Не жизнь, а сказка!

Из названия мы с вами понимаем, что тема статьи интересна и, как воздух, необходима.

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

Не будем петь серенады, как это сложно, и приступим к делу.

Вас посвящают в суть проекта, и главный шаг - уточнить у аналитика или того героя, кто выполняет эту роль, "Есть какая-нить дока?" (далее - спецификация).

Какая может быть спецификация на проекте? Будьте внимательны, я не использую термин документация, потому-что дока - это текстовый формат, а в виде спецификации может выступать:

1) документация; обновленная в последний раз в 90-х

2) макеты; вообще не похожи на прод

3) тикеты в Jira; обычно там один заголовок, но верим в чудо

4) user-story;

5) тест-кейсы, чек-листы; если был тестировщик до

6) звонок с владельцем продукта; Product owner

Ретроспектива. Новогоднее ретро. Как погрузить команду в Christmas mood?

Всем привет, это вторая часть статей о готовых шаблонах проведения ретроспектив. Эта статья посвящена новогодней рестроспективе. Новый год, декабрь месяц, подарки, глинтвейн, сугробы, «Гарри Поттер», «Один дома», селёдка под шубой…

Всё не перечислить, да и не нужно, ведь наша ретроспектива определит ваши планы на декабрь, январь и февраль. Да-да, это чистая правда.

Как провести незабываемую ретроспективу с нуля? Нескучные ретроспективы. Ретроспектива, которую мы заслужили.

Часть 1 Packman. Пиксельное ретро.

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

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

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