Вопрос QA — как вы описываете ошибки?

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

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

В отличие от предложений языка естественного, описания ошибок куда менее разнообразны. А следовательно можно их будет составлять автоматически — прямо на этапе обнаружения. Собственно говоря, сама программа, в режиме исполнения тестов самопроверки, или когда вы вручную ее тестируете, может вам в особом окне показывать с помощью предложенного ранее языка ключевых слов что именно происходит (как синхронно так и асинхронно)

Вот есть же у программистов комментарии в описании API ? Собственно javadoc на основе комментариев работает.

А теперь представьте, что и вы — тестировщики — укажете, возле тестов, описания на этом самом формализованном языке вызова/показа иконок.

Таким образом, когда программа не пройдет тест — описание сразу же высветится и останется только кликнуть по нему, чтобы добавить при помощи плагина в Jira или Bugzilla

Сойдет за стоящую идею или я чего-то не додумал?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1) Summary
2) Preconditions
3) Steps to reproduce
4) Expected result
5) Actual result
6) Версия продукта, платформа, ОС, версии продуктов с чем связан кейс, полное описание окружения
7) Логи
8) Скриншоты, видео
9) Severity, Priority

Все поля обязательные или it depends?

Severity, Priority

как определяете?

1,3,4,5,6,9 — обязательные. 6 поле варьируется в зависимости от продукта.
Severity и Priority ка каждом проекте по-своему определяются, в зависимости от влияния на продукт, проект, бизнес.

до пятницы подождать не мог?

В обсужденнии много лулзов (что хорошо), но маловато конструктива. Исправляю :-)
Идея не реализуема. Проблемы:

1. «Полнота языка». Компьютерные программы как правило описывают реальный мир. Следовательно, для описания сбоя без существенной потери смысла нужно примерно то же количество слов, что и в живом современном языке минус синонимы, идиомы и прочее. Итого у нас получится что-то вроде en.wikipedia.org/wiki/Special_English или en.wikipedia.org/wiki/Basic_English. Т.е. 850 или 1500 слов. плюс IT-специфические термины. В итоге, получим словарный запас среднего тестировщика в мировой IT индустрии.

2. Падение автотеста однозначно не идетифицируется без вмешательства человека. Это значит, что баг-репорт будет содержать только сырую и непроверенную информацию. В результате бОльшея часть баг-репортов будут невалидным и только отвлекать девов, порождать недоверие к результатам тестов. Почему нельзя установить истинную причину автоматически см. en.wikipedia.org/...​_law_of_requisite_variety

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

4. Избыточность/неполнота общего формата описания ворк-продактов тестирования (в т.ч. багов). Даже ISTQB признает, что нет золотого стандарта и что тестирование всегда контекстно-зависимо. То, что хорошо для Аэроспейс индустрии будет злом при создании веб-магазинчика по шаблону. И наоборот.

"

Таким образом, когда программа не пройдет тест — описание сразу же высветится и останется только кликнуть по нему, чтобы добавить при помощи плагина в Jira или Bugzilla

" — да здравствует Тест менеджмент тулз .... )

google в помощь ....
SAMPLE BUG REPORT
Bug Name: Application crash on clicking the SAVE button while creating a new user.
Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug)
Area Path: USERS menu > New Users
Build Number: Version Number 5.0.1
Severity: HIGH (High/Medium/Low) or 1
Priority: HIGH (High/Medium/Low) or 1
Assigned to: Developer-X
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Windows 2003/SQL Server 2005

Description:
Application crash on clicking the SAVE button while creating a new
the user, hence unable to create a new user in the application.

Steps To Reproduce:
1) Login into the application
2) Navigate to the Users Menu > New User
3) Filled all the user information fields
4) Clicked on the ‘Save’ button
5) Seen an error page „ORA1090 Exception: Insert values Error...”
6) See the attached logs for more information (Attach more logs related to bug..IF any)
7) And also see the attached screenshot of the error page.

Expected result: On clicking SAVE button, should be prompted to a success message „New User has been created successfully”.

(Attach ‘application crash’ screenshot. IF any)

Больше стандартов богу стандартов.

описания на этом самом формализованном языке

Такий вже є Behat:

Feature: Listing command
  In order to change the structure of the folder I am currently in
  As a UNIX user
  I need to be able see the currently available files and folders there

  Scenario: Listing two files in a directory
    Given I am in a directory "test"
    And I have a file named "foo"
    And I have a file named "bar"
    When I run "ls"
    Then I should get:
      """
      bar
      foo
      """

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

Словарь предметной области или семантическое ядро тут составляется?
    /**
     * @Given /^I am in a directory "([^"]*)"$/
     */
    public function iAmInADirectory($argument1)
    {
        throw new PendingException();
    }

Ти запускаєш Behat-тест, який написаний на Gherkin, і для кожної інструкції з тесту має бути реалізація, почитай детально про це, можливо саме це ти хотів створити

И я веду речь только о том, где случился баг. Это координаты бага и они должны быть задаваемыми. Например, если представить программу в виде графа. То будут узлы — координаты. Вот их именовать. И потом работать с ними как раз. Хотя есть еще и такое понятие как уровни абстракции — одним одно нужно, другим другое. Но главное — все это может быть компактифицировано, строго формализовано. Написанием языка. Просто нужно писать языки для каждого проекта. Вот суть идеи. И если вы вокруг посмотрите — так это ж и делают! Только называют по другому — и ленятся писать свое. Чужое выкупают.

мені цілком вистачає тестів і логів, тести показують де помилка при розробці, а логи де помилка коли код опрацьовує реальні дані

Давай предложу идею покруче: писать код сразу без багов

Баг — отсутствие реализации обработки некоторой ситуации? Ну, нельзя же написать код для обработки всего? Вообще всех возможных ситуаций с данным софтом? Это значит, что код всегда будет с багами. А вот заставить девелоперов еще и прописывать именования процессов, происходящих, когда код исполняется — это легко могут надсмотрщики на галерах сделать. И заставят. Вот увидишь. А потом — прикинь — визуальная отладка — смотришь как код — не в отладчике — построчно — а на третьем мониторе кубики туда сюда гоняет — процессы друг другу цветные данные-потоки перегоняют — картинка оживет. Великое Айти настанет для всех. РиалТайм — а не как сейчас — с помощью ноде и вебпака коды реакта обновляются.

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

Почему нельзя? Можно.

Это значит, что код всегда будет с багами.

Не значит.

А вот заставить девелоперов еще и прописывать именования процессов, происходящих

Что?

а на третьем мониторе кубики туда сюда гоняет

less debug.log
и зажать Page Down. Почувствуй себя Нео..

Фотошоп достиг своего предела, а css нет. Кому теперь нужен дизайн в фотошопе сначала, да еще послойный? Уже можно начинать сразу ваять адаптивный css. Сплошная экономия средств. А за эти деньги как раз можно нанять писателей — пусть составляют единое семантическое ядро на проект, которым все будут пользоваться и для всего, что проекта касается: документации, описания багов, сео, комментариев, титлы, идентификаторы. Все — строго формализовано в рамках предметной области проекта будет. А значит будет меньше места для свободы творчества и других извращений.

Все знают как минимум 42 способа написания кода без багов — но почему то все пользуються 43м

Сойдет за стоящую идею или я чего-то не додумал?

Если любишь БДСМ, идея что надо. Вот прям озвучиваешь мастеру — и плёточка просто запоёт, часа на три, без кофе-брейка

marker.io/...​blog/bug-report-template

Нужно еще больше стандартов =D

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

P.S. все уже давно сделано до нас. и стандартов так же много.

Универсального нет. Вот введут его и все остальные враз использовать перестанут.

Ситуация: Существует 14 конкурирующих стандартов

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

Вскоре
Ситуация: Существует 15 конкурирующих стандартов

Стандарт вказати 1) expected, 2) actual, 3) steps to reproduce. Також нотатки і якомога більше інфи, якщо є проблеми із відтворенням, нотатки про відмінність expected від actual, якщо це не очевидно.

любую ошибку приложения описать несколькими ключевыми словами.

ой все

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

Я не думаю, що це можливо. Unit та integration тести вже є на чому писати, для репортів людську мову, будь-ласка. Репорти не формалізувати, там наркоманія ще та буває. Спочатку думаєш, що тестувальник наркоман, але він тобі дуже переконливо пояснює, що ні, то ти. Плюс ще треба вміти не надто подробно але і не надто повно написати репорт. Плюс вибачте, ще одна мова? Впровадити ще одну мову — ви не уявляєте яка морока. І це закид, що всі інші дурні і не побачили можливості, такі закиди треба дуже гарно обгрунтовувати, інакше ніхто не буде вас серйозно сприймати.

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

Ще раз, як словник допоможе? Без вашого словнику слова можна фігачити де треба і які треба. Як це і роблять зазвичай.

Да неужели вы ни разу собственный интерпретатор не писали? Зачем по вашему формализованные языки делают? Не для того, чтобы наизусть учить. А чтобы была возможность автоматической проверки соответствия написанного DTD. Описания демонтируются на слова и по словарю эти слова ищутся если находятся то все ок. Иначе в лог падает предупреждение — нетути такого слова в нашей предметной области. Хотите добавить? Так, кстати, дополняемый словарь формируется. Я же написал: никакой самодеятельности больше не будет при правильно строгом подходе. А не шалтай болтай как сейчас у многих.

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

Спасибо. Отличный материал. Изучаю.

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

Я джва года жду такой язык

Можно перейти от чересчур подробных логов к такому языку
....
log("now in module p1″)
log("user click at x,y")
log("now at module p2″)
log("show dialog")
log("user input: 12w")
log("now in validation module")
log("error: user input not valid")
log("now in expert help module")
....
Ну предположим накопили историю логов. Потом отобрали строки с ошибками.
И воспроизвели в проигрывателе. При этом можно упаковывать утрамбовывать одинаковые по содержанию блоки.
Такое получается тестирование альфа и бета релизов. Ну а задача тестировщиков логи написать. Формализованные. Согласно dictionary.

Скриншот или снятое видео. Это самое лучшее описание.

Особенно на паблик, фронтальной камерой

Так я как раз об этом. Сначала мы составляем тест план, потом проходим тест кейсы с разными тестовыми наборами. И все это снимаем на видео. Вот только еще у нас включен плагин. Плагин отображает визуальный (т.е. легко распознаваемый даже с видео) маркер. Он нам потом пригодится. А пока мы просто тестируем и замечаем баги. Как только мы заметили баг мы жмем кнопку «БАГ» это нам позволяет отделить тонны нормального прохождения тестов от падающих тестов. А потом мы уже более тщательно начинаем работать уже исключительно с бажными областями. А визуальные маркеры очень сильно нам помогают при этом. Так как могут рассказать очень многое о ситуации в которой тестировщик обнаружил баг.
Вот так можно отделить выполнение тест-кейсов от собственно описания обнаруженных багов.
Но для этого нужно, чтобы у плагина были данные, которые он будет отображать, нужна связь плагина и выполняемых процессов.

Підписатись на коментарі