Вхід і реєстрація
Розробка · 27 травня 2019, 17:45 1977
Олег Дорожко, Програміст фрилансер, у минулому адміністратор системи, 48 років

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

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

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

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

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

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

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

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

Теми: QA
👍ПодобаєтьсяСподобалось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
Olga Тостер с опытом 28.05.2019 14:48

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

Відповісти
Підтримати
Yuriy Kolyadkin 28.05.2019 14:49

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

Severity, Priority

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

Відповісти
Підтримати
Olga
Olga Тостер с опытом 28.05.2019 15:26

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

Відповісти
Підтримати
Yuriy Kolyadkin
Roman Tretyak QA Automation в Ciklum 28.05.2019 13:23

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

Відповісти
Підтримати
Luci 28.05.2019 13:06

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

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 признает, что нет золотого стандарта и что тестирование всегда контекстно-зависимо. То, что хорошо для Аэроспейс индустрии будет злом при создании веб-магазинчика по шаблону. И наоборот.

Відповісти
Підтримати
Eugene Stogniy 28.05.2019 10:24

"

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

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

Відповісти
Підтримати
Eugene Stogniy 28.05.2019 10:22

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)

Відповісти
Підтримати
Котэ 28.05.2019 01:22

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

Відповісти
Підтримати
Ярослав Характерник Golang Developer в DocHQ 28.05.2019 00:37
описания на этом самом формализованном языке

Такий вже є 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
      """
Відповісти
Підтримати
Олег Дорожко 28.05.2019 00:41

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

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

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

Відповісти
Підтримати
Олег Дорожко
Олег Дорожко 28.05.2019 00:46

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

Відповісти
Підтримати
Ярослав Характерник
Ярослав Характерник Golang Developer в DocHQ 28.05.2019 01:18

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

Відповісти
Підтримати
Олег Дорожко
Олексій Пєніє 27.05.2019 21:24

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

Відповісти
Підтримати
Олег Дорожко 27.05.2019 21:46

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

Відповісти
Підтримати
Олексій Пєніє
Александр Шевченко 27.05.2019 23:46
Ну, нельзя же написать код для обработки всего?

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

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

Не значит.

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

Что?

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

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

Відповісти
Підтримати
Олег Дорожко
Олег Дорожко 28.05.2019 00:02

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

Відповісти
Підтримати
Александр Шевченко
Eugene Stogniy 28.05.2019 10:18

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 27.05.2019 21:24
Сойдет за стоящую идею или я чего-то не додумал?

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

Відповісти
Підтримати
S S 27.05.2019 19:25

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

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

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

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

Відповісти
Підтримати
Олег Дорожко 27.05.2019 19:27

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

Відповісти
Підтримати
S S
Pavlo Pakholka Software Engineer в Bolt 28.05.2019 10:25

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

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

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

Відповісти
Підтримати
Олег Дорожко
De Money 27.05.2019 18:32

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

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

ой все

Відповісти
Підтримати
Олег Дорожко 27.05.2019 18:37

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

Відповісти
Підтримати
De Money
De Money 27.05.2019 19:04

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

Відповісти
Підтримати
Олег Дорожко
Олег Дорожко 27.05.2019 19:14

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

Відповісти
Підтримати
De Money
De Money 28.05.2019 00:19

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

Відповісти
Підтримати
Олег Дорожко
Олег Дорожко 28.05.2019 00:31

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

Відповісти
Підтримати
De Money
Олег Дорожко 28.05.2019 00:37

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

Відповісти
Підтримати
De Money
Олег Дорожко 27.05.2019 18:38

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

Відповісти
Підтримати
Sergii Voloshyn
Олег Дорожко 27.05.2019 19:18

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

Відповісти
Підтримати
Sergii Voloshyn
Олександр Кваско Test Automation 27.05.2019 18:23

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

Відповісти
Підтримати
Олег Дорожко 27.05.2019 18:59

Можно перейти от чересчур подробных логов к такому языку
....
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.

Відповісти
Підтримати
Олександр Кваско
Дима Дима 27.05.2019 18:20

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

Відповісти
Підтримати
Олексій Пєніє 28.05.2019 21:30

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

Відповісти
Підтримати
Дима Дима
Олег Дорожко 28.05.2019 21:51

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

Відповісти
Підтримати
Олексій Пєніє

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.