Тестирование из первых рук

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

Абстрактный пример как это происходит:

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

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

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

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

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

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

Разработчик переносит кнопку, тестировщик успешно тестирует согласно требованиям менеджера.

Продукт попадает к заказчику и он недоволен. Просит перенести кнопку в верхний левый угол.

Менеджер передает задачу разработчику, то снова переносит кнопку, тестировщик снова тестирует и продукт приобретает требуемый заказчиком формат.

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

Эту историю можно сделать еще интереснее, добавив автоматизацию тестирования и соответственно обновление тестов несколько раз.

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

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

Ошибки, вызываемые подразумеваемым будут, но их можно минимировать, иначе будет как в анекдоте:

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

Недавно понадобилось на Windows 10 распознать текст с изображения.

Нашел два оффлайн решения:

1. Microsoft OneNote:
- открыть документ
- вставить изображение
- правая клавиша мыши
- распознать текст

2. PDF24
https://tools.pdf24.org/en/
Лицензия позволяет использовать тул как в личных так и профессиональных целях
- использовать сервис PDF OCR
- сохранить pdf документ с распознанным текстом
- открыть его
- скопировать текст

Для моей задачи PDF24 оказался более эффективным, чем Microsoft OneNote.

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

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

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

Актуальный список каналов:

https://t.me/addlist/PNmSaWa9ktw2YjRi

В дискуссиях на тему 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

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

Можно вполне использовать в качестве девиза 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 в зависимости от ошибки, пункты типичны для ошибок бекэнда в первую очередь.

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

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

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

Один из терминов, с которым можно встретиться, это идемпотетность. Этот термин предложил американский математик Бенджамин Пирс.

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

Сначала пара бытовых примеров:
1. Многократное нажатие кнопки закрытия багажника на ключе автомобиля не меняет состояния так сказать закрытости багажника. То есть эта операция идемпотентна.
2. Схожий пример, это нажатие кнопки светофора - при первом нажатии отправляется сигнал переключения на зеленый свет, повторные нажатия не приводят к иному результату, эта операция тоже идемпотентна.
3. Противоположный пример, добавление соли приготовлении блюда. Каждое добавление соли будет изменять состояние блюда, то есть эту операцию нельзя назвать идемпотентной.

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

1. GET запросы: Получение информации через GET запрос всегда идемпотентно, так как он не изменяет состояние сервера.

2. PUT запросы: Этот запрос используется для обновления ресурса на сервере. Если вы отправите PUT запрос с теми же данными несколько раз, это не повлияет на состояние ресурса на сервере. Например:

PUT /users/123
   {
       "name": "John",
       "age": 30
   }
   

Если этот запрос будет выполнен несколько раз, информация о пользователе с идентификатором 123 будет обновлена до "John", 30, но состояние сервера не изменится.

3. DELETE запросы: Удаление ресурса с помощью DELETE запроса также является идемпотентной операцией. Если вы отправите DELETE запрос для удаления ресурса, его повторное выполнение не изменит состояние сервера. Например:

DELETE /users/123

Если этот запрос будет выполнен несколько раз, ресурс с идентификатором 123 будет удален, и состояние сервера не изменится.

4. POST не считается идемпотентным, так как может использоваться для создания новых ресурсов.

Однако часто возникает потребность делать POST запрос идемпотентным принудительно, так как повторное выполнение POST запроса с теми же данными может привести к созданию дубликата ресурса или ошибке, если ресурс уже существует, например, запрос create user имеет смысл сделать идемпотентым для того, чтобы избежать дубликатов.

Резюме и некоторые другие документы создаю с использованием Latex. Иногда использую готовые темплейты, которые подгоняю под свои нужды. На этом сайте есть, например, бесплатная подборка темплейтов для резюме: https://de.overleaf.com/latex/templates/tagged/cv

Уже упоминал выше, что chatGPT периодически начинает ходить по кругу, то есть выдает один и тот же ответ в определенных ситуациях.

Нашел способ, как можно это обойти: прошу предложить сразу несколько вариантов.

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

chatGPT начал упорно выдавать только один перевод, игнорируя замечания о том, что это не то слово, которое я ищу. В итоге сформулировал запрос следующим образом:
дай 10 вариантов перевода слова и сразу нашёл искомое значение.

На тему поиска ментора. Сам периодически выступаю в роли ментора, был и менти в свое время, например брал консультации на тему Spring и test driven development (tdd).

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

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

Запись сегодняшнего разговора https://youtu.be/0y-1c9x42zI