Взгляд назад

Ретроспективу тестировщики обычно проводят совместно со всей командой, но дата наших подведений итогов возможна намного позже выпуска, поскольку результат нашей работы виден лишь в долгосрочной перспективе. Отсутствие жалоб пользователей или благодарность за вовремя и в точности выполненные изменения - это положительный результат действий QA и его оценивают обычно на контрасте. Руководители проектов чаще не желают замечать тех ежедневных титанических усилий защитников качества, которые приводят к успеху продукта, а приписывают его только себе. Наши частые просьбы подправить мелкие баги в общей корзине изменений приводят к лоску всего продукта. Кто из ваших лидов отмечал эти капли на фоне моря бэклога во время ретроспективы? QA вполне могут приплюсовывать такие неприметные шажки к кампании по профилактике проблем.
Две-три недели изоляции достаточно для проведения первой ретроспективы. Но для полноценной оценки стоит учитывать не только предпринятые меры в учётный период. На примере современного общества можно увидеть, что государственное здравоохранение, организованное Н. Семашко, именно сейчас дало положительный эффект - спокойствие и государственную защищённость граждан. Страны, нацеленные на быстрый доход, не стремящиеся к долгосрочным перспективам (аналогия со стартаперами), только в текущей критичной ситуации заметили свою несостоятельность. Это яркий пример необходимости проводить регулярную профилактику вместо надежды на единственного супергероя, который в очередной раз вставит "костыль". Ещё одним положительным шагом, сыгравшим свою роль в условиях удалённой работы на дому, считаю проект Д. Медведева "Последняя миля". Как сто лет назад Ленин продвигал освещение по всей стране, так и в начале этого века нас покрыли RUNET-ом. Благодаря такому далеко-сведущему движению мы не только сейчас своевременно проинформированы обо всём, но можем продолжать обучение и трудовую деятельность. В рамках ретроспективы стоит сказать "спасибо" за столь важную предусмотрительность. А ваши тимлиды отмечают на подведении итогов роль примечаний и идей QA?
Наш соратник, бывший IT-шник, хотя врядли в наш инфо-век мы успеем стать "бывшими", М. Мишустин своевременно способствовал цифровизации налогообложения, а теперь, отменив в этом году перепись населения, надеюсь и её переведёт в режим фактов, не давая повода всяким фрикам хайпануть за государственный счёт. Хорошо помню свою волонтёрскую деятельность конца советского периода, когда летними вечерами приходилось обходить квартал за кварталом близлежащих к школе домов и переписывать всех детей, чтобы школа смогла вовремя составить расписание и подобрать пед.состав на одну или две-три смены. Тогда не было возможности обменяться базами данных ЗАГСу, паспортному столу и школам, даже тетрадку и ручку нам никто не выдавал. А сегодня тратятся немалые средства на оборудование (планшеты, канцелярия, удостоверения, реклама) и зарплату опрашивателей. Ведь эти все деньги и материалы вполне себе могли бы сослужить более выгодно: планшеты очень нужны школьникам для удалённого обучения, за меньшие деньги любое бюро разработки ПО быстро напишет связь всех нужных баз данных. Цифровизация переписи населения - это не только единоразовая экономия, это долгосрочное ПО, которым можно будет пользоваться хоть ежегодно, хоть ежедневно. Аналитики всех слоёв выгадают от этого, а у рядовых граждан не будет повода выдумывать всякую всячину взамен реальных имён, национальностей и прочих житейских параметров. Тут, как нельзя лучше, подходят обе поговорки "не было бы счастья, так несчастье помогло" и "всё, что не делается - к лучшему". Надеюсь, отменённая в этом году перепись населения перейдёт в разряд госзаказа на ПО, тем самым даст нам, тестировщикам-интеграторам, больше работы.
Ещё один правильный шаг делает правительство - повсеместно строит больничные комплексы. Это достаточно умно, если учесть, что сейчас семьи много времени проводят вместе, а государство объявило о поощрении роста демографии. Хочу натолкнуть вас на мысль, что эти больницы к концу года будут весьма востребованы в качестве перинатальных центров. QA, а вы умеете предложить такой костыль в критичных условиях, который лёгким движением превращается в солидное новшество? Помните, для плодотворной работы тестировщик обязан обладать многоходовым разумом шахматиста.
Ограничения на поездки переводят нас повсеместно в ранг пешеходов, многие из которых возможно спровоцируют очередной общегосударственный проект "Дорога к дому", в рамках которого главы поселений почувствуют на своих подошвах изношенность или отсутствие тротуаров, их затемнённость или узость. Надеюсь, местным властям, предпринимателям и жителям в рамках такой национальной программы удастся реставрировать устаревшие дорожки, проложить новые с полным соблюдением дистанции, обустроить зоны для велосипедистов, роллеров и иных мелко-колесящих участников движения. Хочется верить, что проект "Дорога к дому" на законодательном уровне закрепит героскутеры, скейтборды, самокаты и ролики, как средства передвижения по выделенным полосам тротуаров и пешеходных дорожек. Любое сужение рамок в творческом уме тестировщика порождает выгодные решения.
В рамках кризисного периода главы местного самоуправления получили больше полномочий, но почему-то не всюду торопятся ими воспользоваться на благо своих жителей. Например, каждый многоквартирный дом имеет придомовую территорию, но жители заперты в квартирах. А ведь старшие по дому и подъезду вполне могли бы составить плавающий график прогулок в пределах двора с предварительной санобработкой. Это же не так сложно - родителям части квартир за 10-15 минут пересменки до своей прогулки опрыскать детскую площадку антисептиками, а на последующие 45 минут вывести своих чад под присмотром и в соответствующем времени обмундировании (маска, перчатки).  Даже если в доме 100-200 квартир, то удлинившийся световой день вполне достаточен для того, чтоб на игровой площадке поочерёдно побывали хотя бы полчаса ежедневно все проживающие дети. Ребёнку нужен свежий воздух, физическая нагрузка, а не всякие жилые строения способны выдержать нагрузку прыгающих и бегающих непосед, да и стране более важны здоровые, а не хилые граждане. Если вам дали чуть больше воли, то используйте её на благо окружающих и тогда профит от неё подмигнёт звёздочкой на плече.
А. Рыжов хайпует постановками секс-шоу на старшеклассниках вместо воспитания в них культурного поколения. Запреты молодым актёрам на полное прочтение и просмотр оригинальных источников приводят к тому, что спектакли ТЮЗа из раза в раз отображают только комплексы режиссёра, а не истинные проблемы автора произведения и современного поколения. Театр - искусство массовое, несущее разум и воспитание. Также, как и при разработке ПО, постановка спектаклей вынуждена учитывать желания потребителей, изначально взятый курс стоит не только корректировать согласно современным течениям, но и забрасывать удочку на перспективу - развивать общество. А ваша команда на ретроспективе какие уроки пройденного периода усваивает и вырабатывает ли новые цели?
НТВ посылает московских репортёров в поля, не тронутые короновирусом, вместо расширения полномочий местных сотрудников и предотвращения распространения заразы, ведь привезти микробы они вполне могут на аппаратуре. Микрофоны как дезинфицируют? Концерт в Большом Театре показал отношение артистов к своему производственному предмету: клавиши рояля протирали перед каждым выступлением, О. Газманов держал микрофон в перчатках. Вещание круглосуточного новостного канала "Россия 24" перебазировалось в домашние условия, а НТВ по-прежнему собирает звёзд на тесных диванчиках, стратегически-важные каналы "Первый" и "Россия 1" в большинстве прямых эфиров и ток-шоу соблюдают социальную дистанцию, а НТВ зрителей и участников передач плотно набивает в зал без санитарных масок. Как представитель QA предупреждаю общественность, что телевещательный канал своим примером исключительности опасен в дни пандемии из-за несоблюдения санитарных правил. Не удивительно, что некоторые жители не соблюдают самоизоляцию, поскольку они берут пример со своих "любимых" телеканалов. История любых времён докажет вам, что в достижении успеха практика двойных стандартов никогда не являлась помощником, а только усугубляла процесс деградации.
За одну-две недели удалённой работы любой оценит важность соблюдения общепринятых правил и особенно распорядка дня, при чём не только средним звеном, но и высшим. Древняя наука - педагогика - практикует закон "пример заразителен", да и своё название взяла из фразы "веду за собой". Если руководитель желает сплотить коллектив и воспитать его в лучшем виде, то должен начать с себя, показать положительный пример на своём поведении и постоянно его придерживаться. Тайм-менеджмент нарушается начальником, считающим себя всегда исключением и не уважающим рабочее время своих сотрудников. В таких случаях я ратую за лозунг: "Чаты вместо звонков!" Профессионалы-тестировщики даже могут обучать искусству задавать краткие, конкретные, однозначные вопросы, которые способствуют эффективности в производстве и взаимоотношениях. Довольно многих раздражают голосовые сообщения из-за слов-паразитов, отнимающих драгоценное время. А при печатании текста ни их, ни мат уже не вставить. Боитесь, что затеряется ответ? Используйте напоминалки и цитирование в чатах. Любители поболтать, экономьте время ваших секретарш, которым всё-равно придётся переводить звук в печатный текст, ставьте задачи и вопросы сразу в письменном виде.

Полагаю, на этих нескольких примерах стали более очевидны принципы ретроспективы:
- выявить положительные и негативные действия как всей команды, так и отдельных её членов;
- дать оценку последствиям шагов обеих (+/-) сторон;
- выяснить причины успехов и провалов для выработки общих правил;
-  определить вектор развития.
Желаю, чтобы совещания в конце спринта стали более эффективными за счёт вышеизложенной памятки.

Когда кликать 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-ГОСТ, командный состав не важен, отзывы потребителей выходят на уровень юридических претензий)
*-* обязательная выделенная команда тестирования и контроля качества, совмещающая техподдержку, но отдельная от группы аналитиков и тех.консультантов.

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

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!", но он воспринял это лишь шуткой, не придав значения хлипкости командного духа подчинённых.
Количеством закрытых в спринте задач любил бахвалиться РМ и перед вышестоящим руководством, не вдаваясь в подробности того, что половина из них были элементарным откатом к функционалу прошлых версий. На каждое изменение в продукте "деды" тестирования всегда оформят, как минимум, две задачи. А если тестировщик более внимательно слышит пользователя, нежели сборщик бэклога РМ, то процесс его пополнения будет бесконечным: РМ навязывает свой взгляд на решение, а тестировщик инвертирует к пожеланиям пользователей.

Докладное добро

17 сентября 2019г. семейство московских тестировщиков под пиццу и напитки от ФИНАМ согрелось в подвале учебного центра вместо крыши идеями от Алексея Петрова и Андрея Мясникова.
Алексей проделал масштабную аналитическую работу, собрав в своей выкладке факты вертикальных и горизонтальных срезов за 10-15 лет. Подробно рассказал на собственных примерах как было и как стало в IT области. С большинством случаев слушатели активно соглашались, поскольку многих аналогичные пути привели к сегодняшним реалиям. Но, поскольку Алексей не мечтатель, то о подробном будущем пришлось угадывать самостоятельно. Лично меня посетила мысль, что профессия тестировщика уже не перспективна для желающих войти в IT. Об этом он упоминал ещё на SQADays-25 в докладе "Мексиканские страсти по мидлу": набор навыков и знаний требуется сейчас более высокий даже к юниору. Куда же стоит уже сейчас направить своё развитие? Полагаю, что учебным заведениям пора обзаводится курсом МОИР-ов (мастер обучения искусственного разума). И эту идею усилили прослушанные доклады с SQADays-25 "Когда научная фантастика становится реальностью тестировщика", "Расширяем идею статического анализа от проверки кода до других процессов разработки" и многие другие.
Согласно правилам развития, спираль неизбежна. Техники и инструменты тестирования развиваются также быстро, как и проверяемые продукты, технологии. Автоматическое code-review не только подсказывает, как правильно писать код, но и уже исправляет некоторые проблемы, например, фича Autofixes в ClearSQL. Искусственный интеллект явно в скором времени заменит тестировщиков. Если ещё недавно достаточно было иметь навык тест-чекера для начала, то через 5-10 лет "мартышками", по-моему, будут звать МОИР-ов.
В прошлых пятилетках следовали все waterfall-у, а сегодня поголовный agile. Завтра, думаю, наступит эпоха lean или "бирюзовых организаций". Ха, лозунг "Вперёд, к коммунизму!" весьма пророческий был и опять проявляется.
Алексей напомнил о зоопарке BTS, а мне припомнилось разнообразие и самописные комплексы по автоматизации документооборота (Галактика, Axapta, OEBS). Сегодня и те и другие выбрали одного, постоянного производителя. Или взять транспорт в Москве: ещё недавно в глазах рябило от рекламы в переходах и на корпусе машин, а сегодня все перевозчики объединились и живут на свои "живые" деньги. Это ли не принцип стабильности и процветания? Пусть мало и дёшево, но регулярно. А некачаственные конкуренты, не соблюдающие правило ВВС (критерии качества - верно работает, вовремя поставлено, сумма затрат), сами отвалятся. Регулярность выработки позволяет увеличивать срок планирования. Вот уже и гос.бюджет с годового планирования вырос до 5-20 летнего.
Да, мне не хватило мечтаний от Алексея. Но не только для того, чтобы сравнить их с реальностью через десяток лет, а для подсказок производителям тех технологий, на которых нам жить в следующих пятилетках.
Два доклада Андрея Мясникова, заменившего приболевшего Антона Семенченко, не вызвали моментально вопросов, но заставили серьёзно задуматься. Вроде бы из каждого проблемного угла был указан светлый путь, но почему-то логическая нить опять возвращалась. Андрей советовал записывать все контакты, но тем не менее утверждал, что всё равно в итоге всё повесят на тебя и ты же останешься виновным во всех грехах. Зачем поддерживать регулярный контакт с ответственным из смежной компании, если с обратной стороны нет взаимности и долгосрочных планов? Если вы раскрепощённый человек, то любую проблему можете решить не через личные связи, а напрямую с руководством смежников. А вот отношение Андрея к любителям сверхурочной работы меня порядовало. Хотя возможно, что не все причины (нравится занятие, увлёкся и не заметил, гипертрофированное чувство долга, нежелание спешить домой) ему известны. Но в любом случае, Андрей молится на своих энтузиастов, в отличие от шефа ConquestSS, который выгонял из команды ответственных сотрудников. Никаких тебе "спасибо" или мясниковских молитв и оплат, потому что для вечного стартапера привычнее пинать молодых и ему неведом принцип ошибки выживших.

ТО о SD 5.1.1.160

Очередной build#160 продукта SQLDetective (SD) 5.1.1 выложен 18 июля 2019г. Пройдёмся по Release Notes (RNs).

IMPROVEMENTS  (85+0+80)/3=55%   минус (2,6+1+0,2)=3,8 баллов

Code Explorer (0,9+0,8+0,9+0,8)/4 = 85% готовности, минус (1+0,3+0,3+0,5+0,5)/5=2,6 пунктов за баги
• By default, the Code Explorer panel is now always open in the SQL Editor and Stored Program Editor.
По-умолчанию панель Code Explorer теперь всегда открыта в редакторах SQL Editor и Stored Program Editor.
В надежде на лучшее будем полагать, что наличие раскрытой панели Code Explorer является дефолтным только для первого открытия редакторов, так как в SQL Editor она не всегда нужна, например, DML запросы в этом дереве показаны лишь одной нодой, поэтому ничем не упрощают работу программисту. Постараемся в тестах не путать понятия "открыт" и "развёрнут", поскольку первое управляется кнопкой на тулбаре или опцией в контекстном меню, а второе - сплиттером открытого дерева.
По результатам общего теста (смотри ниже) для всех новшеств блока Code Explorer текущий пункт получает 0,9 балла, потому что кнопка тулбара показывает верно состояние дерева только в SQL Editor.
• It is now possible to toggle the visibility of the Code Explorer panel for each module separately.
Теперь возможно переключать видимость панели Code Explorer  для каждого модуля раздельно.
Напомню, что панель Code Explorer предназначена для визуализации PL/SQL кода, поэтому её наличие ожидаемо в следующих модулях и окнах: Stored Program Editor / main editor, SQL Editor / code editor, Trigger Wizard / Trigger Body / code editor, Job Wizard / General / What Execute, Sched.Job Wizard / Program / Inline Program / PL/SQL Block / code editor, Sched.Program Wizard / General / PL/SQL Block. Причём в Stored Program Editor и Trigger Wizard дерево существовало давно, а в SQL Editor добавили в SD 5.0, но из Trigger Wizard дерево как бы пропало в SD 5.1, поскольку апдейт не включает новую настройку (чуть позже опишу баг).
В целом новшество реализовано, но описание не конкретизировало модули, поэтому даю 0,8 балла.
• The “Code Explorer” page was removed from Preferences.
Страница "Code Explorer" удалена из настроек приложения.
Странно, что этот пункт не в отдельном блоке Removes и не в блоке компонента Preferences.
Проверка этого новшества заключается в трёх тестах: 1) функциональный - визуально проверить отсутствие страницы в окне Preferences; 2) недоделки (функционально-регрессионный) - в окне поиска Preferences не должны появляться убранные элементы; 3) регрессионный - восстановление (загрузка из файла) настроек приложения из предыдущей версии не меняет функционал. Функционально-юзабилити тест на замещение необходимо было бы проводить при отсутствии следующего пункта RNs.
Тест новшества положителен, но за неточности техписателя даю 0,9 балла.
• Added the “Toggle Code Explorer” command to the SQL Editor, Stored Program Editor, and Trigger Wizard pop-up menus.
Контекстное меню редакторов в окнах SQL Editor, Stored Program Editor и Trigger Wizard дополнено пунктом "Toggle Code Explorer".
Техписателю стоило уточнить, что пункт добавлен в блок Tools, а также функционал продублирован в IDic.
Тест новшества положителен, но за неточности техписателя даю 0,8 балла.

Для проверки минимальной функциональности открываем каждое из окон в режиме "чистой установки" (удаляем все настройки приложения из файловой системы и реестра), затем переоткрываем окна с включенным и отключенным предварительно деревом в этой же сессии приложения, третий шаг - открытие модулей с перезапуском приложения.  Для теста нужна матрица:

Для просмотра кликните по элементу

Если вы заметили, то этой матрицей мы одновременно проверяем все вышеописанные новшества. Проверки состояния пункта Tools/Togle Code Explorer в контекстном меню, состояния кнопки переключения дерева на тулбаре, состояния дерева expanded-split также можно сделать параллельно, но для полной детализации стоит расширить матрицу соответствующими строками.
Примечания. Первое открытие приложения "на чистую" всегда сопровождается автоматическим открытием SQL Editor, поэтому влияние модулей друг на друга проверяем полностью, а не опираемся на первый кейс. Поскольку SD позволительно запустить множество раз на одной машине, а некоторые настройки приложения временно работают из оперативки, то не лишним будет тест в трёх параллельных сессиях приложения (не подключение к базе, а отдельные инстансы интерфейса).
Тесты дали в большинстве положительные результаты. Выявленные баги:
1. Опцию переключения дерева кода в Trigger Wizard перенесли в иное место хранения (внутрипрограммные заморочки), но не выполнили перенос значения опции при апдейте приложения. В результате - регрессионный баг функционала - старые пользователи "потеряли" дерево кода в Trigger Wizard. Почему не включили для новых пользователей? Первая гипотеза - забыли, вторая - посчитали излишним, третья - посчитали интерфейс и без того перегруженным. Минус 1 балл.
2. В редакторах PL/SQL кода таких окон как Job Wizard, Sched.Job Wizard, Sched.Program Wizard нет дерева кода. Если бы описание новшества было конкретизировано по модулям, то это не считалось бы багом, а предложением. Минус 0,3 балла.
3. Не упомянуты в RNs изменения экшена и его кнопки в рамках IDic. Баг малой критичности из области документирования. Минус 0,3 балла.
4. Состояние открытости дерева в Stored Program Editor и Trigger Wizard не совпадает с состоянием кнопки переключения на тулбаре. Примечание: этот же экшен корректно отображается в контекстном меню. Интерфейсный баг не высокой критичности. Минус 0,5 балла.
5. В мастере триггера выявлен баг, связанный с размерами окна. При переоткрытии окна не восстанавливается высота. К тому же, предлагаемая высота чуть больше рабочего пространства, что вынуждает приложение добавлять вертикальный скроллер. Минус 0,5 балла.

Text Editor -100% антивыполненности
• When there is no text occurrence of the searched text in the code, the user is no longer prompted to start searching from the top.
Юзеру больше не предлагают начать поиск с начала, если в тексте закончились места с искомым.
Во-первых, в SD существует два типа редакторов текста: SynEdit, встроенный в модули для редактирования кода, и стандартный редактор текста, используемый самостоятельным окном для показа, например, значений символьных полей. Во-вторых, в обоих поиск запускается по стандартному экшену (Ctrl+F, кнопка на тулбаре, пункт в контекстном меню) и должен итерационно продолжаться по тоже стандартному экшену (F3, кнопка на тулбаре, пункт в контекстном меню).
Тест на продолжение и окончание поиска показал, что в SynEdit функционал поиска остался неизменно удобным: продолжение поиска работает и, при достижении конца/начала текста, предлагает новую итерацию. А вот в простом редакторе текста (окно с результатами Schema Extractor или дополнительное окно для просмотра/редактирования varchar-поля) не то что выполнение следующей итерации с начала/конца текста перестало быть возможным, а даже обычное продолжение по F3 (нет кнопки Find Next на тулбаре и пункта в контекстном меню).
Мало того, что описание новшества не соответствует реализации, так ещё это можно назвать анти-юзабилити. Поэтому минус 1 балл.
В рамках комплексного тестирования выявлено западание окна с результатами множественных замен в тексте.

Для просмотра кликните по элементу

Online Support Desk (=OSD) 80% готовности
• Added the ability to reply to OSD messages from the “OSD Preview” window.
Добавлена возможность отвечать на OSD сообщение из режима предварительного просмотра.
Вспомним, что экшен Reply давно появился в списках сообщений. Но почему-то хотя бы в рамках новшества не убрали лишние пункты из меню для отправленных и удалённых, поскольку для черновиков пункта Reply нет в контекстном меню.
В режиме просмотра кнопка Reply активна для сообщений типа Received, но странно, что она не гаснет и для просматриваемого нового ответа. Да, для обычных новых сообщений кнопка в неактивном режиме, но ведь ответ - это тоже новое сообщение. Значит программист на каком-то этапе не допереключил флаг с Received на New, поскольку ещё раз ответ уже не генерится.
С учётом недоделок даю 0,8 балла.
В рамках комплексного тестирования вылезли следующие юзабилити-баги:
1. Минимальная высота окна такова, что все кнопки управления спрятаны. Для их нажатия приходится скроллить основной экран, что прячет информацию из заголовка сообщения. Моё предложение про необходимость сворачивать блоки существует (если шеф его не удалил) в базе багов очень давно, года с 2015-2016.
2. В форме нового сообщения-ответа (Reply) поле Text имеет два окна: не редактируемая пустая строка и основное окно. Эта пустая строка - лишний элемент, обычно показываемый для авто-формируемых сообщений из EurekaLog. Если её скрыть, то кнопки управления будут хотя бы наполовину видны.

Для просмотра кликните по элементу

BUGS FIXED  (100+0+75+90+50+100)/6=69,16%  минус (1+0,3+1+0,3)=2,6 балла

Code Explorer два бага исправлены на 100%, но за регрессию минус 1 балл
• Toggling the visibility of the Code Explorer panel in the Stored Program Editor no longer affects the SQL Editor and Trigger Wizard.
Переключение видимости панели дерева кода в Stored Program Editor больше не влияет на SQL Editor и Trigger Wizard.
Поясню. Раньше (до SD#5) Code Explorer был только в Stored Program Editor и Trigger Wizard, его видимость определялась по своим настройкам в каждом окне, но для Stored Program Editor был дубликат опции в настройках приложения. Когда в предыдущей версии Code Explorer добавили в SQL Editor, то его видимостью (а заодно и фильтрацией) заведовала общая опция с Stored Program Editor. Теперь, поскольку у каждого модуля есть самостоятельная опция переключения видимости, изменение её значения для одного окна не влияет на остальные два. Тест уже был проведён в рамках вышеописанных новшеств для Code Explorer - это тоже принцип комплексного тестирования, когда одним тестом закрываются и новшества, и баги по одному модулю. Ставлю 1 балл.
• The Code Explorer tree is no longer empty on first opening of the script.
Дерево Code Explorer больше не пустое при первом открытии скрипта.
Этот баг был актуален только для SQL Editor, поскольку для чистой закладки редактора дерево кода даже не подписывалось и воспринималось как лишнее окно. Баг исправлен и заслуживает 1 балл.
Но тест был бы не полным, если бы мы ограничились лишь одним модулем и не проверили пустые окна Stored Program Editor и Trigger Wizard. Открытие пустого окна и новой закладки в Stored Program Editor никакой регрессии не привнесло. А вот открыть новый Trigger Wizard с пустым редактором кода не было возможным в предыдущей версии (шаблон тела триггера вставляется автоматически). Попытки же создать новый триггер без предварительного выбора таблицы/вьювера оказались невозможными. То есть внесён баг регрессии: невозможно открыть мастер триггера для создания нового объекта из главного меню приложения и контекстного меню навигатора объектов без заведомо выбранного родительского объекта. Минус 1 балл.

Schema Compiler не более 0,5 балла
• An access violation error no longer occurs after compilation is completed.
Ошибка доступа больше не случается по окончании компиляции.
В качестве теста выполняем компиляцию схемы в предыдущем билде и текущем. Поскольку у меня не получилось отловить AV ни на особой схеме, ни на нескольких, ни на спец.режиме компиляции в предыдущих билдах, то заключаю, что это не исправление бага, а приписка. И поэтому ставлю 0,5 балла за возможное неполное описание техписателем.

Schema Extractor 90% из-за неполного описания
• The object list in the Schema Extractor is no longer empty.
Список объектов в экстракторе схем больше никогда не пустует.
Поясню: список объектов в Schema Extractor можно увидеть только если включена опция "Schema Extractor / Options / Preview list of objects before extract".  Поскольку она по-умолчанию включена, то для теста экспортируем любую схему в предыдущем билде и текущем. Из чего выяснилось, что раньше выгружались только триггеры, хоть и были выбраны все типы объектов. Так что баг исправлен на 0,9 баллов. Но меня смущает тот факт, что не исправляется не менее важная проблема - скорость, особенно для юзера без DBA привилегий. Schema Extractor работает в полтора раза медленнее Compare Schemas, а обычный юзер в два раза медленнее админского. Также был подмечен баг прятания модульного окна со списком объектов за основное окно приложения, если во время выгрузки переключаться на другие приложения.

Main Window 75% из-за регрессии
• When the “Show active session window only” option is enabled, objects of inactive sessions are no longer shown in the taskbar pop-up menu.
Объекты неактивных сессий больше не показываются в контекстном меню линейки задач при включенной опции "Show active session window only".
Поясню: опция "Show active session window only" переключается в главном меню "View / Active Session" или по кнопке главного тулбара в правом нижнем углу, а контекстным меню для описанного случая считается список не уместившихся кнопок на строке задач. Для теста, кроме включенной опции "Show active session window only" желательно включить опцию "Preferences / General / Task Bar / Dislay captions" и нет смысла включать опцию "Preferences / General / Task Bar / Combine buttons". При такой комбинации настроек надо сделать несколько подключений к базе (одинаковые или разные схемы), в которых открыть много мастеров объекта (любого типа, но проверить и пересечение типов, и наименований). Окна с фичей мультисессии (Stored Program Editor, Schema Extractor и другие) для теста не показательны, но могут дать баги при внутреннем переключении сессий, если это не было проверено при внедрении фич по визуальному разделению сессий и масштабированию панели задач.
В рамках воспроизведения бага на предыдущей версии выяснилось, что панель задач может вообще быть пустой для второго подключения базы. Так что фикс получился более широким, а техписатель коротким описанием принизил масштаб и важность исправления.
По результатам тестов можно отрапортовать о следующих багах:
1. Выполнение Close All для панели задач не учитывает режим показа кнопок только активной сессии. Для меня была неожиданностью пустота taskbar во второй сессии после выполнения Close All в рамках первой при включенной опции "Show active session window only".
2. В подписях кнопок (или хотя бы в хинтах) и пунктов выпадающего списка панели задач не хватает информации о сессии (connection string, color), особенно для окон с поддержкой мультисессионности. Понимаю, что это сложно реализовать для SmartDataset и Stored Program Editor, работающих одновременно с разными сессиями без фильтрации по ним. Но когда в нескольких SQL Editor ведётся работа по отдельным сессиям, то именно подобная подпись смогла бы улучшить интерфейс. На самом деле отсутствие хинтов - это баг регрессии, особенно если выключить опцию "Preferences / General / Task Bar / Dislay captions".
3. Анимация значков не работает в выпадающем списке панели задач. График двигается для модуля DB Monitor и давно ожидается для PL/SQL Profiler на кнопках taskbar. Но когда они в списке невидимых, то иконка модуля только статична.
4. Мультисессионные окна никак не реагируют на переключение между активными сессиями при включенной опции "Show active session window only".
5. Множественное открытие окон SQL Editor и Stored Program Editor для нескольких подключенных сессий в режиме включенной опции "Show active session window only" прячет окно Preferences на моменте его открытия.

Object Wizards 0%
• The “Compress data” check box no longer appears unavailable (grayed out) in the Index Wizard, Materialized View Wizard, Materialized View Log Wizard, Tablespace Wizard.
Чек-бокс "Compress data" больше не рисуется в недоступном режиме в мастерах объектов Индекса, Материализованного Представления, Лога материализованного представления, Табличного Пространства.
Во-первых, ни в одном из мастеров нет опции под названием "Compress data". Во-вторых, аналогично её нет и при выгрузке DDL (как-то промелькнула мысль, что техписательница опечаталась с модулями). В-третьих, в мастере сегмента есть опция компрессии, но это давно комбобокс, а не чек-бокс. В-четвёртых, комбобокс недоступен для изменений при значении Unavailable для компрессии объекта в рамках базы. Из чего заключаю, что этот фикс либо приписка из числа давно неактуальных багов, либо техписательница абсолютно неверно описала фикс. Не могу поставить даже полбалла.

User Wizard 100%
• The “Account Lock” check box no longer appears unavailable (grayed out).
Чек-бокс "Account Lock" больше не рисуется в недоступном режиме.
Стоит отметить, что вместе с опцией "Account lock", возможно в рамках текущего фикса, поправлена и соседняя "Password expire". Так что плюс в карму программиста, но минус в карму техписателя. А фиксу даю 1 балл.


Итого готовность билда: (85+0+80)/3=55% импрувами и (100+0+75+90+50+100)/6=69,16%  багами даёт 62% общей готовности.

ТО о SD 5.0.1.182

Отчёт о тестировании SQLDetective 5.0.1.182 (далее - SD), опубликованном 13 июня 2019 года. Проверки производились согласно пунктам Release Notes.

IMPROVEMENTS 0-1+1=0  из 1+1+1=3 возможных, -0.2-0.5=-0.7 за баги
SQL Editor  0 из 1 возможного
• Improved the workflow of the automatic determination of the execution plan.
Усовершенствован путь автоматического определения плана выполнения.
У данного пункта RNs весьма многозначный смысл. Либо речь идёт об утилите Explain Plan, которая является неотъемлемой частью SQL Editor. Либо речь идёт об автоматическом подборе настроек из числа "Preferences / General / Session", касающихся версии базы данных. Либо речь идёт о сугубо внутреннем программном коде, который производит общение приложения с базой данных (DOA - пакет Delphi, осуществляющий взаимосвязь базы данных Oracle с интерфейсом SQLDetective). В любой из трёх моих гипотез что-либо проверить по имеющемуся тексту RNs не представляется возможным, вернее, исследовать можно бесконечно долго и много. Поскольку тех.писательнице не разъяснили конкретику новшества, то считаю этот пункт припиской и не дам ни балла.
Database Monitor -1 из 1 возможного, за баг комплексного теста -0.2 балла
• Queries now run in a sequence, not in parallel threads.
Запросы теперь запускаются последовательно, а не в параллельных потоках.
Утилита мониторинга базы позволяет отслеживать множество процессов с точки зрения её администратора. Не могу согласиться, что для ускорения выполнения запросов их последовательное выполнение более удобно, да и для истинного мониторинга некоторых процессов более точные данные получаются при параллельном обследовании. Поэтому считаю данное новшество вредным усугублением функционала и снимаю балл за исполнение. Более полезным было бы введение опции для каждого из графиков, при значении которой администратор базы сам бы выбирал очередь или параллелизацию выполнения запросов для мониторинга процессов. Хотелось предложить проверить функционал внутренними средствами (Session Navigator, DB Examiner / Top SQL), но Session Navigator во всех билдах 5-й версии не работает, то есть открывается пустое окно после ошибки базы "ORA-29275: partial multibyte character", а в списке последних выполненных запросов "DB Examiner / Top SQL" не видно изменение параллелизации на последовательный запуск. К сожалению, в старых версиях SD (4.7, 4.4) модуль Session Navigator тоже не показывает, что запросы монитора базы выполнялись в параллельных нитях (не дополнительные сессии). За давний не исправленный баг соседнего модуля есть смысл снять -0.2 балла.
PL/SQL Debugger  1 за исполнение, -0.5 за баг
• Added the ability to view global variables.
Добавлена возможность просматривать глобальные переменные.
Поскольку пункт RNs в группе дебаггера PL/SQL кода, то речь идёт о глобальных переменных в рамках, например, пакета. Для теста создадим спецификацию и тело пакета в базе любой версии с глобальными и локальными переменными.
CREATE OR REPLACE PACKAGE glb_prm_pkg
AS
prm1_glob date;
  procedure proc_1 (prm2_local in number);
END;
CREATE OR REPLACE PACKAGE BODY glb_prm_pkg
AS
  procedure proc_1(prm2_local in number) IS
  BEGIN
 prm1_glob := sysdate + prm2_local;
  END;
END;
Затем добавим их в список просматриваемых (Stored Program Editor / Watches), и в режиме включенного дебаггера (Session / PL/SQL Debugger / Start) в пошаговом исполнении одной из подпрограмм пакета посмотрим на значения переменных в текущем и предыдущем билдах SD. Также посмотрим на значения переменных через контекстное меню "Stored Program Editor / PL SQL Debugger / Evaluate Modify", через хинт (при включенной опции "Preferences / PL SQL Debugger / Tooltip expression evaluation") переменной при наведении курсора на её имя в области редактора кода. Предыдущий билд глобальную переменную везде отображал как необъявленную, хинт для неё не срабатывал, а значение локальной переменной не изменялось при пошаговом исполнении в хинте и списке Watches. Обе переменные подвешивали навсегда приложение при попытке просмотреть их значение через контекстное меню "Stored Program Editor / PL SQL Debugger / Evaluate Modify" - это серьёзный баг, почему-то до сих пор не выявленный группой разработки. Получается, что в рамках новшества был исправлен баг несменяемости значения наблюдаемой локальной переменной, но упущен из виду один из способов просмотра значения переменных. Поэтому пункт RNs получает 1 балл за исполнение и теряет -0.5 за критичный (нет вариантов обхода ошибки, приложение закрыть получается только через Диспетчер Программ) баг. Примечание к багу: пункт контекстного меню активирован в режиме запущенного дебаггера, но не выделенного курсором текста. Вероятная причина бага - парсер не в состоянии определить границы имени переменной для передачи в последующий модуль.

BUGS FIXED  0.8+1.5+0+1+0.8+0+0+0+0.8=4.9  из 1+3+1+1+1+2+1+1+1=12 возможных, -0.5-0.4-0.2=-1.1 за баги
Code Editors  0.8 из 1 возможного
• The cursor, when moved using the Ctrl+arrow keys combinations, no longer breaks on pointing to the dollar and number signs.
Курсор при его перемещении комбинацией клавиш Ctrl+стрелка больше не сбивается на символах доллара и цифр.
Для тестов нам понадобятся строки с символами доллара и цифр в разных местах: до и после пробела (а также переноса строки, табулятора, дефиса, подчёркивания), самостоятельные, комбинированные с другими символами. К редакторам кода относятся многие окна приложения, но достаточно проверить один Stored Program Editor, поскольку комбинация клавиш срабатывает в едином интерфейсном элементе SynEdit из числа Delphi возможностей, на котором написан продукт. Вполне вероятно, что ваш текст для теста поможет обнаружить и другие символы, препятствующие ожидаемой работе комбинации клавиш. Разница между кликами в предыдущем и текущем билдах заметна на строках с символом доллара, но не на цифрах, поэтому фикс получает только 0.8 балла.
PL/SQL Debugger  1+0+0.5=1.5 из 3 возможных
• The error message “Unhandled exception occurred. Debugger will be terminated.” no longer appears after an Oracle exception error is raised.
Сообщение об ошибке про уничтожение дебаггера больше не появляется после срабатывания исключения ошибки базы.
Поскольку ошибка исключения не конкретизирована, то для теста попытаемся воспроизвести его на вышеупомянутом коде. Запустим отладку пакетной процедуры, предварительно добавив блок исключений (перекомпиляцию выполним без отладчика - просто Ctrl+F9) и не задав входного значения. Да, предыдущий билд сообщал о разрушении дебаггера, тем не менее не отключал его. Фикс выполнен и получает балл.
• Unexpected error messages no longer appear if a breakpoint is set to an illegal line.
Сообщение о неожиданной ошибке больше не появляется, если точка остановки поставлена на незаконной строке.
Какие строки считаются недопустимыми для точки останова? Например, декларативная часть или разбитое на несколько строк выражение присваивания. К сожалению, мне не удалось получить неожиданную ошибку в предыдущем билде, поэтому этот пункт RNs считаю припиской и не даю балл.
• Variables are now automatically applied to the script during its execution.
Переменные теперь автоматически применяются в скрипте во время его выполнения.
О каком скрипте речь? У меня на уме два места: скрипт самой отлаживаемой подпрограммы и скрипт для отладки, формируемый в окне "Stored Program Editor / Stored Program Execution" по кнопке "Generate PL/SQL for object execution" и автоматически на открытии этого окна. Скрипт самой подпрограммы визуально не изменяется, но значения локальных переменных стали отображаться в списке Watches. Также без каких-либо изменений отображается скрипт в окне "Stored Program Editor / Stored Program Execution". Поэтому фикс получает лишь 0.5 балла за введение юзера в заблуждение подобным описанием.
SQL Editor 0 из 1 возможного
• Fixed the work of the “Bytes per character” option when it is set to “Autodetect".
Исправлена работа опции "Байт на символ", когда она установлена в автоопределение.
Переключение опции "Байт на символ" доступно на странице "General / Session" настроек приложения Preferences. Почему этот пункт RNs в группе SQL Editor - для меня загадка, потому что применение опции разбросано по всему приложению, начиная от мастера таблиц, ячеек гридов и кончая всеми редакторами и окнами, отображающими данные UTF-базы. В тексте фикса не уточняется, как именно неверно определялась пропорция: не бралось в учёт какое-то значение базы из числа параметров инициализации, либо шрифт для отображения символов в SQL Output или ячейках грида неровно форматировался, а может и что иное. Поэтому попытаемся найти разницу в отображении UTF-символов только в SQL Output закладке окна SQL Editor. В качестве теста выполним запрос с различной шириной символов:
select 'м и ш - русский текст' as fld from dual
union
select 'Ш и М - текст русский' as fld from dual
union
select 'РусскийТекст -  М и Ш' as fld from dual;
в грид и текстовый вывод при различных значениях опции на любой базе, вне зависимости от её версии и utf-инсталляции. Разницы между результатами в предыдущем и текущем билдах не обнаружено, поэтому пункт RNs не получает ни балла.
Object Navigator 1 из 1 возможного
• The error “Invalid SQL statement” no longer occurs on trying to expand the Editions node.
Ошибка неверного SQL выражения больше не случается при попытке развернуть ноду Editions.
В нескольких предыдущих билдах SD на базах, поддерживающих редакции объектов, действительно был выявлен этот баг. В текущем билде доступ к списку редакций осуществляется без проблем. Фикс получает балл.
Database Monitor  0.8 из 1 возможного
• Slow SQL statements for blocked and blocking sessions now run faster in Oracle Databases 11.2. The fix also affects the Session Navigator.
Показ блокированных и блокирующих сессий теперь осуществляется быстрее в базе версии 11.2. Фикс также осуществлён и в навигаторе сессий.
В мониторе базы два графика блокированных данных отображаются на закладке Activity. В навигаторе сессий для слежения за блокированными данными сформировано три грида на закладке Locks. Для тестов воспользуемся внутренней утилитой "DB Examiner / Top SQL" и сравним значения Optimizer Cost, CPU Time, Elapsed Time для запросов
SELECT SUM(Decode(B.BLOCKER, 'YES', 1, 0)) BLOCKING, SUM(Decode(S.BLOCKING_SESSION_STATUS, 'VALID', 1, 0)) BLOCKED FROM SYS.V_$SESSION S   , ( SELECT DISTINCT SID BLOCKER_SID         , 'YES' BLOCKER       FROM V$LOCK       WHERE BLOCK=1         AND 0=0     ) B WHERE 0=0   AND B.BLOCKER_SID(+) = S.SID;
/
SELECT SUM(DATA_BLOCKS_READ) DATA_BLOCKS_READ, SUM(DATA_BLOCKS_WRITE) DATA_BLOCKS_WRITE, SUM(TEMP_BLOCKS_READ) TEMP_BLOCKS_READ, SUM(TEMP_BLOCKS_WRITE) TEMP_BLOCKS_WRITE FROM ( SELECT /*+ NO_MERGE */ SUM(PHYBLKRD) DATA_BLOCKS_READ, SUM(PHYBLKWRT) DATA_BLOCKS_WRITE, 0 TEMP_BLOCKS_READ, 0 TEMP_BLOCKS_WRITE FROM SYS.V_$FILESTAT S WHERE 0=0 UNION ALL SELECT /*+ NO_MERGE */ 0, 0, SUM(PHYBLKRD) TEMP_BLOCKS_READ, SUM(PHYBLKWRT) TEMP_BLOCKS_WRITE FROM SYS.V_$TEMPSTAT S WHERE 0=0 );
/
в процессе работы DB Monitor. К сожалению, не получится увидеть фикс в Session Navigator, так как он не показывает никаких данных из-за вышеописанного бага. В рамках комплексного тестирования обнаружен баг в DB Examiner, который перестал дублировать полный и форматированный текст ячеек столбца "SQL Text". Но поскольку один из запросов в мониторе базы был оптимизирован до
SELECT SUM(DATA_BLOCKS_READ) DATA_BLOCKS_READ, SUM(DATA_BLOCKS_WRITE) DATA_BLOCKS_WRITE, SUM(TEMP_BLOCKS_READ) TEMP_BLOCKS_READ, SUM(TEMP_BLOCKS_WRITE) TEMP_BLOCKS_WRITE FROM ( SELECT /*+ NO_MERGE */ SUM(PHYBLKRD) DATA_BLOCKS_READ, SUM(PHYBLKWRT) DATA_BLOCKS_WRITE, 0 TEMP_BLOCKS_READ, 0 TEMP_BLOCKS_WRITE FROM SYS.V_$FILESTAT S WHERE 0=0 UNION ALL SELECT /*+ NO_MERGE */ 0, 0, SUM(PHYBLKRD) TEMP_BLOCKS_READ, SUM(PHYBLKWRT) TEMP_BLOCKS_WRITE FROM SYS.V_$TEMPSTAT S WHERE 0=0 );
то пользователи смогут заметить ускорение. А мы, как тестировщики, можем это подтвердить сравнив планы исполнения. Фикс получает 0.8 балла из-за наличия блокера в Session Navigator для полной проверки.
DDL for Scheduled Jobs  0+0=0  из 2 возможных, -0.4-0.1=-0.5 за проблемы
• Replaced single quotes with double quotes in the attribute statement event_condition => ‘TAB.USER_DATA.EVENT_TYPE = ‘‘JOB_OVER_MAX_DUR’‘’.
Заменены одинарные кавычки на двойные для атрибута выражения в сложносоставном условии события.
Для проверки фикса откроем мастер задач по расписанию и попробуем создать задание со сложным условием события. Для этого на странице Schedule  выберем "Inline Schedule" и "Event". В блоке Event выберем любой имеющийся объект, например, очередь в схеме SYS. Теперь можем формировать сложное условие для события через мастер формул. И тут выясняется, что все символьные строки мастер формул обрамляет только в одинарные кавычки. А это значит, что фиксить стоило не последствия (формирование DDL), а причину (интерфейс продукта). Никак не получится отметить фикс. А за давнишний прокол в мастере формул ещё и сниму -0.4 балла.
• DDL now generates with a correct attribute value RAISE_EVENTS => JOB_OVER_MAX_DUR.
Скрипт на создание задачи по расписанию теперь генерится с корректным значением JOB_OVER_MAX_DUR атрибута RAISE_EVENTS.
Указанный атрибут бывает с подобным значением в базе версии ниже 11, которой нет в моём распоряжении. Поэтому и невозможно выяснить, что же конкретно тех.писательница считала некорректным в предыдущем билде. Но попутно выяснились интерфейсные проблемы мастера задания по расписанию.

Клик по троеточию позиционирует новое окно, не выровняв его по ресурсному элементу

На странице General можно выбрать события из списка, который открывается в неожиданном месте, перекрывая зону вызова при минимальных размерах мастера, окно не выровнено ни по одному из элементов, что сбивает юзера с толку - не понятно для какого видимого элемента предназначен выбор значений. Пункту RNs не дам ни балла из-за пространного описания, а за интерфейсные проблемы сниму -0.1.
Installer/Updater  0 из 1 возможного
• Fixed the installation procedure on a 32-bit Windows OS.
Исправлена процедура инсталляции на 32-битную систему Windows.
К сожалению, тех.писательница не удосужилась уточнить причину проблемы, а инсталлятор и апдейтер не показали никакой разницы в стандартной функциональности. Поэтому пункт RNs не получает ни балла.
Profiler Wizard   0 из 1 возможного
• The settings to set/modify password parameters in the Profile Wizard are no longer missing.
Установка выставления и изменения параметров пароля в мастере профиля больше не пропускается.
Поскольку Профиль - объект не схемный, то подключиться к базе для тестирования надо с админскими правами. Визуально мастер профиля в предыдущем и текущем билдах не отличается, поэтому для выяснения того, ЧТО пропускалось, создадим как минимум два объекта - со значениями по-умолчанию и любыми другими. Перед созданием объекта просмотрим внимательно скрипт на создание объекта, а после его создания сгенерим DDL и их тоже сравним по билдам и исходникам. Поскольку никакой разницы ни в чём не обнаружено, то могу смело заявить, что в предыдущем билде ничто не пропускалось, а пункт RNs является припиской и не получает ни балла.
Scenes  0 из 1 возможного, -0.4 за баги
• An access violation error no longer occurs on trying to save the default scene after reconnecting a session.
Ошибка доступа больше не случается при попытке сохранить декорации по-умолчанию после переподключения сессии.
Часть навигатора объектов ContentSelector умеет сохранять и восстанавливать закреплённые закладки, что разработчиками SD названо "декорациями" этого окна. Набор закладок можно сохранить в декорацию по-умолчанию или в названную по-иному. Поскольку декорации схемо-зависимые, то для теста в предыдущем и текущем билдах подключимся поочерёдно к одной и той же сессии, закрепим одну-две закладки, выполним переподключение к базе и затем сохранение декорации. Если в предыдущем билде не получается воспроизвести ошибку доступа, то обнулим сохранённую декорацию (быстрый способ - удалить файлы "SD_ON_Scene*.*" из папки "%AppData%\Roaming\SQLDetective\Data\"; рабочие действия - включить только Default декорацию, в среднем окне проверить, что нет закреплённых закладок, иначе - открепить их). Примечание: оба билда для точности проверки нельзя запускать одновременно на одной машине, либо тесты проводите последовательно, либо на разных машинах, чтобы настройки приложения не наложились друг на друга. У меня никак не получилось воспроизвести ошибку доступа, проделывая в точности описанные шаги при различных значениях опций "Preferences / General / Object Navigator / Restore open scenes" и "Preferences / General / Object Navigator / Automatically save modified scene". Но в обоих билдах выявлен интерфейсный баг не ожидаемой работы чек-бокса: декорация по-умолчанию выключается при переподключении к базе "Session / Reconnect", включается при отключении от базы "Session / Disconnect" или при запуске приложения с подключением к базе. Изменённая декрация по-умолчанию всегда сохраняется вне зависимости от опции "Preferences / General / Object Navigator / Automatically save modified scene". Так что пункт RNs никак не может считаться сделанным и не получает балл, а за выявленные баги в работе опций снимаю -0.4 балла.
Preferences  0.8 из 1 возможного, -0.2 за баг
• Fixed local sorting of numeric columns when the “Display Numbers” option is set to “Numeric”.
Исправлена локальная сортировка числовых колонок, когда опция показа числовых значений выставлена в Numeric.
Опция показа числовых значений расположена на странице "Preferences / General" и распространяет своё действие в основном на гриды данных базы. О разнице локальной и серверной сортировки почитайте статьи "Preferences – Dataset Editors" и "Dataset Editors – Data sorting" хелпа приложения. Для тестов воспользуемся гридом Objects в навигаторе объектов, который доступен и всегда имеет необходимые для нас данные (числовые, символьные и другие поля) вне зависимости от версии базы. В предыдущем билде локальная сортировка числовых колонок при любом значении их отображения выполнялась как для символьных: сначала все, начинающиеся с 0, потом с 1 и так далее, вне зависимости от размерности чисел. В текущем билде локальная сортировка воспринимает числовые поля, как цифры со своей разрядностью, а не буквенно-числовые символы. Фикс сделан, но описан в RNs с запутыванием юзера (лишнее упоминание о настройке), поэтому получает только 0.8 балла. В процессе тестов проявился баг в порядке сортированых полей после смены серверной и локальной сортировок: открыть набор данных, отсортированный по одному полю серверно - одно поле первого порядка серверной сортировки; трижды кликнуть по несортированному полю для выставления/смены/снятия локальной сортировки - одно поле первого порядка локальной сортировки; выставить на этом же поле серверную сортировку - её порядок серверной сортировки не 2-го порядка, а неожиданно 3-го. То есть какие-то из кликов не обнулили флаг расчёта порядка серверной сортировки или локальная добавила лишний клик в соседский флаг. За баг сниму -0.2 балла.

Итого по билду: 0+4.9=4.9 баллов из 3+12=15 возможных дают 4.9/15=32% готовности и теряет -0.7-1.1=-1.8 балла.

Балловая связь

Чиновники для народа

Общественность постоянно сетует на работу чиновников: и не слышат они народ, и взятки берут. Уж и законы об обращениях граждан на них насылали, и штрафы взяточникам взвинтили, а они всё равно рвутся занять должность "слуги народа", чтобы жить по-царски. А может сами подчинённые и избиратели виноваты в том, что продвигаются не те проекты, которые нужны? Как повысить активность граждан? А может подношения вышестоящие воспринимают как необходимую благодарность, которую не получают после окончания дела? Как воспитать всех отзывчивыми? Почему же власть портит людей? Даже мелкую сошку, бригадира или начальника подотдела не узнать через несколько месяцев верховенства. Может они всё время ждут благодарности за свой труд и грустят от неблагодарности "свиты"? Или гордыня затмеваем им основную идею лидерства - вести за собой и опекать подчинённых от неприятностей? А ведь даже родители взращивают своих детей, чтобы в старости было кому поднести стакан воды. Значит и руководитель всегда ждёт своей доли благодарности, и не в виде зарплаты, а чисто по-человечески.
Можете ли вы представить себе, что цифровая экономика и демократия способны воспитывать общество в целом и каждого в частности? При этом можно искоренить кумовство и взяточничество, снизив до нуля человеческий фактор ошибок. И решается проблема довольно просто: небольшое дополнение к закону об обращениях граждан и введение автоматической аттестации для всех уровней руководящего состава.
Техническая реализация заключается в следующем. Дополняем закон об обращениях граждан обязательным завершающим пунктом для выставления отметки об исполнении запроса обратившегося. Для этого предварительно дублируем (переводим) весь оборот обращений и ответов в электронный вид. К сожалению, на этом этапе нет полной автоматизации, так как кроме электронных писем и специализированных форм обратной связи на сайтах существуют очные письменные и устные способы общения, телефонные звонки и смс, посты в соц.сетях и публикации в СМИ.  Но любой разговор всегда можно записать и оцифровать, а бумажные формы отсканировать в цифровой вид. Поэтому будем считать, что все входящие реально регистрировать в электронной базе. Объём обращений можно лимитировать, автоматически рассчитывая пропорцию рабочего времени руководителя и количества подопечных. Например, при 40-часовой рабочей неделе и минимуме в 15 минут на визит мэр города с 5 тысячами полноправных жителей сможет максимально обработать около полутора (4*40*52/5000=1,664) обращений в год от каждого, но не более 8320 (=4*40*52, где 4 - количество обращений в час, 40 рабочих часов в неделе, 52 недели в году без отпуска) всего в год. Соблюдать уникальность обращений и их инициаторов объективно может только электронная база данных. Она же станет и беспристрастным оценщиком исполнительности. Обязав заявителей отправлять электронно отзыв о выполненности или отказе, можно собирать статистику по каждому начальнику и автоматически выставлять им рейтинг. Эта же система самостоятельно будет контролировать исполнение. Например, гражданин подал срочную заявку, которую зарегистрировали в базе (присвоили уникальный идентификатор, завели данные гражданина - паспортные и телефон, суть обращения, дату обращения и высчитан крайний срок исполнения). Если исполнитель уложился в срок, то система отправляет заявителю СМС (исполнена ли заявка, удовлетворены ли ответом/отказом) с обязательным ответом (0 - нет, 1 - да), или автоматическое электронное письмо, или телеграмму обычной почтой. Если исполнитель не уложился в срок, то система автоматически добавит заявку в отрицательный список рейтинга начальника. Если исполнитель всё исполнил, но заявитель не удовлетворён исходом дела, то отвечает "0" и он влияет на негативный рейтинг начальника. Если дело исполнено благополучно, то заявитель улучшает рейтинг начальника. На этом этапе сами исполнители будут бегать за заявителями с просьбой положительного отзыва. И здесь заявителю придётся проявить собственную гражданскую ответственность и объективность. Такой переворот отношений между заявителем и исполнителем поднимет активность граждан, наладит диалог, будет воспитывать отзывчивость, сблизит общение чиновников и общества, приучит говорить "спасибо" даже столь неприятным до селе чиновникам. Поскольку рейтинг конкретного исполнителя будет зависеть от каждого обращения, то чиновники реже станут перенаправлять заявки на иные инстанции и реализовывать собственными силами в положеный срок. Но поскольку менталитет у всех таков, что "не подмажешь, не поедешь", то вполне возможно исполнители начнут предлагать взятки заявителям за положительные отзывы. Поэтому наказания взяточников неизбежны, если каждый гражданин не перестанет контролировать самого себя, хотя подачки поменяют размер и направление. Таким образом чиновника по факту превратятся в слуг народа.
Современные технологи позволяют разделить базы заявок и отзывов, а агрегированные данные вполне можно опубликовывать. Процент выполненных заявок можно раскрасить их объёмом, как это подсчитывается в спорте (кмс, чемпион, чёрный пояс и т.д.), взяв процент от максимального объёма. И в этом случае объективность будет соблюдена за счёт лимита уникальных обращений от каждого заявителя.
Рейтинг руководителей, опубликованный в общем доступе, регулярно и независимо обновляемый, станет не только мерилом ответственности, но и гарантом доверия. Результаты ежечасной работы сложатся в профиль кандидата на вышестоящий пост, либо вовремя покажут причину снятия с должности или необходимость дотаций, внешней помощи.
Аналогичную систему предлагаю и для аттестации руководителей всех уровней. Очень много в стране компаний, на руководящие должности в которых поставлены работники без знаний КЗоТ или с недостатком навыков управления персоналом. В советские времена профсоюзы повышали такой уровень в спец.школах и на курсах. Но сейчас организациям приходится тратить собственные средства на обучение. И поскольку это дорого, то компании экономят на развитии трудовых ресурсов. Если же руководителей всех уровней можно было бы сертифицировать и регулярно аттестовывать, то такой контроль заставил бы начальников знать законы и уметь применять техники руководства. Аттестацию вполне логично возложить на комиссии по трудовым спорам и центры занятости населения. Комиссии по трудовым спорам могут составлять независимые рейтинги на основе обращений работников, количестве увольнений и предотвращённых сокращений штата. А центры занятости могут проводить экзамены на знание КЗоТ и умение применять техники управления персоналом. Сертификацию руководителей можно сравнить с техосмотром автомобилей - отсутствие грозит штрафами, а наличие гарантирует спокойствие подчинённых. Если в этой системе обращения работников в комиссии по трудовым спорам будут бесплатны, а расходы на рассмотрение споров будут оплачивать начальники, то задержки зарплат, сокращение штата и беспричинные увольнения уйдут в небытие. А значит у центров занятости уменьшится объём работ по подбору вакансий и это время распределится на аттестации, организацию курсов. Главным плюсом сертификатов воспользуются кандидаты на замещение вакансий.

Дорогие trivial-ы

В распределённой команде руководитель время от времени поставляет тривиальные баги команде тестировщиков. Но самому их вносить в систему учёта багов ему лень. А поскольку команда общается посредством Slack, то картинки постятся в чат, часто без пояснений о конкретном месте проблемы, мол: "Ищите сами, всё же видно!" Ещё ситуацию усугубляет серверная версия Jira без выхода в Инет. Билд с фиксом шеф обычно желает получить мгновенно, так как считает такие баги "пятиминутками". Но в 5 минут никогда невозможно уложиться.

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

Bug Reporter	Tester	Bug Fixer
3-5 мин на снятие screen shot, редактирование и вставку в Slack	1-3 мин на чтение чата и понимание проблемы (где происходит, как получить, в чём собственно проблема)	1-3 мин на чтение и понимание проблемы (где происходит, как править)
10-30 мин на собственное возвращение к прерванной работе	10 мин – 2 часа на воспроизведение в разрабатываемом билде и опубликованном	5 мин правка и submit в систему контроля версий
	опционально: 30 мин на выяснение подробностей с репортером	10 мин – 2 ч проверка в скомпиллированном приложении
	10 мин на пересылку оригинала screen shot из Slack в локальную сеть с Jira	10-30 мин на собственное возвращение к прерванной работе
	3-10 мин оформление задачи в Jira
	10-30 мин на собственное возвращение к прерванной работе
	10 мин – 2 ч проверка после правки
	опционально: 20 мин оформление возврата, разночтений и последствий недоправок, недопроверок
13-35 мин	44 мин – 5 ч 43 мин	26 мин – 2 ч 38 мин

Итого, на одну "пятиминутку" требуется от 1 ч 23 мин до 6 ч 56 мин общекомандного времени.
Сократить перерасход времени можно за счёт регулярной проверки новооформленных задач одним или несколькими сотрудниками QA. При этом нет необходимости отрываться от текущих дел, так как на new-task-review обычно уходит 10-20 минут ежедневно в рамках регулярных запланированных работ, а правка и проверка задач тоже в планах всей команды и нет необходимости отрывать кого-то от текущих дел.

Bug Reporter	Tester	Bug Fixer
3-5 мин на снятие screen shot, оформление и вставку в Jira	1-3 мин на чтение и понимание проблемы в рамках проверки задач Jira	1-3 мин на чтение и понимание проблемы (где происходит, как править)
10-30 мин на собственное возвращение к прерванной работе	10 мин – 2 ч проверка после правки	опционально: 30 мин на выяснение подробностей с репортером
	опционально: 20 мин оформление возврата, разночтений и последствий недоправок, недопроверок	5 мин правка и submit в систему контроля версий
		10 мин – 2 ч проверка в скомпиллированном приложении
13-35 мин	11 мин – 2 ч 23 мин	16 мин – 2 ч 38 мин

При таком раскладе затрачивается от 40 мин до 5 ч 36 мин общекомандного времени на "пятиминутку". Экономия – от 43 мин до 1 ч 20 мин.