Состою в группе менторов и тех, кто ведет собственные telegram каналы. Группа периодически делает ревью существующих каналов с целью составить список, который можно рекомендовать всем интересующимся QA.

Некоторые критерии попадания в список:
- канал регулярно обновляется и не заброшен
- содержит авторский контент
- сконцентрирован на QA и IT темах

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

Актуальный список каналов:https://t.me/addlist/PNmSaWa9ktw2YjRi

Telegram

QA Лучшее

Anton Duenin invites you to add the folder “QA Лучшее”, which includes 40 chats.

В дискуссиях на тему soft skills периодически упоминают умение просить помощи у коллег.

В случае сложностей возникает дилемма, как быть? Бежать за помощью немедленно? Пробовать решить проблему самому?

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

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

Немного Java:

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

Вызов такого метода может выглядеть следующим образом:

userCreator.createUser("John", "Marie", "Peter");

А реализация так:

public class UserCreator { public void createUser(String... names) { // Создание пользователей на основе списка имен for (String name : names) { // Создать нового пользователя с именем "name" User user = new User(name); } } }

Обратить внимание хочу на String... names: Это аргумент метода. String... означает, что метод принимает переменное количество аргументов типа String и позволяет передавать любое количество аргументов типа String при вызове метода. Они будут доступны в методе как массив String[] names.

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

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

Чтобы как-то проверить и/или отсеять подобные вещи, есть смысл поискать альтернативные источники, для проверки новых идей.

На тему AI и генерирования изображений. Многие сервисы являются условно-бесплатными с соответствующими ограничениями.

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

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

Я использую идею breadcrumbs в названии багов, например:

Login page: login mask: enter password: validation doesn’t workПодобный формат позволяет коротко и точно описать проблему, в случае с простыми багами достаточно подобного названия и видео и/или скрина в описании, кроме этого подобный формат представляет по сути набор ключевых слов, эти слова могут использоваться для поиска багов по названию.

На тему подхода к работе с user story в плане отношения к деталям и того как детали могут влиять на конечный результат/ответ, примерно с 0:45 до 1:50

https://youtu.be/q3QXkjjD2i4?si=sqWLRqo2eYGOsox5

YouTube

Тест (отрывок из фильма "Феномен")

Доверяй, но проверяй.

Можно вполне использовать в качестве девиза QA.

Английский перевод: trust, but verify

Еще небольшой комментарий на тему баг-репортов. Вторым пунктом структуры может быть precondition. Я выделяю precondition в отдельный пункт в-основном тогда, когда он содержит несколько подпунктов, в противном случае записываю precondition в виде первых шагов в пункте how to reproduce.

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

Не читают по ряду причин:
Одна из них заключается в том, что многие быстро пробегают глазами и по тексту и выделяют для себя самый главный пункт: how to reproduce.
Другая причина, ни на одном проекте, где я работал, не было унифицированной структуры баг-репортов, соответственно разработчик не заточен на работу с багом в определенном порядке.

На тему баг-репортов, практически на всех проектах работаю с jira, ниже более-менее стандартная структура моего бага, то, что идет в description:

1. Environment - все доступные данные о версиях: браузер, приложение и тд
2. How to reproduce - описание, скрины, видео. Иногда все вместе, иногда хватает скринов или видео. Иногда прикладываю скрипты для генерирования тестовых данных.
3. Expected: описание, иногда, если есть скрин
4. Actual: описание. Иногда этот пункт описываю буквально на скрине со стрелочками, рамками и тд
5. Issue details: логи, информация из DevTools, в первую очередь из console или network, мои наблюдения и результаты предварительного анализа, указания на схожие баги и тд
6. Possible solutions | improvements: описание возможного решения проблемы. Обычно речь не о технических решениях, а об изменении функционала

1,2,3,4 присутствуют практически всегда, иногда 3 и 4 очевидны на основании скринов: ошибки layout или другие подобные вещи.

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

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

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