Практикум корректности
Есть ряд слов и фраз, употребление которых в описании багов, в том числе и исправленных, не уместно. Эти слова могут быть восприняты пользователем продукта двояко. Сегодня покажу на конкретных примерах неоднозначность слова "корректно".
Для тестирования возьмём Release Notes для продукта ClearSQL 7.1.2.181.
Пример 1
Окно "Select Code Review Rules to Suppress Violations" можно открыть из области редактора кода через одноимённый пункт контекстного меню. Оно является дочерним только для редактора кода, но модальным для основного окна приложения. С точки зрения usability возможность сдвига вспомогательного окна и последующее его переоткрытие на том же самом месте - это удобство и очевидное ожидание пользователя. Но с программистской стороны имеется просчёт - позиция и размер дочернего окна не зависит от координат родительского. Если пользователь работает на нескольких мониторах, то рабочее пространство продукта не ограничивается координатами основного окна приложения, что часто приводит к проблемам при открытии приложения после отключения одного из мониторов: окно фактически открывается, но не доступно в видимой области активных экранов.
В предыдущей версии окно переоткрывалось центрировано по активному монитору, а размер устанавливался ни последний пользовательский, ни минимальный стандартный (интерфейсные приложения компании Conquest Software Solutions разрабатываются в Delphi и используют настройки по-умолчанию в среде разработки от Embarcadero), к тому же уменьшение размеров окна не имело предела.
Ошибками тех-писателя, составлявшего Release Notes, считаются:
- отнесение данного пункта к модулю "Code Analyzer Options", поскольку окно "Select Code Review Rules to Suppress Violations" является самостоятельным и всего лишь клоном части окна "Code Analyzer Options";
- употребление слова "restart" вместо "reopening", поскольку имеется ввиду переоткрытие окна, а не перезапуск приложения.
Таким образом пользователь остаётся в недоумении о "корректности" правки:
- впервые появившись в продукте окно открывалось каждый раз центрировано по основному окну приложения, поэтому новое позиционирование по координатам монитора может исказить ожидания пользователя;
- впервые появившись в продукте окно открывалось каждый раз одного и того же размера, установленного программистом, поэтому восстановление "пользовательского" размера при каждом переоткрытии окна может быть воспринято и как удобство, и как неожиданность;
- не уточнённое "restart" относительно переоткрытия окна или приложения вводит в заблуждение пользователя.
Если программист не счёл нужным ориентироваться в разработке новой фичи на чит-лист, то это действительно баг. А если первоначальное поведение было задумано разработчиком, то подобный пункт в Release Notes стоит оформлять улучшением интерфейса, а не багом.
В предыдущей версии окно переоткрывалось центрировано по активному монитору, а размер устанавливался ни последний пользовательский, ни минимальный стандартный (интерфейсные приложения компании Conquest Software Solutions разрабатываются в Delphi и используют настройки по-умолчанию в среде разработки от Embarcadero), к тому же уменьшение размеров окна не имело предела.
Ошибками тех-писателя, составлявшего Release Notes, считаются:
- отнесение данного пункта к модулю "Code Analyzer Options", поскольку окно "Select Code Review Rules to Suppress Violations" является самостоятельным и всего лишь клоном части окна "Code Analyzer Options";
- употребление слова "restart" вместо "reopening", поскольку имеется ввиду переоткрытие окна, а не перезапуск приложения.
Таким образом пользователь остаётся в недоумении о "корректности" правки:
- впервые появившись в продукте окно открывалось каждый раз центрировано по основному окну приложения, поэтому новое позиционирование по координатам монитора может исказить ожидания пользователя;
- впервые появившись в продукте окно открывалось каждый раз одного и того же размера, установленного программистом, поэтому восстановление "пользовательского" размера при каждом переоткрытии окна может быть воспринято и как удобство, и как неожиданность;
- не уточнённое "restart" относительно переоткрытия окна или приложения вводит в заблуждение пользователя.
Если программист не счёл нужным ориентироваться в разработке новой фичи на чит-лист, то это действительно баг. А если первоначальное поведение было задумано разработчиком, то подобный пункт в Release Notes стоит оформлять улучшением интерфейса, а не багом.
Пример 2
Сразу в трёх пунктах блока Call Tree диаграмм использовано слово "корректно". Но, как и в предыдущем примере, правильность исправлений не может быть единственно объективной как для заказчика, так и для исполнителя, поскольку продукты в Conquest Software Solutions разрабатываются по методу Research&Develop, а общепринятых стандартов для отображения Call Tree никто не вводил.
Экспорт диаграмм не изменился по сравнению с предыдущей версией продукта, кроме излишнего формирования map-файла. Но об этом имеется отдельный пункт в Release Notes. Так что пункт об имени экспортируемого файла можно считать очковтирательством в списке исправленных багов. Но не будем столь строго относится к некомпетентному тех-писателю, а попросим разработчиков уточнить исправления. Возможно, что-то было подправлено для особых типов объектов или только в одном из множества типов экспорта. Ещё возможный вариант правки - иной тип диаграмм, а тех-писатель опечатался в имени блока Release Notes. Либо правка на самом деле была в пред-предыдущей версии, а про баг написали только в этот раз.
Во втором и третьем пунктах говорится о Call Tree диаграммах, автоматически открываемых из CRUD матриц по клику на имена связанных объектов. Согласно чит-листу для тестирования новой фичи приоритетными параметрами статуса, размера и позиции окна считаются пользовательские. То есть наиболее ожидаемое поведение - это когда окно открывается на том же месте и того же размера, каким оно было закрыто в текущей сессии приложения и после перезапуска приложения. А центрирование дочернего окна основывается на координатах родительского. Поэтому, если фикс о центрировании актуален лишь в случае показа всех объектов на одной лишь закладке CRUD2, то фикс статуса окна легенд слишком сомнителен. Дело в том, что CRUD1 матрицы формируются в разрезе скрипта и для Call Tree диаграмм разворачивается дополнительная панель, а не модальное окно. При этом о центрировании панели не может быть и речи, а легенда диаграммы Call Tree скорее всего переформировывается из-за включенной опции "Preferences / Project Analysis / Keep diagram/matrix local settings".
Пример 3
В предыдущих выпусках копирование диаграмм в память вообще не происходило, если Flowchart или Call Tree были сформированы в формате GIF. Поэтому приписка "correctly" в данном случае просто излишняя, ведь никаких стандартов по копированию картинок в память у ConquestSS нет, а дополнительные индикаторы операционной системы и оперативной памяти в приложение не встроены.
Пример 4
В блоке Отчёта Проекта нашлось сразу два пункта с запрещённым словом.
Для подтверждения, а вернее доказательства от противного первого пункта сформируем проект с диаграммами в предыдущем билде и текущем. На основе диаграмм всех форматов сформируем отчёты аналогичных проектов в обеих версиях. Проверяя кликабельность из диаграмм в код в рамках отчётов, получаем возможность позиционирования кода из GIF, JPEG, PNG диаграмм в текст кода в рамках проекта из предыдущей версии продукта. А в текущей версии позиционирование перестало выполняться для перечисленных форматов, но стало благополучно выполняться для SVG формата. Так сказать "за уши притянуть" корректность к описанной правке фактически невозможно. Поэтому употребление недопустимого слова не только искажает смысл, а просто напросто противоречит элементарной логике как пользователя, так и разработчика.
Для второго пункта аналогично генерим отчёты, выбирая одинаковые параметры фильтров и группировки для данных на Summary страницах отчётов. Отметим, что параметры касаются только двух таблиц на Summary страницах отчёта всех уровней (проект/папка/скрипт). После сравнения отчётов получается, что раньше данные в таблице "Top Violated Code Review Rules" фильтровались по условию из интерфейса закладки "Project Analyzer Results / Summary", а в новой версии приложения группировка применяется из настроек Project Report Assistant, но никаких пометок в самом отчёте о применённой группировке нет. Так в чём же "корректность" правки? С таблицей "Code Metrics" дела обстоят немного лучше, так как в заголовке таблицы и ранее имелась информация о фактически применённых группировке и фильтрации. Но о корректности правки стоило говорить намного раньше, когда переименовали опцию "Project Report Assistant / New Report / Summary Options / Panels Size and Position / As in the Analyzer View Summary Page". Стоит напомнить, что группировка и фильтрация двух таблиц устанавливаются в трёх-пяти местах - в уже упомянутом окне Project Report Assistant и его аналоге для Job and Schedule Manager, на закладке "Project Analyzer Results / Summary" и дублируются в Preferences, на "Preferences (Job) / Export" странице настроек для автоматического экспорта. Какие из этих настроек стоит считать эталонными, какова территория их применения и отображения - ответы на перечисленные вопросы не очевидны и их невозможно найти в Online Help продукта. Значит очередной пример подтверждает запрет на использование слова "correctly" в описании фиксов.
Пример 5
Хотя в примере и видны два пункта, но на самом деле они об одном и том же. Пользователю заметно лишь изменение в подсчёте объёма отчёта, но не одного файла, как это сказано, а всех составляющих html-документ. Вероятно программист изменил структуру хранения информации об отчётах, а тех-писатель не смог пояснить внутренних процессов. На самом деле вместо приписывания одного слова "correctly" необходимо было перефразировать баг в улучшение или хотя бы переименовать file в document для большей правдивости. Отсутствие достаточной коммуникации между тех-писателем и разработчиками, низкая квалификация и нежелание повышать уровень знаний замещаются шаблонной отпиской, которая оборачивается для пользователя непониманием и последующим недоверием к поставщику продукта.
Пример 6
Обновление дерева файловой системы после импорта визуально ничем не изменилось в новой версии. Возможно что-то было оптимизировано в алгоритме или коде. И чтобы скрыть отсутствие обмена информацией в команде разработки тех-писатель вынужден заполнять свои пробелы в знаниях пустословием.
Пример 7
Визуально фикс заключается в стабилизации позиционирования на скриптах в дереве проекта. Неумение выразить техническое изменение доступным для пользователя языком - это прямое несоответствие занимаемой должности тех-писателем. А в итоге страдает конечный пользователь, который перестаёт доверять компании, фальсифицирующей правки.
Пример 8
Элементарный smoke-test не может показать произведённых изменений. Поэтому можно заключить, что фикс касается некоторого частного случая, для описания которого у специалистов не хватило профессионализма. В результате пользователь вполне имеет право считать, что никакого исправления не было.
Пример 9
Данный случай вполне обошёлся бы просто без слова "correctly". Поскольку активация окна не подразумевает вариаций. Или же разработчики компании Conquest Software Solutions ввели стандарт активации окна без предупреждений или подтверждений? Не очень похоже на них, так как в ClearSQL и других их продуктах очень много мест с излишними подтверждениями. Так почему же по их меркам в этом случае смена рабочей области происходит автоматически и без пользовательского согласия?
Пример 10
В этом примере к одному запрещённому слову добавили ещё и always, забыв постулат тестировщиков о порождении двух новых багов на основе одного фикса. Но это не удивительно, поскольку шеф группы разработки любит добавлять к описанию задачи фразу "исправить везде". Это следствие неумения и нежелания применять декомпозицию и конкретизировать планирование.
По существу правки. Можно ли считать правильным обрезание имени подпрограммы? В предыдущем билде имелась приставка из имени объектного типа, которая позволяла не теряться в списке подпрограмм таблицы Code Metrics, особенно на закладке Summary. Но половинчато всё же фикс был - overloaded подпрограммы теперь показываются с цифровым индексом, но без перечисления параметров. В чём корректность правки? Вопрос весьма не риторический.
Комментариев нет:
Отправить комментарий