Ограниченность

Тестировщики в своей работе очень часто встречаются с ограничениями. Прописанные ограничения являются стандартами, на которые равняются результаты тестов. Начинающие соратники среди первоочередных задач называют проверки граничных значений. Недостаток ограничений всегда можно оформить в предложение.
Про то где и какие уместны проверки ограничений вполне доступным языком рассказала и показала лектор курса начинающих тестировщиков Нина Агеева (тренер курса «Погружение в тестирование. Jedi Point») в видео-уроках. 
К чему может привести отсутствие достаточных ограничений упомянуто на примерах в форуме тестировщиков.
А вчера в магазине случилась беда у кассира с покупателем из-за отсутствия ограничения. Программное обеспечение касс не отображает остатки на складе, поэтому кассир может проставить количество, превышающее имеющиеся и покупаемые позиции. Когда покупатель берёт несколько одинаковых мелких пакетиков, кассир может сканировать каждый из них, либо отсканировать один, просчитать вручную фактическое их количество и ввести это значение с клавиатуры. Но ручное пересчитывание грозит "человеческим фактором", что и произошло на моих глазах. Покупатель, обнаружив опечатку в количестве приобретённых позиций (забрал все остатки с полки, но их число оказалось меньше пробитого в чеке) не только нервничает и возмущается (ругается с персоналом универсама), но и задерживает очередь остальных покупателей для восстановления справедливости. Возврат оплаты и узнать баланс остатков может сделать только карта администратора магазина, то есть всем известное ожидание отражается не только на обманутом покупателе, но и на прочих клиентах. А ведь если кассир не смог бы ввести количество позиций, превышающее остатки, то сразу бы заметил собственный обсчёт и не устроил бы негативную ситуацию, нервы и деньги покупателей были бы в сохранности, впечатление о торговой сети не портилось бы.
Уважаемые тестировщики, пусть ваша ограниченность в знаниях предметной области не становится причиной отсутствия достаточных ограничений в программном обеспечении.

Когда кликать QA

Моя статья "Tester's KPI" и участившиеся билды продуктов компании ConquestSS без тестирования сподвигли меня объединить данные обоих исследований и попытаться найти лучшую пропорцию количества тестировщиков и курируемых продуктов в команде разработки. Видеоролик "Нужен ли тестировщик на проекте?" от ПОИНТ-курсов утверждает, что наилучшее сочетание - это 1 тестировщик на 3 программиста, и в данных для моих графиков оно почти соблюдено.
Давайте оценим соотношения по фактическим цифрам.

Соотношение билдов в месяц и продуктов

Компания ConquestSS за 37 месяцев разработки одного продукта опубликовала 33 билда, за 8 месяцев параллельной разработки двух продуктов опубликовала 12 билдов, за 76 месяцев параллельной разработки трёх продуктов опубликовала 51 билд, за 37 месяцев параллельной разработки 4 продуктов опубликовала 59 билдов, за 12 месяцев разработки двух продуктов опубликовала 26 билдов. Примерная пропорция 1месяц/1продукт сбилась в правой части графика из-за отсутствия тестировщиков. Это хорошо заметно по следующему графику.

Соотношение тестировщиков и выпускаемых билдов

На всём протяжении выбранного периода, за который у меня накопились данные из публичных источников, пропорция 1тестировщик/3программиста сохранялась до последней части, когда команда ConquestSS совсем исключила тестировщиков-профессионалов (осталась лишь тех.писательница, слегка обучившаяся тестированию) и штат программистов сократился в 4 раза. В первом периоде один тестировщик параллельно обслуживал 3 продукта и за 107 месяцев было опубликовано 82 билда, два тестировщика на 3 продукта и 6 программистов помогли выпустить 12 билдов за 11 месяцев, 3 тестировщика на 9 программистов выпустили 17 билдов за 18 месяцев, 4 тестировщика на 10 программистов за 3 месяца выложили 5 билдов, 3 тестировщика (без ведущего специалиста) на 11 программистов за 13 месяцев выпустили 22 билда, а оставщиеся два с полтиной программиста за 17 месяцев выложили 42 билда. Эти цифры убеждают меня в моём мнении, что пропорция продуктов и тестировщиков более эффективна при соотношении 1/1. В предпоследнем периоде количество билдов в месяц возросло, поскольку все три тестировщика остались из числа юниоров, а шестой период при полном отсутствии тестировщиков подтверждает моё мнение, что программисты с лёгкостю пропускают в прод критичные баги, из-за которых приходится срочно выкладывать фикс-билды.
Графики показывают интенсивность билдов по точкам. Если точки расположены на одной прямой, значит номер версии не увеличивался и билд собирался для исправления какого-то важного бага юзера. По вертикали - номера версий продуктов, по горизонтали - даты выпуска, четыре цвета точек (синий, рыжий, зелёный, голубой) соответствуют четырём основным (без WEB сайта и портала) продуктам (SQLDetective, ClearSQL, ClearDB, docuVIEWER). У группы разработки ConquestSS существует правило: если от пользователя приходит критичный баг, то фикс-билд выкладывается всем в течение одной-двух недель. Но если баг важный для юзера, но готовится к выпуску следующая версия продукта, то юзеру даётся индивидуальный билд, а фикс официально публикуется в новой версии. По прижатости точек на графике вы можете заметить, как росло и падало качество продуктов со временем "взросления" одного тестировщика (первый период), приходом и уходом мидлов (второй и третий периоды), при полностью обновлённой группе тестирования (четвёртый период - один синьор и три юниора, пятый период - три юниора)  и при полном отсутствии профессиональных тестировщиков (последний период).
Прежде чем приглашать в команду тестировщика, хорошенько подумайте, а нужен ли вообще кто-то ещё вашей команде. Например, фин.директор и маркетолог ConquestSS, избавляясь от ведущего QA инженера или справляясь о житье-бытие, оговариваются по Фрейду, заявляя, что своих багоделов всегда достаточно, чтобы развалить компанию. Судя по вышеизложенным цифрам, группа разработки может работать стабильно, если раз в месяц концентрируется над одним продуктом. Вполне оправдан спринт в месяц для десктопного продукта, но слегка назойлив для юзера. Но если учесть, что компания ConquestSS поддерживает 3-4 продукта, то стабильные публикации билдов одного продукта раз в квартал смогли бы успокоить клиентов в плане надёжности поставщика, а группа разработки не распылялась бы на все продукты ежедневно. А там, глядишь и с глобалами бы проблема отпала, поскольку на ежемесячных планёрках такие задачи не смогли бы забыться.
Для себя, нас - тестировщиков, делю на четыре группы:
- инженер QA (quality assurance) постоянно задаёт неудобные вопросы, ведущие к развитию продукта и команды, лезет во все дела, имеет право голоса и влияния. Преподаватели из "Стратоплан" зовут таких бунтарями (смотрите доклады М. Завилейского "Три составляющие" и Олега М. Вайнбера "Зачем мы приходим в организацию и почему она нанимает именно нас");
- инженер QC (quality checker) - констататор фактов без собственного мнения, покладистый и безмолвный;
- инженер BA/BI (business analyst, business intelligence) - идейный лоббист юзерского и своего мнения;
- тестировщик на техподдержке - сборщик фактов и переводчик между пользователем и кодировщиком без права собственного мнения.
Не смотря на давнишнее рождение компании ConquestSS (с 2005 года) группа разработки придерживается позиции стартапа, поэтому так легко пренебрегает качеством продуктов. Хорошо бы на эти графики наложить суммы продаж, но у меня нет такой информации, которая бы доказала РМ-у необходимость профессионального тестирования. Программист никогда не проверит свой код так, как этим продуктом пользовался бы конечный юзер.
После просмотра доклада "Как QA инженеры могут повлиять на качество продукта? Или не могут?" Николая Алименкова на QA Fest 2016 у меня сформировалось мнение, что бизнесу разного уровня нужен определённый специалист:
* начальная стадия бизнеса (стартап, 1..5 разработчиков, нет или мало отзывов юзеров)
*-* роли тестировщика, аналитика, внедренца, техподдержки выполняют сами разработчики и владелец продукта, бизнес-аналитик выполняет роль технического консультанта
* средняя стадия бизнеса (продукту несколько лет на рынке, 5-20 разработчиков и аналитиков, отзывы регулярные)
*-* достаточно тестировщика на техподдержке и толкового аналитика-внедренца с функцией тех-консультанта
* стабильный бизнес (продукт сертифицируется по ТУ-ISO-ГОСТ, командный состав не важен, отзывы потребителей выходят на уровень юридических претензий)
*-* обязательная выделенная команда тестирования и контроля качества, совмещающая техподдержку, но отдельная от группы аналитиков и тех.консультантов.

А как в вашей команде соотносятся количества тестировщиков с программистами, продуктами и регулярностью выпусков?

Отчёт о тестировании SD 5.1.1.239

Отчёт о тестировании SQLDetective 5.1.1 (build 239), опубликованном  28 ноября 2019. Тесты основаны на пунктах Release Notes. Предыдущий билд выпустили месяц назад и в текущий попали фиксы накопившихся проблем.

IMPROVEMENTS  0.8 балла из 1 возможного, -0.2 за баги
Database Connection
⦁ Added the option “Switch to a new connection in the active window” to Preferences > Session, enabled by default. When disabled, starting a new database session does not change the database connection in the active window.
Добавлена опция переключения коннекта в активном окне в настройки приложения на страницу сессий, которая по-умолчанию включена. При выключенном состоянии запуск новой сессии базы данных не изменяет строку подключения к базе в активном окне.
Поскольку это новая опция в приложении, то тесты стоит осуществлять по чит-листу: название интуитивно понятное, краткое описание в хелпе имеется, расположение опции на странице "General / Session" логично и соответствует UI стандартам, сохранение и восстановление не отражается на других настройках, её можно найти в Preferences по наименованию. Для проверки функциональности выберем подходящие окна. Все окна в SD делятся на мультисессионные и коннекто-зависимые. К первым относятся те, что имеют комбобокс для смены строки коннекта и могут быть открыты без подключения к базе, ко вторым относятся те, что отображают содержимое базы без возможности мобильной смены сессии. Для новой опции необходимо проверить её распространение на окна первой группы и отсутствие воздействия на окна второй группы. Ко второй группе относятся мастера всех типов объектов, SmartDataset, Stored Program Editor. Перечислю мультисессионные окна, согласно структуре главного меню: Object Navigator (комбобокс на главном тулбаре), SQL Editor, HTM Editor (генерирует код для текущей схемы), Object List, View Differences, PL/SQL Profiler, Object Privileges (для открытия окна нужен хотя бы один коннект к базе), Find Object, Data Dependency Analyzer, Report Generator, Export Data (для открытия окна нужен хотя бы один коннект к базе), Import Data (для открытия окна нужен хотя бы один коннект к базе), Fast Copier, DB/Schema/Objects Compare, Schema Extractor, Schema Compiler, Schema Analyzer, Session Navigator, Storage Manager, DB Examiner, DB Monitor, Top Session Locator. Для ускорения теста открываем все перечисленные окна и подключаем или отключаем сессии БД. Осторожнее при работе с админскими утилитами, поскольку ошибки подключения обычного юзера могут прятаться под другие окна, чаще всего - за Fast Copier. Кроме подключения к базе надо проверять и отключение от сессии БД. Для интерфейсного продукта давно стоило внедрить эту экономию перерисовки. Но тесты показали, что не все окна его поддерживают при подключении сессии и все окна обновляют список коннектов при отключении сессии БД. Такая реализация говорит о непродуманности переделки UI и получает 0.8 балла. А поскольку некоторые окна меняют коннект с ошибкой базы "ORA-29275: partial multibyte character" и окно Fast Copier постоянно перекрывает диалоговые окна с предупреждениями и ошибками, то новшество теряет -0.2 балла за эти старые баги, до сих пор не исправленные.

BUGS FIXED   0.5+1+1.7-0.5+1+1+0+0=4.7  из 5+2+2+1+2+1+1+1=15 возможных, за баги -0.5-0.4=-0.9
SQL Editor  0+0.5+0+0+0=0.5  из 5 возможных
⦁ Fixed the work of the history panel splitter.
Исправлена работа сплиттера для панели с историей.
Поскольку баг конкретно не описан, то для воспроизведения в предыдущем билде поиграемся со статусом окна при открытии/закрытии и сворачивании/разворачивании/максимизации окна SQL Editor, смене позиций закладок вывода и редактора кода. Перечисленные места необходимо проверить в сочетании с опцией "Preferences / Code Editors / SQL Editor / Allow only one SQL Editor window". К сожалению, никакой разницы в работе сплиттера не выявлено по сравнению с предыдущим билдом, поэтому фикс не получает ни балла.
⦁ Splitter positions of the Dataset Manager and SQL History panels are now remembered and restored correctly.
Позиции сплиттеров настройщика данных и истории запросов теперь запоминаются и восстанавливаются корректно.
В чём может заключаться корректность по отношению к позициям сплиттера? Также, как и в предыдущем фиксе, изменения необходимо проверять в сочетании с опцией расположения закладок с результатами и редактора кода, поскольку программист мог пронумеровать элементы окна, чтобы не придумывать уникальные имена. С запоминанием и восстановлением позиции сплиттера были проблемы только у настройщика данных. Они исправлены, а пункт RNs получает лишь 0.5 балла, потому что описание фикса не соответствует действительности (упомянут элемент без изменений и использован эпитет correctly без отсылки к правилам).
⦁ The token with the leading ampersand “&” in a string literal is now always recognized as a possible substitution variable.
Вызовы через амперсанд в символьных строковых теперь всегда распознаются как возможные переменные подстановки.
Такое описание фикса более похоже на усовершенствование, а не на исправление проблемы. В настройках приложения существует опция "Preferences / Code Editors / Bind and Subst. Variables / When a Token with Leading '&' Appears in a String Literal" с доступными значениями: распознавать, не распознавать как переменную подстановки, предлагать пользователю выбрать вручную. Пользовательский вариант является дефолтным, как в предыдущем, так и в текущем билдах. Применяется распознавание амперсанда в SQL Editor и Stored Program Editor на одноимённых закладках. Так что описание пункта RNs не проясняет пользователю сделанные программистом изменения, а лишь запутывает. Надо полагать, что на самом деле поправлен лишь какой-то из частных случаев распознавания переменных подстановки. Любой из тестировщиков знает, сколько вариантов нужно для проверки символьного поля, эти же вариации применимы и к символьной строке с переменной подстановки. Поскольку программист пожадничал с собственными знаниями и не пояснил тех.писательнице подробности правки (а может ничего и не исправлено по-факту), то фикс не получает ни балла.
⦁ The height of the results panel is no longer minimized after switching back from the Stored Program Editor.
Высота панели с результатами больше не минимизируется после переключения из редактора хранимых программ.
Все мои попытки воспроизвести проблему в предыдущем билде не увенчались успехом, не спровоцировали её даже сочетания с опцией расположения редактора сверху результатов и максимизация окон, параллельное открытие нескольких окон одного типа и растяжение дополнительных панелей через сплиттер. Если бы описание было более конкретным и легко воспроизводилось, то можно было бы заметить работу программиста. Поэтому фикс не получает ни балла.
⦁ A literal is no longer truncated if there are line breaks in it.
Символьные больше не обнуляются, если в них есть перевод строки.
Совершенно непонятное описание фикса, для которого у меня нет никаких соображений, где и как такое можно было бы воспроизвести. Из-за неясной трактовки фикс не получает ни балла.
Smart Dataset  0+1=1  из 2 возможных
⦁ The “List index out of bounds” error no longer occurs on refreshing the dataset for a modified table.
Ошибка превышения количества больше не случается при обновлении данных для изменённой таблицы.
О том, как может быть изменена таблица следует искать в документации БД Oracle в рамках статьи ALTER TABLE. Поскольку ранее случалась ошибка о некоем количестве, то попробуем изменить состав таблицы по её столбцам. Будем полагать, что под модификацией таблицы подразумевается только структура объекта, а не его данные, поэтому побалуемся с таблицей из 3-4 полей без содержимого. Описание фикса не конкретизировано типами полей и наличием данных. Вероятно поэтому у меня не получилось воспроизвсти баг (открыть таблицу в SmartDataset, через мастер объекта удалить или добавить колонку, в гриде выполнить Refresh Data-F12 или Reopen Object) в предыдущем и текущем билдах. Пункту RNs не могу дать ни балла.
⦁ The error “ORA-00947: not enough values” no longer occurs on trying to perform an insert into tables with several object type fields of a similar type.
Ошибка о недостаточности значений больше не случается при попытке выполнить вставку данных в таблицы с несколькими полями объектного типа одинаковой вариации.
Первое, что меня смутило, это множественное число таблиц для вставки данных. Надеюсь, что это всего лишь опечатка тех.писательницы, поскольку через SmartDataset одномоментно редактируются данные только в одной таблице (служебное поле ROWID в запросе по правилам Oracle может быть лишь одно). Для минимального теста создаём объектный тип с одним атрибутом, на основе которого в таблице из трёх полей (символьное и два пользовательского типа) двум выбираем только что созданный тип. В гриде такая таблица будет состоять из трёх столбцов, два из которых имеют сложносоставные названия (имя поля и через точку имя атрибута объектного типа). В предыдущем билде описанный баг проявляется только при добавлении непустых данных, но не случается при их изменении. В текущем билде баг исправлен, то есть добавление и модификация данных в любом из столбцов этой таблицы не вызывают проблем. Исправление заслужило балл.
Database Examiner  1+0.7=1.7   из 2 возможных и -0.3-0.2=-0.5 за проблемы
⦁ The “Refresh Data” command is no longer active when a database connection is closed.
Команда обновления данных больше не активна после закрытия коннекта к базе.
Все страницы утилиты состоят из гридов, составленных из системных вьюверов, поэтому для теста выберем любую страницу. Баг проявлялся в предыдущем билде только для гридов, интерфейсным элементом для которых является самописный HisGrid, а простые списки из двух колонок на страницах Instances, Database и кнопка на основном тулбаре окна не оставляли подсвеченными две жёлтые стрелки. Поскольку аналогичные интерфейсные элементы используются повсеместно, то дисконнект следует поглядеть и во всех админских утилитах, окнах для работы с данными. Описанный баг оказался характерен лишь для окна DB Examiner. Но продолжение комплексного тестирования выявило проблему излишнего считывания привилегий при отсутствии коннекта к базе на странице Database. К сожалению, в ConquestSS игнорируеют полное тестирование и этот очевидный баг прошёл мимо группы разработки, то есть не исправлен в текущем билде. А текущим фиксом поправлен лишь мелкий интерфейсный глюк (клик по кнопке и горячей клавише F12 безопасный без коннекта). Пункт RNs получает балл за исправление и теряет -0.3 за невыявленный функциональный баг.
⦁ The “Find in All Columns” window now always opens on pressing Ctrl+F in the Database Examiner.
Окно поиска по всем колонкам теперь всегда открывается при нажатии горячей клавиши в окне утилиты.
Описание бага больше смахивает на усовершенствование, нежели исправление проблемы. На деле же горячая клавиша для поиска по данным гридов стала срабатывать только при наличии активного курсора в самом гриде, а вместо диалога поиска по тексту или файлам теперь открывается диалог поиска с интерфейсом локальной операционной системы, в котором всё ещё актуальны проблемы подписей элементов на региональном языке и мигающий курсор виден в области радио-кнопок вместо текстового поля ввода. Разность слов тех.писательницы и дела программиста приносит фиксу только 0.7 балла, а старые баги опять снимают -0.2.
Session Navigator  -0.5 из 1 возможного
⦁ If an Oracle directory does not exist in the database, it is now automatically created to get a trace file.
Если директория, как объект базы, не существует, то она автоматически создаётся для доступа к файлу трассировки.
Теоретическую часть об объекте Директория вам стоит изучить самостоятельно по статьям CREATE/ALTER/DROP DIRECTORY из документации Oracle DB. Только для Session Navigator этот объект, как и файл трассировки, не имеют надобности. Все данные, отображаемые в Session Navigator, берутся из системных вьюверов напрямую без директорий, а трассировка используется в SQL Editor и TKPROF Shell. Так что этот пункт RNs невозможно никак проверить из-за неадекватного описания или выбора модуля. К тому же опасные слова о том, что объект базы будет автоматически создан, тревожат меня отсутствием предупреждения о скрытых действиях в базе, которые может выполнять только юзер с админскими правами. Ни балла за такое дать не могу, да ещё сниму как минимум полбалла за возможные опасности и давно неправленный баг "ORA-29275: partial multibyte character" при открытии модуля.
Schema Compiler  1+0=1  из 2 возможных, но -0.4 за проблемы
⦁ When the “Auto Open” option is enabled, the Schema Compiler window now always opens automatically when a new session is created.
При включенной опции автооткрытия окно компилятора схемы автоматически открывается при создании новой сессии.
Опция автооткрытия окна настраивается в списке Window Settings рабочей области "Preferences / General / Workspace" и, как вы понимаете, должна одинаково работать для всех окон из этого списка. Для скорости теста включаем в настройках приложения автооткрытие всех окон и подключаем ещё одну сессию базы, желательно с админскими привилегиями. Компилятор схемы стал открываться при новом коннекте и фикс получает свой балл. Замечено было, что исправилась проблема с окнами ассистента кода и для быстрого копирования объектов, которые ранее всегда показывались поверх всех приложений, открытых в операционной системе. А встречающиеся проблемы в каждом открываемом окне (нехватка прав, испорченные скрипты браузера документации и прочее) всё также стопорят открытие последующих окон, за что есть смысл снять -0.2 балла. В списке окон на странице Preferences почему-то Telegram не расположен в алфавитном порядке. А вместе с компилятором схемы не открывалось (и до сих пор не открывается) автоматически окно Action Output с результатами действий приложения. Выявленные баги отнимают у билда ещё -0.2 балла. Почему-то последовательное групповое исключение окон из автооткрытия и в прошлом, и в текущем билдах включает галки для всех окон, но поскольку мне пока не удалось локализовать проблему, то за баг списывать баллы не буду.
⦁ The Schema Compiler customization is no longer cleared after disconnecting from an inactive session.
Настройки компилятора схемы теперь не очищаются после отключения активной сессии.
К настройкам утилиты относятся не только опции на соответствующей закладке, но и выбор типа компиляции, фильтры на объекты и схемы. Сравним все их в текущем и предыдущем билдах в сочетании с новой опцией про строку коннекта при подключении сессии. Кроме смены или сохранения строки подключения при новом коннекте никаких изменений в окне не замечено, поэтому считаю этот пункт RNs лишним и не даю за него балл. Опять же, бОльшая часть проблемы пришла от тех.писательницы, не конкретизировавшей фикс, и от программиста, не пожелавшего обучить её техническим вопросам.
Export Data Wizard 1 из 1 возможного
⦁ Exporting data from the Object Navigator no longer adds a non-existent object “.” to the export objects list.
Экспорт данных из навигатора объектов больше не добавляет несуществующий объект без имени и схемы в список объектов для экспорта.
Мастер экспорта данных можно открыть несколькими способами: из главного меню и главного тулбара, из открытого грида данных (SmartDataset, закладка Data в ContentSelector, все доступные гриды данных во всех утилитах приложения) по кнопке на тулбаре окна или из контекстного меню, через контекстное меню объекта данных в ObjectSelector. Из всех перечисленных вариантов только последний давал описанный баг в предыдущем билде и исправлен в текущем. Фикс получает балл, но тех.писательнице стоило вместо общего наименования окна Object Navigator указать его конкретное дерево - ObjectSelector.
Dataset/Datagrid  0 из 1 возможного
⦁ The QBE (Query By Example) and Find commands are no longer active when the dataset is closed.
Мастер настройки фильтров и диалог поиска больше нельзя активировать в закрытом наборе данных.
Очень странная формулировка, но попробуем её понять по фактической работе. О том, как вызвать мастер установки фильтров или диалог поиска, написано в топиках хелпа приложения. А вот что имелось ввиду под закрытым набором данных даже мне со знанием продукта с первых дней его разработки не понятно. На ум приходят такие действия: при открытом SmartDataset с данными закрыть сессию, открыть данные в SmartDataset в режиме только чтения без возможности редактирования, сменить активное окно. Но никакой из перечисленных вариантов поведения приложения не воспроизводит описанный баг. Поэтому не могу дать ни балла.
Main Window  0 из 1 возможного
⦁ The main application window no longer hides after opening the Database Connection window for the second time.
Главное окно приложения больше не прячется после открытия окна коннектов во второй раз.
Главное окно обязано быть под окном подключения к базе, в какой бы раз не делалось подключение. По описанному фиксу могу заключить, что тех.писательница скорее всего перепутала окна и, возможно, окно коннекта иногда пряталось под основное окно приложения. Но скорее всего проблема была и осталась совсем в другом. Это не раз мне удавалось воспроизвести в предыдущем и текущем билдах, когда новый коннект  автоматически открывал рабочие окна с какими-нибудь ошибками (недостаточно прав, проблемы с перекодировкой или в скриптах документации), диалоговые окна которых и прятались, создавая эффект подвисания приложения. Максимально за подобное описание проблемы и её якобы исправления не могу дать ни балла, а при плохом настроении (лучший подарок тестировщику - это билд с полностью закрытыми "зелёными" задачами и без порождённых багов) этот пункт получил бы от меня отрицательный балл.

Итого по билду: 0.8+4.7=5.5 баллов из  1+15=16 возможных, что равняется 5.5/16=34%, из которых баги отнимают   -0.2-0.9=-1.1 балла.

Глобалы

Глобальными модулями в группе разработки продуктов компании ConquestSS называются такие компоненты трёх смежных приложений, код которых равнозначно применим в каждой программе. Например, самостоятельная библиотека OSD.DLL с полноценным интерфейсом и функционалом, интерфейсное окно ABOUT с информацией о продукте, текстовый парсер для сбора данных анализатора кода. Соответственно задачи, которые касаются только таких модулей, а не их внедрения в продукт, называются "глобалами". Для удобства фильтрации такие задачи объединены были в отдельный "продукт в BTS".
SQLDetective, ClearSQL, ClearDB - интерфейсные продукты, написанные в основном на Delphi. Но поскольку была внедрена система LFT, то многие стандартные элементы не могли удовлетворить требования, выработанные этой командой. Поэтому программисты ConquestSS вынуждены были дописывать или переделывать интерфейсные компоненты. Например, для выставления своих фонтов и отступов в ckeck-box, radio-button, list-view, плавное расцвечивание в progress-bar и многое другое. Переработка компонента оформлялась как глобал, а его внедрение в определённый продукт - задачей на конкретное приложение и его модуль. Но в большинстве своём задачи по внедрению в конкретный продукт игнорировались, не оформлялись, подразумевая процесс внедрения в рамках одной задачи-глобала.
Со временем появилась необходимость вести версионность некоторых глобальных модулей. До сих пор сохранилось отображение версии только для анализатора кода. Её номер вы можете увидеть в комментариях к отформатированному коду. Парсер кода - часто меняющийся в последнее время модуль, поскольку обязан поддерживать все новшества базы данных Oracle. Поэтому все три продукта вполне могут выпускаться регулярно, обновляя лишь один глобальный модуль - анализатор кода. А вот версионность другого глобала - OSD.DLL - помогла лишь однажды, когда он кардинально был переработан для работы отладчика. Но, к сожалению, не все старые версии смогли на лету сработаться с библиотекой, поэтому простое копирование файла в рабочую папку приложения не спасало положение, и для полноценной отладки приходилось пересобирать весь продукт с изменённой библиотекой. Не так давно OSD переместили в core продуктов и его версионность отжила свою надобность. У всех остальных модулей-глобалов вообще не велась версионность, достаточно было версий основных продуктов, в которые внедрялись эти глобалы. А при закрытии задач в BTS эти их внутренние версии вообще никогда не имели смысла.
Исходники продуктов, как и положено, хранятся в системе контроля версий (VCS), каждый в своей ветке. Для глобальных модулей была выделена самостоятельная ветка. При этом сборка каждого продукта, автоматизированная со временем, выбирала файлы не только из своей продуктовой ветки, но и мониторила обновления по дате редактирования ветку глобалов. Когда dev-ops реализовал полезняшку (подкинутую мной идею о добавлении комментариев в задачи Jira с номером билда, в который вошёл фикс), то это значительно упростило работу тестировщика, часто сомневавшегося "стоит ли начинать тест? перебилден ли продукт с требуемой версией глобала?". VCS Perforce связана с Jira через FishEye, а сборщик билдов написан на Python, поэтому кроме нотификаций в Slack о готовом билде, dev-ops легко реализовывал и многие другие важные для команды разработки напоминания и уведомления. Да, пока сборка велась в ручном режиме слишком силён был человеческий фактор и часто забывали включить в билд нужную версию глобала, либо ошибались с датами фиксов и накладывали старые баги на новый функционал. И тогда мы получали весьма жуткие временные баги от корявой сборки.
Конечно, такой вынос одинакового кода и интерфейса в отдельную папку VCS был весьма удобен программистам. Ведь у них значительно поубавилось работы. Код не приходилось триплить во все продукты, а лишь сделать одну правку. Но, к сожалению, не всегда задачи в BTS оформлялись на каждый конкретный продукт. Поэтому тестировщику приходилось в каждом из трёх продуктов проводить одни и теже тесты, да ещё удваивать (а то и утраивать) их из-за необходимости поддерживать несколько версий продукта (опубликованный, предыдущий опубликованный, разрабатываемый по спец.заказу или общий будущий). Программист комментировал свои фиксы только в VCS, по которым собирались внутренние Release Notes, то есть единожды. А тестировщик обязан был отметить фиксы в каждом продукте и его версиях. Поэтому пришлось в самописной BTS создать дополнительную таблицу (child для основной таблицы задач)  для таких отметок. Самописную BTS вполне удавалось заполнять в SmartDataset гриде своего же продукта SQLDetective, поскольку в основном это были обычные таблицы с набором справочников. Но для отметок глобалов в SD не сгодилась даже утилита DataDependencyAnalyzer. И после недолгих упрашиваний dev-ops смастерил мне формочку на пару гридов (parent - all_bugs, child - global_checks) со справочником версий продуктов. Да, такой дополнительный список усложнял сбор Release Notes для пользователей, поскольку РМ раньше фильтровал только общую таблицу задач, а теперь ему приходилось частенько припоминать о глобалах.
Когда же самописную BTS сменили на Jira, то систему глобалов не упразднили. Самостоятельный продукт Global Modules (GM) так и продолжил своё существование, но его ни минули пара революций. Команда разработки росла и новым тестировщикам тяжко было как понять систему глобалов, так и поддерживать её в актуальном состоянии. Некоторые модули имели реализацию только в определённых продуктах. Например, CRUD2 матрица или браузерный отчёт анализатора (CS Project Report, CDB Docu), которые формируются сразу для нескольких объектов базы, а потому не приемлемы для единичных объектов в SD. Участились отвлекания старожилов на разъяснения, поскольку даже пояснения к модулям, которое возможно заполнить в справочниках Jira, не отображается для выбираемых компонентов в процессе оформления задачи. Так что моя одноразовая акция по проставлению в комментариях каждого компонента продукта GM списка поддерживаемых продуктов не сильно помогла. Пришлось проводить проверку каждой новой задачи GM на применимость в продуктах и дописывать в Description важные примечания для разработчиков и тестировщиков, если фикс не должен был быть в каком-то из продуктов или его реализация имела продуктовые особенности. Тех.писательница, собиравшая Release Notes, тоже постоянно забывала упомянуть об изменениях за счёт глобалов, либо добавляла лишние пункты, не применимые в продукте, либо текст по опечатке содержал упоминание соседнего продукта. В продукте GM приходилось админу Jira дублировать версии конкретных продуктов после каждой сборки. Тогда ещё не был полноценно дописан авто-билдер, поэтому добавление производилось вручную после публикации, а поскольку не редки были случаи забывчивости, то чек-лист публикации пришлось пополнить отдельным пунктом для админа Jira. Даже РМ, собиравший бэклог публикации в Jira Structure, не всегда вспоминал, что стоит добавить и уже закрытую по другим продуктам GM-задачу, но ещё не внедрённую по текущему спринту. Эти неудобства послужили аргументом к прекращению поддержки GM. Несколько месяцев трёх тестировщиков было потрачено на перенесение имевшихся GM-задач в конкретные продукты. Спасибо, в Jira есть фичи клонирования и переноса задач из одного продукта в соседний, поэтому имевшиеся задачи разносились более менее быстро. А вот новые иногда забывались клонироваться. По окончании этой работы взвыли программисты, которые забывали открыть в Jira слинкованные одноимённые задачи, сменить им статус и отметить затраченное время, забывали в VCS упомянуть авто-фиксы по всем продуктам. Но те проггеры, которые не забывали про лишние телодвижения, были рады резкому скачку их производительности, ведь она утроилась по времени и количеству задач! Итак, тестировщики обрадовались конкретике, тех.писательница успокоилась при сборе Release Notes из-за уменьшения фильтра, но РМ в большей степени прислушивался к мнению программистов, которые ленились отмечать свою работу в клонированных задачах. Из-за этого РМ вопреки мнению большинства своим "царским указом" возобновил поддержку в Jira глобалов. Да притом изменил путь статусов на жёсткую схему, и один статус TESTING был разбит на несколько (сначала три, а потом и четыре) по количеству разрабатываемых продуктов TESTING_Prod1, TESTING_Prod2, TESTING_Prod3, TESTING_Prod4. Статусы можно было сменить только в обозначенном порядке, что очень осложнило работу тестировщикам, которые были закреплены за конкретными продуктами. Но РМ на это неудобство ответил распоряжением самоуправца и закрепил глобалы за одним тестировщиком из числа новичков. Юный тестировщик не возражал, так как не знал, что столкнётся с более сложной проблемой. На тот момент продукт ежедневно собирался при наличии фиксов в своей ветке, а поскольку какие-то из продуктов были "заморожены", то тестировщик не мог закрыть проверенную в продуктах 1 и 4 задачу, не имевшую реализации в продуктах 2 и 3 ввиду отсутствия нужного билда. Dev-ops-у пришлось опять менять авто-билдер, чтобы даже временно отложенные продукты всё равно ежедневно собирались, но лишь для тестирования. И РМ-у было наплевать на то, что некоторым задачам абсолютно не нужно было проходить хоть какую-то проверку в определённых продуктах, то есть авто-билдер гонялся впустую, тестировщик безрезультатно искал исполнения в пустом продукте, а тех.писательница опять стала ошибочно вносить "чужие" фиксы в Release Notes.
Из обеих революций для большинства членов команды разработки был вынесен единый вывод: "Глобалы - это зло!", но поскольку мнение ленивых и приближённых к РМ-у программистов перевешивало демократизм, то о каком бы-то ни было компромиссе мечтать не стоит. Кое-как соглашусь, что в VCS глобалы есть смысл сопровождать в собственной ветке, но и здесь не мало проблем с внутренней и общей версионностью. А в BTS никак не стоит объединять глобалы, поскольку они первые в числе забываемых. Если у вас Jira, то клонирование и перенос задач между продуктами легко снимут с вас проблемы актуализации багов и фич. Кабы в нашей старой самописной BTS была фича клонирования багов и разработок в другие продукты (SmartDataset в SD может дублировать строки только в одной таблице, а значит не давал полноценного клонирования по справочникам, да и не видно было потом линкованного исходника для клонов), то моя идея глобальных модулей ограничилась бы только VCS и в BTS не отразилась.

Tester's KPI

Product Manager (РМ) команды разработки в ConquestSS многие годы опирался на количество задач при оценке уровня специалиста. Поэтому, когда команда разрослась, поручил мне еженедельно публиковать в чате отчёт об обработанных задачах в разрезе продуктов (от трёх до шести приложений) и о переписке тех.поддержки (сколько получено писем, сколько отправлено ответов, сколько застряло в обработке). В те недели, когда у меня были отпуска, количество обработанных задач резко падало, и это первым заметил PM. Сделав выборку значений и подставив периоды моего отсутствия, у меня получился нижеследующий график.

Схождение отпусков и провалов задач

Скачки снижения количества задач (голубая и рыжая кривые) в точности совпали помесячно с периодами моих отпусков (коричневая кривая, где 100 - наличие отпуска, 0 - рабочий период). Что в точности подтвердило гипотезу РМ.
Но мне стали интересны и другие мои идеи.
1. Как часто стоит менять курируемый продукт? Ежедневно, как это делал РМ на стендапах, или закрепить один продукт за каждым тестировщиком на весь период спринта?
2. Зависит ли производительность тестировщика от его гендерности?
3. Кто эффективнее обучает новичка?
Для этого была собрана нижеследующая таблица.

Данные о сроках и количестве задач в разрезе тестировщиков

Имя (пол)		Tester_1 (F)	Tester_2 (F)	Tester_3 (F)	Tester_4 (F)	Tester_5 (M)	Tester_6 (F)	Tester_7 (M)
Через N дней оформлен "свой" баг		1	13	4	15	11	9	23
Через N дней оформлена первая задача из техподдержки		16	46	3	15	11	9	23
Срок в команде (месяцы)		165	26	16	26	6	5	2
Обработано всего задач за весь период		32457	4510	2181	1632	548	427	157
Скорость (обработано задач в месяц)		196,7	173,5	136,3	62,8	91,3	85,4	78,5
Количество оформленных задач (найденные баги самостоятельно и предложения из техподдержки)	всего	17204	1697	814	1362	188	148	51
	в т.ч. своих	12187	994	497	707	91	65	35
	%	71	59	61	52	48	44	69
Курируемый продукт		All	P_1, P_2, P_3	P_1, P_4	All	P_1, P_3, P_4	P_2	P_1, P_4
Количество обработанных задач по Product_1	всего	4981	3042	1116	926	288	16	147
	в т.ч. новые	3779	1136	260	798	101	10	44
	закрытые	1202	1906	856	128	187	6	103
Количество обработанных задач по Product_2	всего	5920	923	86	324	16	400	0
	в т.ч. новые	3701	328	16	292	12	128	0
	закрытые	2219	595	70	32	4	272	0
Количество обработанных задач по Product_3	всего	21016	336	31	163	164	11	0
	в т.ч. новые	11388	174	6	152	42	10	0
	закрытые	9628	162	25	11	122	1	0
Количество обработанных задач по Product_4	всего	540	209	948	219	80	0	10
	в т.ч. новые	444	59	532	120	33	0	7
	закрытые	96	150	416	99	47	0	3
Кто обучал внутренним правилам		самостоятельно	Tester_1	Tester_1	PM	Tester_3	PM	Tester_5

Если рассмотреть цифры в строке "Скорость (обработано задач в месяц)" в зависимости от строки "Курируемый продукт", то можно предположить, что тестировщик - универсальный солдат, легко перескакивающий с одной темы на другую. Но если учесть "Срок в команде (месяцы)", то гипотеза становится сомнительной. Особенно после отчёта на одном из стендапов, когда Tester_6 отчиталась об оформлении одного бага, а от Tester_1 за этот же день было добавлено в BTS более 20-ти задач.
На второй мой вопрос о половой принадлежности цифры мало что могут ответить. Поскольку не было возможности разбить задачи по их тематичности, которая в большей степени влияет на эффективность распределения работ. Более подробно об этом читайте в моей статье "Гендерность на страже качества или Вам Девочку или Мальчика?".
А вот на третий вопрос об обучении цифры вполне подтвердили мою гипотезу, что передавать знания должен единый лидер. Скорость учеников прямопропорциональна скорости учителя. Взгляните на строки "Скорость (обработано задач в месяц)" и "Кто обучал внутренним правилам" в купе со значениями "Курируемый продукт".
По таблице может у вас возникнуть вопрос о наличии данных в продуктовых деталях у тестировщиков, занимавшихся не всеми продуктами. Это последствия частой смены кураторов, которую так усердно лоббировал РМ, желая превратить нас в универсальных солдатов. Как следствие, одна из тестировщиц на указания шефа стала отвечать смайликом "Yes, Sir!", но он воспринял это лишь шуткой, не придав значения хлипкости командного духа подчинённых.
Количеством закрытых в спринте задач любил бахвалиться РМ и перед вышестоящим руководством, не вдаваясь в подробности того, что половина из них были элементарным откатом к функционалу прошлых версий. На каждое изменение в продукте "деды" тестирования всегда оформят, как минимум, две задачи. А если тестировщик более внимательно слышит пользователя, нежели сборщик бэклога РМ, то процесс его пополнения будет бесконечным: РМ навязывает свой взгляд на решение, а тестировщик инвертирует к пожеланиям пользователей.