QA, QC или иначе

На примере отношений тестировщика с программистом хотелось бы уточнить разницу между должностями QA и QC. Соглашусь, что многие тестировщики в своих блогах касаются этой темы. Да и у меня уже была слабая попытка (читай - "Тестировщик или QA"). Ни в коей мере не хочу дублировать их или утверждать, что моё мнение по этому вопросу единственно верное и окончательное. Просто каждый из нас, тестировщиков, стремится разъяснить понятия и принципы работы ПО так, как это более доступно обеим сторонам производства ПО от точки проверки качества: вправо - программисту, влево - пользователю. Да, это профессиональная привычка - делать всё понятным и доступным. ;)
Капитан Врунгель, отправляясь в плавание, напевал: "Как вы лодку назовёте, так она и поплывёт.", а будущие специалисты, желающие внедриться в сферу информационных технологий, частенько встают в тупик при выборе вакансий. Какую должность искать? Что вбивать в строку поиска, кроме принадлежности к IT-сфере?
На мой взгляд войти в IT можно легко, если начинать с мелкого. Раньше, годах в 1980-90х, существовала специальность "оператор ПК", но когда компьютерной грамотностью овладело всё работоспособное население, то в этой должности отпала необходимость также, как и в машинистках. Нажимать на клавиши сегодня может любой, понимающий принцип хранения информации. А с приходом искусственного разума стало возможным преобразовывать звук в печатный текст, то есть даже по клавиатуре клацать уже не требуется. Этот факт, конечно, ускоряет процессы производства, но и лишает человека занятия мелкой моторикой, что в значительной мере напрямую влияет на мозговую деятельность, то есть замораживает мыслительные процессы через атрофирование нервных окончаний. Но, сегодня я не об этом.
Инженеры по тестированию программного обеспечения (должность в реестре России зарегистрирована с мая 2014 года), а в простонародье - тестировщики, бывают разные: ручники и автоматизаторы, безопасники и нагрузочники, исследователи и производственники, да ещё всякие разные. Поначалу, всех называли просто "тестировщиками", но не "тестерами", потому что второе имя означает прибор, например, - амперметр или индикаторная отвёртка, а не такое, более сложное существо, как - человек. Тестер-прибор показывает довольно быстро информацию о том, работает ли проверяемая конструкция правильно, то есть в ожидаемом режиме, к тому же в большинстве случаев даёт количественные показатели. Например, спиртометр указывает процент сахара и алкоголя в сусле при брожении будущих напитков, а вольтметр - наличие заряда в батарейке.
Исходя из истории возникновения профессии тестировщика (плата не отработала задумываемым образом из-за погибшего на ней мотылька) могу убедительно утверждать, что первейший принцип тестирования ПО - исследование причин, по которым ПО не работает ожидаемым путём. А это совершенно иное, нежели простое измерение величины или детекция наличия/отсутствия контакта, давления, электричества прибором, именуемым - тестер. Да, нашу работу тестировщиков постоянно хотят измерить количеством багов, затраченным временем или финансовыми сбережениями, но эти показатели совершенно иная сфера, нежели простые величины стрелок и шкал приборов-тестеров.
Ещё не так давно появилось разделение тестировщиков на QA и QC. Расшифруем, переведём и попытаемся найти меж ними отличия. Quality Assurance - обеспечение качества. Quality Check - проверка качества. Как видно из наименований, должности различны по своему предназначению. Тестировщики, только проверяющие качество (QC), наиболее схожи с сотрудниками отделов технического контроля (ОТК), которым на входе подают изделия и список требуемых соответствий определённому уровню качества. После того, как в ОТК заполнены чек-листы, проставлены в них положительные галочки, вычеркнуты отрицательные (негативные) несоответствия, заполнены параметры проверки (что проверялось, кто и когда проводил проверку, конкретизация продукта и вспомогательного оборудования), сотрудник ОТК передаёт такие ведомости в производство или сбыт для подтверждения качества, либо направляет претензии к поставщикам и промежуточным производителям в случае выявления несоответствий требуемому качеству. Если же тестировщик, кроме вышеперечисленного для QC (проверка по готовому чек-листу, подтверждение уровня качества, составление претензий о несоответствии уровню качества) сам определяет направления проверок, формулирует параметры качества, исследует весь цикл производства и внедряет дополнительные шаги, либо исключает лишние, для предотвращения проблем как в конечном продукте, так и в процессе производства, способствует внедрению наиболее совершенных практик для достижения качества продукта, то такого специалиста я со всей ответственностью могу назвать QA. Но вот уже чуть больше года в реестре вакансий мелькают такие названия, как DevOps и TestOps. Они расширяют полномочия QA до уровня всей команды разработки. Если путь от QC до QA считать вертикальным продвижением по карьерной лестнице, то от QA до TestOps (сокращение от "Testing + Operations", что в переводе - "тестирование + системное администрирование") - горизонтальным обогащением профессионализма на всех уровнях производства.

Наименования графикой

Визуально для меня QC представляется палочкой или латинской буквой "I". Её ассоциирую со словом "Inside", потому что QC зациклен лишь в тестировании, смотрит только в одном направлении. Он не точка, потому что в любом случае набирается и опытом, и знаниями. QA же специалист в моих глазах представляется буквой "T", где в вертикальной палочке накопились умения в области тестирования, а ответвления вправо и влево означают развитие в смежных областях: программирование, аналитика, внедрение ПО и поддержка юзера. Буквой "Т" начинается слово "Transform", то есть QA в состоянии менять себя и окружающие процессы. А TestOps видится мне буквой "E", с которой начинается слово "Extend". TestOps расширяет себя и всю группу разработки на всех ступенях, по краям и в центре, стремясь в одну сторону - к качеству.
Напомню, что такое "качество" с точки зрения пользователя, к которому в производственной цепочке ближе всех тестировщик. Понятие "Качество" определяется тремя составляющими: точность исполнения требуемого, получение желаемого в означенное время, денежные затраты. На все эти три направления и направлена работа тестировщика: зелёные чек-листы гарантируют полное соответствие требуемому, ускорение процессов разработки сокращают период от запроса юзера до поставки готового продукта, совершенствование процессов и пресекание проблем на корню снижает себестоимость конечного продукта.

Отношения QA - QC - Dev

При движении продукта между программистом и тестировщиком его ореол состоит из вопросов программиста к тестировщику про состояние продукта. QA определяет круг вопросов и проблем, которые необходимо сверить с эталоном. QC исполняет намеченные проверки и выдаёт программисту весь перечень выявленных новых проблем и заключение о соответствии продукта техническим требованиям.
Для того, чтобы стать QC, достаточно знаний школьной программы. Для продвижения по служебной лестнице к QA необходимо расширять свои знания и умения не только в науке тестирования, но и глубоко постигать предметную область (например, экономику для создателей интернет-магазинов, географию для развития онлайн-туризма), а также новые способы сбора, обработки и хранения информации (программирование, аналитика и управление данными), чтобы в любой момент вы смогли стать TestOps, то есть на любом этапе разработки ПО быть в состоянии подменить аналитика, программиста, внедренца. Если QA отличается от QC лишь наличием более широких знаний, то TestOps лучше QA из-за его возможностей не только подсказать в нужный момент, но и самостоятельно внести в нужное время коррективы для производства более качественного продукта.

Все эти растолковывания приурочены к Дню Учителя. Именно с его деятельностью тесно связана наша - тестирование, когда нам приходится самим разбираться во всём том новом, что создали программисты, и затем подробно доносить полученные знания всем заинтересованным лицам (пользователю, руководителю проекта, кодеру и другим участникам разработки).

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

Загадки QA

В одном из радиоэфиров как-то разгадывали профессию дозвонившегося слушателя. По десяти коротким описаниям ведущие должны были назвать не только отрасль, но и специализацию. За каждый неверный ответ радиостанция выкладывала приличное денежное вознаграждение игроку. Мне эта идея понравилась, и ниже перечислю свои загадки о профессии "специалиста по тестированию программного обеспечения" (далее - СТПО). Их у меня получилось больше десятка. К каждой загадке буду давать пояснения.

1. Этой профессии уже не мало лет, хотя признали её совсем недавно.

Программированием, а значит и тестированием, занимаются официально в мире с середины ХХ столетия. Должность СТПО включена в государственный реестр весной 2014 года.

2. До недавних пор этим делом занимались в основном представительницы женского пола, но современность привлекла и мужское население.

Пока был больше упор на ручное тестирование, то эту нудную работу легче выполняли девочки. С распространением автоматизации мужской ум стал более приемлем.

3. Многие считают эту профессию самым лёгким путём для начала карьеры.

Поскольку операторы ПК превратились в просто-пользователей, а тестировщиков считают юзерами альфа-версий, то и желающие "войти в IT" полагают, что освоив профессию QA, они быстрее станут одним из членов престижного клана по созданию информационных технологий.

4. Прежде чем занять свою нишу в производственной сфере, необходимо изучить и опробовать не только нижние ступени, но и хорошо знать верхние, а также уметь заменить любого в параллели. Профессия из числа ИТРиС (инженерно-технические работники и специалисты), но в ВУЗах специализированных факультетов до сих пор нет. На сегодня специальность можно освоить самостоятельно, либо по спец.курсам.

Пирамида команды разработки состоит из трёх слоёв. На верхнем - владелец продукта. В самом большом среднем - программисты, аналитики и тестировщики. В нижнем вспомогательном - тех.поддержка, маркетологи, тех.писатели, коучеры, операторы. У программистов бывают семестры по изучению тестирования, но этого слишком мало. Тестировщик совмещает в себе не только опытного пользователя с аналитиком, но и смотрит на продукт с точки зрения программиста и финансового директора.

5. Наша работа из числа высокого неожиданного риска, но сертифицированный допуск не требуется.

Исследовательское тестирование чаще других может "повесить" или "убить" приложение. Хакерские секреты используются как принципы проверки безопасности.

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

Исследуя новый продукт тестировщик обязан найти его слабые места до момента продажи. Исправляют проблемы программисты и аналитики.

7. Наш вклад в производство настолько субъективная величина, что каждый потребитель мерит её по-своему.

Тестировщика часто называют специалистом по обеспечению (QA инженер) и поддержке качества продукта, а оно имеет три параметра: скорость поставки, цена, удовлетворённость функционалом. Их совокупность каждый пользователь определяет сам.

8. В наши обязанности входит подробное чтение документации.

Есть даже особый раздел про проверку требований к продукту, инструкций пользователя.

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

Требования к продукту, составленные аналитиком, перетекают в инструкцию пользователя после апробации тестировщиком и внесения исправлений, наиболее соответствующих истине.

10. У истоков профессии было насекомое.

Ошибки программирования называются "багами", потому что первой причиной проблемы ПО был мотылёк, а по-английски bug - жучок.

11. День красоты - профессиональный праздник.

Первую ошибку зарегистрировали в журнале проблем ПО 9 сентября 1947 года. В этот же день с 1995 года чествуют всех причастных к красоте в международных рамках. 

12. Представителям нашей касты приходится "рыться в чужом грязном белье".

Тестирование методом "белого ящика" подразумевает чтение кода, написанного программистом, и выявление проблем в этом коде. Программисты очень ревностно относятся к этому методу, наивно полагая, что код - их личная собственность вроде нижнего белья, которое не следует видеть пользователю. 

13. Эта профессия требует особой психологической устойчивости, потому что во всех бедах виновными считают именно нас. Нас хвалят за то, что мы ругаем других.

Тестировщик - основной поставщик проблем для группы разработки.

14. Наш основной стиль работы - объективность. Нам нельзя рекламировать и продавать товар, не смотря на то, что мы о нём знаем всё лучше всех.

Главный отчёт тестирования - вердикт о работоспособности ПО, то есть правдивое описание положительных и негативных тестов. У нас нет прав умалчивать проблемы. Постоянно работая в разрабатываемом ПО именно тестировщики знают и помнят о всех его лучших и худших сторонах.

15. Сталкиваясь с вирусом мы кричим "Ура!" и, не боясь заразы, несём его на "лечение".

Хакерские атаки в мире программирования называют "вирусами", от которых систему освобождают программисты и администраторы сетей.

16. Эта профессия подвластна всем - среди нас не мало "желторотых" студентов и седых пенсионеров.

Юниоры входят в IT в основном через тестирование ПО.

17. Мы практику превращаем в теорию.

На основе наших проб пишутся инструкции пользователя.

18. На работе мы можем играть в игрушки целый день, и никто не будет против.

Есть особое направление Game-Dev или Test-Game. Программным обеспечением может быть игра. Но даже в серьёзном продукте элементы игры весьма хорошо применимы при тестировании. 

Вот список тех причин, за которые я в этой профессии. Ровно по одному за каждый год специализации. Испытайте и вы окружающих, задав им несколько загадок из перечисленных мной выше. Очень сомневаюсь, что сочетание некоторых из них приведёт к точному ответу.

Поздравляю соратников с Днём Тестировщика!

ТО о SD 5.1.1.212

Отчёт о тестировании SQLDetective 5.1.1 (build 212), выпущенном 25 октября 2019 года. Проверка осуществлялась по Release Notes, которые не слишком велики, а значит этот билд был выпущен для исправления важного бага, обнаруженного пользователем. После просмотра всего отчёта, надеюсь, вы легко ответите на вопрос "какого бага билд?".

IMPROVEMENTS 1 из 1 возможного
Online Support Desk
⦁ The process of the update downloading is now indicated on the Windows taskbar.
Процесс скачивания апдейта теперь отображается на системном таскбаре.
Такое интерфейсное новшество стоит проверять на всех доступных операционных сестемах (они перечислены в файле Readme.htm или на сайте продукта в блоке System requirements, на сегодняшний день это "Microsoft Windows 7 and above") и их вариациях (стандартная или пользовательская тема расцветки и контрастности, масштабирование). Для теста не обязательно ждать появления следующего билда, а достаточно выбрать ручной режим обновления. Для этого в окне OSD Updater включите опцию "Allow available items to be selected manually". Новшество можно увидеть не только при наличии интернета и скачивании апдейта с сайта, но и при апдейте из файловой системы. Как тестировать, выбирайте сами: либо машину с установленным SD подключить к интернету (не стоит забывать, что в этом случае ваши данные будут переданы на сайт поставщика безусловно и без дополнительных предупреждений), либо скачайте zip-файл с апдейтом (не инсталлятор) и тестируйте много раз на разных системах без тревоги за то, что данные о вашей машине куда-то утекут. Во время копирования апдейта на кнопке приложения, что отображается на таскбаре операционки, заметно течение данных. Имплементация получает балл, хоть и проверен только один случай.

BUGS FIXED  0+0=0 из 5 возможных, -1.5-0.2=-1.7 за баги
Core  0+0-1+1=0 из 4 возможных, -1-0.5=-1.5 за баги
⦁ The error “ORA-00933: SQL command not properly ended” is no longer raised on a script execution if a DDL statement contains an empty string.
Теперь не случается ошибка о неожиданном окончании sql-команды при исполнении скрипта с пустыми стоками в выражениях.
Поскольку баг в группе Core, то проверять исполнение sql-команды придётся не только в SQL Editor, но и через диалог запуска подпрограмм, что доступен из Stored Program Editor. К сожалению, формулировка фикса никак не поясняет какие скрипты невозможно было исполнить, поскольку термин empty string имеет двоякий смысл: толи это просто пустые строки в тексте скрипта, толи это пустые литеральные команды (параметр для выражения EXECUTE IMMEDIATE), толи это пустые значения символьных переменных или ещё что подобное. Ошибка базы ORA-00933  чаще случается для команд, у которых потерялся конец, поэтому возмём простейший случай и вставим пустую строку между служебными словами SELECT и FROM, из череды которых сформируем небольшой скрипт (3-4 выражения, разделённые слешем или точкой с запятой). Например,
select 1

from dual

;
select 2

from dual

/
select 3

from dual
;

Если проверять диалог выполнения подпрограммы из Stored Program Editor, то в предыдущем билде описанная ошибка не проявляется. Если проверять SQL Editor, то выполнять скрипт необходимо не только по четырём доступным кнопкам на тулбаре редактора (весь скрипт, скрипт от курсора, одно выражение под курсором, одну команду под курсором), но и через запуск файла (через команду @). Мне не удалось получить ошибку ORA-00933  в предыдущем билде, поэтому этот пункт RNs считаю припиской и балла не даю. К тому же выяснилось, что так и не исправлен баг с подвисанием окна процесса в SQL Editor (выполните предложенный скрипт в редакторе через Ctrl+Enter, окно процесса не закроется само после окончания выполнения, а при попытке закрыть его и редактор вручную вам будет предложено отправить Eureka-лог ошибки приложения). Поэтому снимаю балл.
⦁ The error “FROM clause not found in SQL” no longer occurs on trying to execute a statement with the apostrophe in a q-notation.
Ошибка необнаружения служебного слова в выражении теперь не случается при выполнении выражения с апострофом в q-нотации.
Стоит вспомнить, что альтернативные кавычки для символьных переменных бажили и в позапрошлом билде. Для теста придётся составить символьное выражение с апострофом внутри (кстати, апостроф и одинарная кавычка - это разные символы) и вложить его в dml-команду с последующим служебным словом FROM (это может быть как и простая команда SELECT, так и вложенные INSERT, DELETE, UPDATE, MERGE), например, select q'[`]' from dual. Поскольку тех.писательница ошиблась и включила пункт RNs не в блок SQL Editor, то верну вас на тропу истины и ограничу тестируемые модули одним редактором, в котором одном можно было бы воспроизвести баг. К сожалению, предыдущий билд не дал описанную ошибку, поэтому и этот пункт причисляю к припискам. 
⦁ Fixed the highlighting of a literal if the opening bracket of a q-notation is followed by a break.
Исправлена подсветка символов, если открываемая кавычка q-нотации следует за переводом строки.
Подсветка текста осуществляется в окнах для просмотра или редактирования кода. Значит этот пункт RNs затерялся в группе Core. За это минус в карму тех.писательницы. У тех, кто фиксил это, должны быть красными уши, потому что вместо улучшения подсветки сделано её ухудшение. В некоторых случаях остаток команды подсвечивается как продолжение символьного выражения в альтернативных кавычках.

Было хорошо, а стало хуже

Такое исправление функционала даёт мне основание отнять балл, а не присудить.
⦁ A single-line comment is now highlighted correctly when it goes after a number.
Однострочный комментарий теперь подсвечивается правильно, если он следует после количества (номера, цифр).
Опять же странное расположение пункта RNs в группе Core, потому что подсветка текста применима в окнах для просмотра и редактирования кода (Code Editor, Text Viewer, SQL Editor, Stored Program Editor, ..). Вторая проблема с пониманием исправления тоже создалась от безалаберности тех.писательницы в выборе терминов. Что имелось ввиду под словами after a number? Толи предыдущая строка кода оканчивается цифрой, толи имелись ввиду номера строк на левом поле, а может и что иное. Для теста в редакторе кода наберём простенький текст:
select 5
--test
 from dual
и поиграем с местом однострочного комментария:
select 5--test
 from dual
Действительно, подсветка закоментированного остатка строки, следующего за цифрой без пробела между ними, не соответствовала ожиданиям в прошлом билде.

Символы после двух минусов в строке считаются комментариями для SQL Oracle

Поэтому даю балл и даже, по доброте душевной, прощаю использование запрещённого слова correctly.

Но поскольку в каждом пункте тех.писательница запутывала юзера, то за все эти промахи сниму полбалла.
Code Insight 0 из 1 возможного, -0.2 за проблемы
⦁ Ctrl+click now works correctly in INSERT and UPDATE statements.
Функциональный клик теперь работает корректно в выражениях INSERT и UPDATE.
Стоит пояснить, что в SD функциональный клик мышью по имени объекта или переменной позиционирует курсор на месте объявления переменной или подпрограммы (если редактор имеет Code Explorer, например "Trigger Wizard / Body" или "Stored Program Editor") и открывает мастер объекта или позиционирует на нём в Object Navigator. Недавно функциональный клик исправляли для нестандартных имён объектов, а теперь для каких-то составляющих или самих команд. Странно, что в список команд не попали остальные dml-выражения (например, MERGE). Поэтому для теста генерим простейшие все dml-выражения, хотя бы через контекстное меню Object Navigator для любой имеющейся у вас таблицы (или вьювера). Из SQL Editor, в который встроили Code Explorer, функционльный клик открывает без изменений мастер таблицы/вьювера для имени схемы и объекта, но ничего не находит для имён столбцов. То есть, никаких фактических изменений, а тем более корректных, найти мне не удалось. Аналогично без изменений остался и Stored Program Editor для перечисленных команд с объявленными и использованными переменными. Поэтому этот пункт однозначно считаю припиской и не даю ни балла. А использованный термин correctly без отсылки к стандартам и отсутствие конкретики при перечислении команд отнимает -0.2 балла.

Итого билд получает 1+0=1 балл из  1+5=6 возможных, то есть исполнен на 1/6=16%. А за баги теряет ещё -1.7 баллов. Предыдущий билд #210 был опубликован неделю назад, то есть этим фикс-билдом команда пыталась загладить свою вину перед пользователями. А как вы считаете, можно ли такими анти-фиксами получить положительную оценку юзеров?

ТО о SD 5.1.1.210

Отчёт о тестировании SQLDetective 5.1.1 (build 210), опубликованному 17 октября 2019 года. Все тесты основаны на пунктах Release Notes.
Три месяца прошло после публикации предыдущего фикс-билда #160, номер релиза или минора не изменился, а значит за этот период накопились фиксы багов без значительных улучшений. Попробуйте угадать "какого бага билд?", то есть какой критичный баг перевесил точку кипения юзеров и команда ConquestSS попыталась умаслить недовольство пользователей?

IMPROVEMENTS  0.5+0.8+0+0.5+0+0.5+1+0.3=3.6  из 1+1+1+1+1+1+1+1=8 возможных и багов на=-0.5-1.5=-2 балла
Core 0.5 из 1 возможного
⦁ Oracle Client is now automatically downloaded and installed if no installation is detected on the PC.
Клиент Oracle теперь автоматически загружается и инсталлируется, если на компе обнаружено полное отсутствие инсталляций.
Поскольку инсталлятор и функционал подключения к базе являются глобальными модулями, то описание тестов аналогично тем, что были проведены для CS 9.1. В рамках же SD лишь убедимся, что реализация и баги идентичны для обоих продуктов.

Нет детекции или забыто отображение результатов

Также стоит отметить, что инсталляция клиента базы Oracle не входит в рамки инсталлятора продукта, а окно подключения к базе автоматически появляется при запуске SD. Поскольку SD существует только в 32-битном исполнении, то и линк для загрузки клиента предлагается только 32-битный. Учтите, что в архивном файле предлагается не инсталлятор, а просто папка instant-client 19-й версии, которую всего лишь надо скопировать себе на диск (или любой доступный) и в переменных окружения в PATH добавить путь к этой папке. Об этом нигде (RNs или Online Help) не сказано. Реализация не совсем соответствует описанию (не блок опций коннекта к базе), расположение инсталлятора сомнительно (не на сайте вендора базы), отсутствие клиентов не проверяет остальные установки (никаких индикаторов о переменных окружения, пакете Microsoft, нет красных NO у лейбл клиентов), поэтому новшество также получает лишь полбалла.
SQL Editor 0.8 балла из 1 возможного
⦁ Added the ability to search for text occurrences in the DBMS Output tab.
Добавлена возможность поиска текста по результатам DBMS вывода.
Для теста подключаемся к любой базе и выполняем в SQL Editor простенький pl/sql блок с выводом dbms-пакета. Например, "begin  dbms_output.put_line('it is my test for search feature');  end;". Если на закладке DBMS Output в SQL Editor пусто после исполнения кода, то проверьте включенность вывода на этой же закладке или в "Preferences / Code Editors / DBMS Output". Далее проверим сам функционал поиска. В предыдущей версии SD не было ни пункта в контекстном меню, ни появления какого-либо диалога по стандартной горячей клавише "Ctrl+F" при активности курсора в окне результатов dbms-пакета. Стоит заметить, что поиск осуществляется интерфейсом, специально разработанным для SD, поэтому поддерживает все возможности, доступные в других текстовых редакторах приложения. К сожалению, хелп-топик закладки DBMS Output почти что не имеет содержимого, поэтому и новая фича не описана. Ещё одна странность этого новшества в том, что оно реализовано только в SQL Editor, а идентичная закладка в Stored Program Editor осталась не у дел. За что и получает новшество лишь 0.8 балла.
Compare Databases 0 из 1 возможного
⦁ Improved the comparison of system generated objects.
Усовершенствован механизм сравнения системных объектов.
Системными объектами в базе Oracle считаются не только те, что схемах SYS, SYSTEM, но и те, чьи имена автоматически генерятся, поэтому либо начинаются с "sys", либо заканчиваются "$$". В большинстве случаев это индексы, констрейнты, иногда таблицы и вьювера, а с 12-й версии базы - колонки таблиц. Так что очень сложно по вышеописанному определить, что конкретно изменилось в сравнении баз. Значит можно не заморачиваться с тестами и пометить этот пункт припиской, не дав балла.
Rename Object +0.5 из 1 возможного, -0.5 за нереализацию
⦁ Added the ability to
  ⦁ automatically rename tables indexes.
  ⦁ rename tables and indexes of another user.
Добавлены возможности автоматически переименовывать индексы таблиц и менять имена таблиц и индексов в чужих схемах.
Экшен переименования объекта доступен лишь в двух местах:  в главном меню Object или контекстном меню для ноды выбранного объекта в дереве Object Navigator. Описание новшества неточно описывает изменение. Радикально добавлено переименование индексов. Переименовывать можно не только табличный индекс, но и кластерный. Совместно с таблицей переименовываться по опции будут лишь индексы, совпадающие по имени с родительской таблицей. К тому же хелп-топик "Working with database objects – Renaming objects" не отредактировали согласно изменениям функционала.  Для проверки наличия новшества открываем вышеозначенные пункты меню для перечисленных типов объектов. Если достаточно прав у текущего пользователя, то выполняем команду RENAME. Для проверки переименования чужих объектов изучаем команду RENAME для используемой версии базы данных, выдаём тест-юзеру необходимые роли и объектные привилегии. Ещё одно неописанное новшество - возможность предварительно просмотреть полный текст исполняемой команды - внесло в SD интерфейсные баги. Текстовый редактор, являясь глобальным модулем, теперь с новыми огромными иконками для кнопок тулбара, заимствованных из CS 9. А на время его открытия исчезает окно, из которого текстовый редактор был вызван. Для текущего юзера оказывается, что переименовать индексы вместе с таблицей нельзя - нет опции, доступной при переименовании чужой таблицы. Единичное переименование своих и чужих индексов работает. Единичное переименование своих таблиц осталось неизменным. Чужие таблицы с массовым переименованием индексов терпит неудачу из-за неверно формируемого блока на исполнение, в котором индексам не присваивается новое имя. То есть для таблицы выполняется команда 'ALTER TABLE old_table_name RENAME TO new_table_name', а для индексов база ругается на существование одноимённого объекта для команд 'ALTER INDEX old_index_name RENAME TO old_index_name'. По результатам тестов могу дать только 0.5 балла и ещё 0.5 балла сниму за баг нереализации.
Dataset/Datagrid 0 из 1 возможного
⦁ Focused cells are now always highlighted in datagrids.
Фокусированные ячейки теперь всегда подсвечены в гридах данных.
Стоит упомянуть, что в SD компонент Datagrid используется повсеместно, но к нему не относятся таблицы без красного символа "?" в левом верхнем углу, например, на ContentSelector окна Object Navigator закладки Data и Columns относятся к числу гридов данных, а таблица на закладке Properties - нет. Больше всего меня в описании смущает слово "всегда", потому что оно откидывает пункт в блок исправленных багов и означает весьма обтекаемое свойство модуля. Дополнительный когнитивный диссонанс вызывает сочетание множественного числа с фокусом. В фокусе (визуально - с красными точками по бордюру) может быть только одна ячейка, даже если выделено несколько (по-умолчанию, цвет подложки - синий, цвет текста - белый). Если проверять фокусировку, то набор тестов будет для одной ячейки. Если проверять подсвечивание, то набор тестов будет касаться нескольких ячеек одновременно (строка, блок или вразброс выбранные ячейки). Если дизайнить тесты по слову always, то следует обращать внимание на интерфейс грида при открытии его самого, на прорисовку его элементов при работе с редактором ячейки (текстовый редактор для символьных полей, калькулятор для числовых, календарь для дат и прочее) или с вызываемыми утилитами (дублирование строк, экспорт/импорт данных и прочее). Все три типа тестов не показали разницы с предыдущим билдом, поэтому заключаю, что этот пункт RNs - приписка, не заслуживающая ни балла.
Taskbar 0.5 из 1 возможного
⦁ Applied the autofit to the taskbar buttons.
Применяется авто-подбор ширины для кнопок тулбара.
О каком тулбаре идёт речь? О главном или о всех в рабочих окнах? Или только о тех, где размер комбобокса со строкой подключения автоматически меняет ширину? Для тестирования будем открывать Icon Dictionary для главного тулбара, редактора и окон с результатами выполнения скрипта утилиты SQL Editor, какой-нибудь утилиты администратора (Session Navigator, Storage Manager, и т.д.) и простое окно без комбобокса сессий (Smart Dataset, Stored Program Editor). Тесты можно проводить параллельно в двух приложениях SD (прошлый и текущий билд), но каждое окно следует переоткрывать в своей рабочей сессии, чтобы применились настройки. Поскольку с предыдущим билдом разницы не выявлено, то считаю этот пункт исправленным багом, воспроизводимом в SD 5.0, но давно исправленном в SD 5.1, а не в текущем билде. Даю только полбалла за неконкретное описание, ошибочное место (не импрув), запоздалое включение в RNs. Запоздалые RNs получаются в команде без своевременного тестирования, когда задачи закрываются тестировщиком уже после выпуска, не поддерживается период заморозки кода.
Code Insight +1 за исполнение и -1.5 за баги
⦁ Added a horizontal splitter so that the height of the Details panel can be customized.
Добавлен горизонтальный сплитер для изменения высоты панели с деталями.
Модуль Code Insight является глобальным и все изменения идентичны, описанным для CS 9. Убедимся в наличии реализации, вызвав подсказчик кода в редакторе SQL Editor или Stored Program Editor. Аналогичность изменений подтвердила и идентичность багов, выявленным в CS 9. Поэтому за исполнение балл, а за баги -1.5 балла.
Query By Example 0.3 из 1 возможного
⦁ Renamed the “Query by Example Editor” command to “Query by Example (filter and sorting).”
Переименована команда вызова "редактора запроса по примеру" в установление "запроса по примеру с фильтром и сортировкой".
Вышеназванный экшен доступен в главном меню Dataset и в контекстном меню всех Datagrid. Стоит заметить, что переименование касается только пункта меню, но не окна редактора. В RNs новшество попало чисто для массовости, потому что изменение было сделано не в прошлом билде, а в прошлой версии продукта. И не только в интерфейсе, но и в хелпе. Так что получает не более 0.3 балла.

BUGS FIXED  4.6+1+0+1+0.5+1.5+1+1+1.8+0.8+0=13.2 из  7+2+2+1+1+2+2+1+2+1+1=22 возможных и багов на=-4.5-1.2-2-0.3=-8 баллов
Core 0+1+0.8+1+0+1+0.8=4.6  из 7 возможных, -1-2-0.5-1=-4.5  за баги
⦁ Fixed highlighting of search results in lines that include the TAB character.
Исправлена подсветка результатов поиска в строках с символом табуляции.
Поскольку пункт RNs не в блоке "Редактор", то придётся тестировать и недавнее новшество поиска по гриду вместе с поиском по текстовому редактору. В качестве данных для теста возьмём текст, содержащий символ табуляции в начале строки, в конце строки, в строке без иных символов, в строке между символами, несколько знаков табуляции в одной строке до искомого значения. Все эти варианты проверяем в текстовом редакторе, в гриде, в текстовом редакторе с предварительным выделением поисковой части. Отдельно проверяем поиск по регулярному выражению (\t  - табуляция (HT/TAB), можно также \x09), поскольку описание можно двояко понять. Поскольку в редакторах текста невозможно включить режим отображения символов табуляции, чтобы убедиться в их наличии после копирования и вставки, и буфер памяти не всегда (или не везде) вставляет все символы в точности, то перед вызовом диалога поиска набивайте вручную табуляторы. После исполнения тестов выяснено, что на самом деле сделан анти-фикс: раньше все подряд находились значения, а теперь через раз, раньше рядом с подсветкой курсор позиционировался, а теперь через несколько символов от найденной позиции. Вдобавок до сих пор проявляется интерфейсный баг диалога поиска в гридах, когда курсор мигает не в окошке ввода поискового значения, а где-то в районе радио-кнопок, имеющих подписи регионального языка операционной системы.

Пугающее юзера положение мигающего курсора

Не могу дать ни балла за изменение, да ещё сниму балл за общее число сопутствующих проблем.
⦁ The words “left”, “right”, “outer”, “inner”, and “cross” are now treated and highlighted as reserved words.
Служебные слова left, right, outer, inner, cross теперь интерпретируются и подсвечиваются как зарезервированные.
Перечисленные слова используются в DML и DDL, код которых отображается в SynEdit (не простые текстовые редакторы, а редакторы кода с раскраской символов). А именно, мастер объекта, просмотр DDL или скрипта в некоторых утилитах, SQL Editor и Stored Program Editor. Настройка шрифта и расцветки зарезервированных слов доступна в "Preferences / Code Editors / Color / Elements / Keywords" (комбобоксы блока Color и чек-боксы блока Text Attributes). Устанавливаем особенные значения шрифта и вводим в доступных редакторах перечисленные слова без кавычек, а для подтверждения работоспособности просмоторщиков кода без права модификации придётся создать объекты с использованием перечисленных слов. Для создания необходимых объектов обращаемся к документации базы Oracle. Это довольно удобно осуществить в Oracle Documentation Browser, встроенном в SD. Поиск по документации предложит статьи из цикла SQL Language Reference, а поскольку большинство слов употребляется в рамках DML, то можно создать вьювер, пусть и инвалидный, по примерам из документации. Странно, что пункт RNs не в группе редактора кода и в багах вместо новшеств, а в остальном заслуживает балл за исполнение.
⦁ Alternative quoted literals are now highlighted correctly.
Теперь корректно подсвечиваются символы в альтернативных кавычках.
Опять странное расположение пункта RNs не в блоке редактора кода, который поддерживает расцветку текста. Никакие иные графические элементы не раскрашивают символы, вводимые через альтернативные нотации. Не рекомендую искать термин альтернативной нотификации в документации Oracle, а просто ознакомтесь с термином Literals, либо воспользуйтесь примерами от разработчиков базы. Если вставите тексты в прошлой версии Stored Program Editor и текущей, то заметите, что последующий текст не раскрашивается в стринговые значения (по-умолчанию, красный цвет шрифта до следующего одинарного апострофа). Но о корректности подсветки говорить нельзя, поскольку нет отсылки к общепринятым или узаконенным стандартам (кстати, даже страница с примерами вендора имеет смущающую расцветку текстов). За введение пользователя в заблуждение дам только 0.8 балла.
⦁ The error “FROM clause not found in SQL” no longer occurs on trying to execute a statement that includes alternative quoting.
Ошибка о ненайденном FROM слове в SQL теперь больше не случается при попытке выполнить выражение с альтернативными нотациями.
В качестве примера выполним запрос "select q'[It's test]' from dual" в предыдущем билде, получим оракловую ошибку с выводом лога Eureka. То есть была двойная ошибка: парсер кода падал при обработке апострофов и оракловая ошибка излишне вызывала отладчик Eureka. В текущем билде запрос выполняется без багов парсера и DOA, но, к сожалению, до сих пор исполнение запроса может быть заблокировано окном подвисшего процесса, закрытие которого вызывает не обработанную ошибку с логом Eureka. И уже в OSD Messenger выясняется баг комплексного тестирования: глобальная osd.dll скомпилирована из CS 9 с новыми огромными иконками, но без возможности быстрого просмотра писем в дереве osd сообщений (нижнее окно всегда пустое). За фикс балл дам, но пару сниму за старый недоправленый и новый баг сборки.
⦁ Ampersand is no longer duplicated in the tab’s caption in the SQL Editor.
Символ амперсанда больше не дублируется в заголовке закладки SQL Редактора.
Пункт RNs по ошибке не в блоке редактора, подозреваю потому, что это интерфейсный баг, а модуль GUI в ConquestSS считается глобальным. Касательно окна SQL Editor, только одна закладка с переменными имеет амперсанд в своём заголовке изначально. Заголовки же закладок с кодом или данными после выполнения запроса никогда не отображали и до сих пор пропускают один амперсанд, то есть никак не дублируют, а наоборот пропускают. Так что из-за описания, абсолютно не соответствующего исполнению и вводящего пользователя в заблуждения с пониманием, не дам ни балла и сниму -0.5.
⦁ The error “SQL command not properly ended” no longer occurs on trying to execute a statement with the nested procedures in the WITH clause.
Ошибка о неверном завершении команды больше не случается при попытке выполнить выражение с сылочной процедурой в WITH выражении.
Пункт RNs ошибочно попал в группу Core, поскольку выполнением выражений заведует глобальный модуль DOA. А на самом деле скрипт со структурой WITH можно выполнить только в SQL Editor.  К тому же термин nested стоило заменить на inline, как это описано в документации БД версии 12c. Для теста найдите в примерах оракловых форумов запрос с inline procedure in with clause. Выполнив его в предыдущем билде и текущем, убеждаемся в реальности фикса бага. Балл заслужен.
⦁ The CLOB field now has an inplace combo box with the IS [NOT] NULL, [NOT] LIKE operators.
CLOB поля теперь имеют встроенный комбобокс с операторами IS [NOT] NULL, [NOT] LIKE.
Пункт RNs однозначно потерялся и попал вместо блока "Improvements / QBE" в блок "Fixed Bugs / Core". Для теста создаём таблицу с CLOB полем и данными, в редакторе фильтров и сортировок пытаемся выставить ограничения на поле CLOB. Новшество реализовано в редакторе фильтров для грида данных, причём термин field стоило заменить на column, а список условий не стоило перечислять, так как раньше вообще никакие не были доступны. За недостатки описания вынужденно даю только 0.8 балла.
В рамках комплексного тестирования выяснилось, что появилась регрессия в Table Wizard: создание любой таблицы, даже самой простенькой, завершается неожиданной ошибкой. За что с билда снимаю балл.

DDL новой таблицы - минимально стандартный скрипт. 

А что приложение предлагает базе - секрет программиста.

SQL Editor 0+1=1 из 2 возможных, -1-0.2=-1.2 за баги
⦁ Timestamps with time zones are now shown correctly in the Data and Output tabs.
Время с зоной теперь отображается корректно на закладках Data и Output.
В SQL Editor окне существует закладка Data Output, а не Data, и ещё три закладки имеют постфикс Output. Поэтому записываем минус в карму тех.писательницы и проверяем все четыре вывода.  Для проверки фикса на Data Output создаём таблицу с полем TIMESTAMP WITH TIME ZONE, но данные придётся добавить в неё вручную, так как SmartDataset всё ещё не позволяет редактировать данные такого типа. Либо берём из документации Oracle пример "SELECT FROM_TZ(CAST(TO_DATE('1999-12-01 11:00:00', 'YYYY-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York') AT TIME ZONE 'America/Los_Angeles' "West Coast Time" FROM DUAL;" и на его основе выполняем запрос в закладки Data Output и SQL Output, pl/sql блок с обращением к dbms-пакету, а через html-редактор создаём процедуру с выводом в HTML Output закладку. Результаты тестов показали идентичность отображения в предыдущем и текущем билдах. Из чего заключаю, что либо этот пункт RNs - приписка, либо тех.писательнице стоило более полно и понятно описать фикс. Полагаю, второй вариант побудил её использовать термин correctly без аппеляции к каким-либо правилам. Фикс ничего не получает. А билд теряет балл за проблему с полем в SmartDataset.
⦁ The application no longer hangs after the replacement of multiple text occurrences.
Приложение больше не виснет после замены множественных текстовых вхождений.
Стоит пояснить, что речь идёт о поиске и замене в тексте, а значит пункт RNs по ошибке попал не в блок любого текстового редактора или поиска по тексту. Для теста открываем текстовый файл побольше размеров в SQL Editor или в Stored Program Editor. Содержимое файла может не быть SQL, поскольку выполнение или компиляция нас не интересует. Предварительно в редакторах подправьте настройки так, чтобы содержимое файла не перезаписалось при закрытии окна или закладки. Вполне удобно в таком случае взять скрипт на вставку нескольких тысяч строк в таблицу и запустить переименование всех названий схемы на другую. В предыдущем билде диалог процесса замены всех найденных сочетаний не позволял параллельно работать в остальных окнах приложения, но в текущем билде изменение таково, что окошко процесса совсем исчезает, позволяя полноценно работать в других окнах. Это явно не исправление бага, а улучшение интерфейса, но слегка не доработанное из-за невозможности следить или прервать процесс массовой замены. Даю балл полезному новшеству, но снимаю -0.2 за недостатки.  
Object Navigator +0+0=0 из 2 возможных и -2 за баг
⦁ Parent nodes are now automatically refreshed once a new object is created.
Родительские ноды теперь автоматически обновляются при создании нового объекта.
У нод верхнего уровня существует два индикатора, меняющихся при добавлении объектов внутрь: количество и наличие символа "+". Их изменением управляет опция "Preferences / General / Object Navigator / Refresh tree on object change". Изменять или создавать объект можно через мастер объекта или в редакторах кода (SQL Editor, Stored Program Editor). К большому сожалению, тех.писательница не уточнила для какого уровня и типа данных сделан фикс. В число верхнеуровневых нод входит не только нода коннекта, моей схемы, всех схем, несхемных объектов и прочие. Также верхнеуровневыми считаются подпапки с подобъектами параметров редактируемого объекта, например, папка колонок или триггеров для таблицы. Также нет уточнения по поводу типа объекта и статуса папки (пустая или есть хоть один подобъект, свёрнутая или развёрнутая). Так что придётся проверять всё, да ещё в множестве сочетаний. Минимально таблица может выглядеть так:

	создан объект в мастере	создан объект в SQL Editor	создан объект в Stored Program Editor
включена опция Preferences / General / Object Navigator / Refresh tree on object change
выключена опция Preferences / General / Object Navigator / Refresh tree on object change
создаётся первый объект (нода пустая)
создаётся последующий объект (нода не пустая)
нода не разворачивалась
нода раскрыта
моя схема
все схемы
системный объект
папка схемных объектов
подпапка схемного объекта

Для пары наугад выбранных типов объектов все тесты не показали никакой разницы, поэтому пункт RNs выкидывается в ранг приписок, а билд недополучает балл.
⦁ The reset action is no longer available for collections.
Операция восстановления больше не доступна для коллекций.
В дереве объектов коллекция - это объектный тип (в документации Oracle он называется Standalone varying array (varray) type). Они расположены в отдельной подпапке у Types. Операция восстановления - это возврат к версии объекта эдишена. Для лучшего понимания изучите Editions, как объект базы данных и команду Alter Type с параметром Reset. А по-минимуму для теста достаточно иметь хоть один объект коллекцию и раскрыть контекстное меню для него в навигаторе объектов. К сожалению, до сих пор невозможно создать объект-коллекцию ни через мастер (в 5-й версии SD он исчез), ни через Stored Program Editor (в нём открываются существующие коллекции, вместо мастера). Так что создайте коллекции через SQL Editor по скриптам из документации базы. И вы убедитесь, что восстановление разрешено для коллекций. Кстати, в документации Oracle нет ограничений на коллекции, поэтому этот пункт - глупая и ненужная приписка. Балл не могу добавить, а вот снять пару за долговечную проблему с мастером коллекций и введение в заблуждение об объектах базы стоит.
Dataset/Datagrid +1 за фикс, -0.3 за недоделки
⦁ The “ORA-01480: trailing null missing from STR bind value” no longer occurs on trying to commit a table  with over 500 characters in the field.
Ошибка предшествующих пробелов у символьных переменных больше не случается при попытке сохранить данные таблицы с более 500 символами в одном поле.
К сожалению, не упомянут тип поля, поэтому проверять придётся таблицу со всевозможными символьными полями, длина которых может быть более 500 символов. Создавая таблицы для тестов не забудьте ограничение на сочетание полей разных типов в одной таблице. Сохранять будем значения с пробелами в начале, конце и середине текста, текст из пробелов и пустой. Типы полей для проверки: varchar2 byte, varchar2 char, char byte, char char, long, clob, nclob, nvarchar2, nchar. Можно также расширить список типов за счёт ANSI и User Defined. Но фактически достаточно иметь таблицу с полем varchar2(4000). Описанная ошибка больше не случается, но текстовый редактор не обрезает слишком большие значения, а база ругается "ora-01461: can bind a LONG value only for insert into a LONG column", не смотря на то, что текст в редакторе обрезается. Встаёт вопрос: на каком этапе (закрытие редактора, вставка из буфера, ручной ввод, post in visible grid или commit  в базу) и кто (приложение или база) должен мониторить и подправлять предлагаемый объём данных к имеющимся возможностям для хранения? За исполнение, соответствующее описанию, балл дам, но за неполноценность разработки сниму -0.3 балла.
Database Connection Window 0.5 из 1 возможного
⦁ Oracle homes changed for the database connection are now saved and restored correctly after restarting the application.
Оракловый хоум, изменённый при очередном коннекте к базе, сохраняется и восстанавливается при следующем запуске приложения.
Для теста нужно иметь проинсталированными хотя бы два клиента разных версий (не забудьте про дозволенное сочетание версий клиента и базы) или типов (полный или облегчённый). Одна сессия приложения разрешает только одного клиента для всех баз, поэтому термин changed имеет двоякий смысл: либо вы вручную выбирали клиента, либо приложение автоматически сменило клиента для второго и последующих подключений. Стоит ещё вспомнить функционал окна подключения: строки считаются разными, если отличаются имена пользователей или баз, тип подключения (нормальный или администратор). Минимальный приёмочный тест: открываем предыдущий билд, подключаемся к одной схеме с клиентом_1, отключаем коннект, подключаемся к одной схеме с клиентом_2, закрываем приложение, открываем приложение и убеждаемся, что в списке запомнен коннект с клиентом_1. Теже самые шаги в текущем билде дают запомненный коннект с клиентом_2. Если проводить расширенное тестирование для автосмены клиента приложением, то результат будет отрицательным, то есть описанный фикс касается только ручной смены клиента. Поэтому слово correctly, использованное в описании фикса, не приемлемо. Когда появился баг - не знаю, но в ранних версиях всем последующим коннектам клиент менялся автоматически. Поэтому за фикс могу дать лишь полбалла.
Table Wizard +0.5+1=1.5 из 2 возможных
⦁ An access violation error no longer occurs on trying to truncate a selected partition.
AV-ошибка больше не случается при попытке очистить выбранную партицию.
Перед тестом стоит изучить команду Alter Table, в частности её параметр truncate partition. Но поскольку тех.писательница проявила неуважение к пользователям и не пояснила, что именно было багом, и что конкретно изменено, почему пункт в группе мастера таблицы, а не навигатора объектов или главного меню (там тоже доступна команда очистки), то сниму несколько долей балла. Говоря, что исправлена av-ошибка, тестировщик или программист ленится актуализировать баг для выяснения его причины и возможных улучшений продукта. В процессе моего тестирования выяснилось, что баг появился в SD 5, а исправление в текущем билде внесло регрессию: если вы подключились к базе с подтверждением DDL команд, то диалог предупреждения появляется при очистке партиции только из главного меню или контекстного меню навигатора объектов, а мастер таблицы лишился подтверждения на выполнение DDL команд. По совокупности оплошностей фикс получает лишь полбалла.
⦁ On creating a new table, the table name is now immediately shown in the window title once the “Object Name” filed is filled in.
При создании новой таблицы её имя сразу показывается в заголовке окна при вводе символов в поле имени объекта.
Сомнительно, что пункт RNs в блоке исправленных багов, так как его описание более похоже на улучшение интерфейса. При воспроизведении не забудьте режим максимизации окна, когда заголовок мастера таблицы и заголовок главного окна приложения являются одним и тем же элементом интерфейса. Изменение сделано и получает балл. За регрессию о сопутствующем баге при создании таблицы уже был снят балл ранее.
Code Folding +1+0=1  из 2 возможных
⦁ Fixed code folding for the lines with parentheses.
Исправлено вложение кода для строк со скобками.
Напомню, что в некоторых редакторах кода на левом поле имеются интерактивные линии, отображающие вложенность кода по служебным словам и скобкам. Не знаю, для каких конкретно случаев скобки не учитывались в структуре, да и тех.писательница не удосужилась это пояснить. Поэтому берём первый попавшийся код (мне подвернулся объектный тип с телом) и смотрим его в Stored Program Editor, как наиболее часто используемом редакторе кода. Да, линии стали прорисовываться для большего числа случаев. В моём случае, если скрипт состоит из спецификации и тела, то линии структуры имеются и в прошлом, и в текущем билдах. А если скрипт состоит только из спецификации типа, то линии структуры прорисовываются для круглых скобок только в текущем билде. С большой натяжкой даю балл исправлению, которое вполне можно было разместить в группе улучшений.
⦁ Fixed the highlighting when statements are collapsed.
Исправлена подсветка для свёрнутых выражений.
Скорее всего термин подсветки относится к линиям структуры кода при нахождении активного курсора в пределах блока. Но речь может быть и о подсветке служебных слов либо выбранность курсором или поиском нескольких символов (строк). Посмотрим изменения и позже решим, о чём конкретно хотела уведомить пользователей тех.писательница. Для теста открываем одинаковый текст в прошлом и текущем билдах, сворачиваем одни и теже ноды и пытаемся найти отличия при перемещении курсора. Мне абсолютно не удалось приметить хоть каких-то отличий. Поэтому не дам ни балла.
Code Insight +1 из 1 возможного
⦁ Ctrl+click now works correctly for all object names.
Горячая клавиша для открытия объекта теперь работает корректно для всех имён объектов.
Не могу согласиться, что функционал открытия мастера объекта или локализации курсора в коде по спец.клику на его имени является частью подсказчика кода, а не фичей редактора или навигатора объектов. К тому же, описание фикса содержит ещё пару промахов. Что имелось ввиду под определением всех имён объектов? Мне известны следующие случаи: имя латиницей в нижнем/верхнем/смешанном регистре, имя латиницей в двойных кавычках, латиницей в нижнем/верхнем/смешанном регистре в двойных кавычках, на региональном языке в двойных кавычках и без кавычек (только utf-базы поддерживают), имена объектов с префиксом схемы через точку, имя подпрограммы с префиксом родительского объекта. Поэтому проверять пришлось все случаи, из которых исправленными оказались имена в двойных кавычках и на региональном языке. Фикс получает балл, а тех.писательница моё и обще-пользовательское "фи" в карму из-за лишних проверок.
Find and Replace +0.8+1=1.8  из 2 возможных
⦁ Fixed the look-and-feel of the dialog box that appears during the text replacement process.
Исправлен внешний вид диалога о процессе замены в тексте.
Поскольку нет уточнения о какой замене речь (единичная или множественная, прерывания для подтверждения или градусник без остановки), топроверяем все четыре варианта. При чём один уже сделан в рамках одного из предыдущих тестов про зависание. И он же единственный дал мелкое отличие в позиционировании окна с прогрессом замены: в текущем билде окошко центрируется относительно редактора, а было в прошлом билде прилеплено к левому верхнему углу главного окна приложения. Иных внешних отличий нет. Поэтому из-за неверного использования термина "внешний вид" вместо "позиционирование", а также из-за размещения улучшения интерфейса в группе исправленных багов даю 0.8 балла.
⦁ Clicking “Cancel” now breaks the text replacement process.
Нажатие кнопки Cancel теперь прерывает процесс замены в тексте.
По-моему, стоило объединить все четыре изменения заменителя текста в один пункт по совершенствованию диалога о процессе массовой замены. Потому что этот пункт RNs лишь дублирует проведённый тест и работоспособность кнопки при огромных объёмах замены. Уж не буду и здесь снимать балл за невозможность прервать процесс замены после временной активации иных рабочих окон, а просто пожалею группу разработки и дам балл за фикс.
Find Text / Find in Files 0.8 из 1 возможного
⦁ The progress dialog box that appears once the text replacement takes more than 5 seconds is now shown at the top of the main window, not in the SQL Editor workspace.
Окно процесса, появляющееся спустя 5 секунд с начала замены в текстах и файлах, теперь показывается в верхнем углу главного окна, а не в рабочей области редактора.
Фикс сделан, но совершенно наоборот описанному: процессинговое окно теперь легче обнаружить в рамках редактора, нежели оно западало за верхний край монитора. К тому же, исправление касается не только окна SQL Editor, но и всех других, поддерживающих массовую замену текста. Ещё одно заблуждение - помещение фикса в рамках модуля по поиску в файлах, поскольку он работает со своим текстовым редактором, а результат и процесс отображаются не в диалоге, а в приклеенной к низу главного окна специальной панельке. Так что из-за промашек тех.писательницы даю лишь 0.8 балла.
System Information 0 из 1 возможного
⦁ TNS_ADMIN registry values are now included in the system information.
Значения реестра TNS_ADMIN теперь включены в системную информацию.
Этот пункт RNs никак не соответствует терминологии багов, ему явное место в новшествах. При чём эти добавления (переменная окружения TNS_ADMIN, список имён баз из файла tnsnames.ora) были сделаны очень давно, но втихоря (тогда срочно нужна была инфа от юзера, а GDPR ещё не поддерживали). Полагаю, поскольку переменные окружения могут быть уровня системы и пользователя, то о значениях сказано в множественном числе. Либо тех.писательница перепутала термины "значение переменной окружения", "содержимое файла tnsnames.ora" и настройка пути к базам через "строковый параметр реестра". Или же последние версии Oracle кроме ветки "Software / Oracle" работают с иными параметрами реестра? Тогда стоило уточнить баг номером версии базы. Для инфы из реестра в файле с системной информацией продуктов выделен блок "OCI Information / Oracle Registry Data", куда попадает всё содержимое упомянутой ветки, а значит и параметр TNS_ADMIN. У меня так и не получилось выяснить, что же конкретно изменилось в содержимом этого файла, который собирается из множества источников и показывается через главное меню "Help / System Information". Также эти все данные передаются в техподдержку ConquestSS без архивации и шифровки вместе с OSD-сообщением. Видимо у разработчиков проявилась совесть или того требует GDPR, поэтому пункт RNs заявил об изменениях спустя несколько лет. Балл за исполнение дать никак не могу, при чём не столько из-за его невоспроизведения, сколько из-за запутанного описания.

Ещё пара багов, до сих пор мозолящие глаза при инсталяции. За каждый из них снимаю по баллу из-за их долговечности и введении пользователя в заблуждение.
Инсталлятор продукта испортился давно, с одного из билдов версии SD 5.0 тем, что список инсталлированных предыдущих версий опустел и определяет наличие только версии 4.7.2.
Файл ReadMe.HTML имеет одну недоправленную ссылку "top..", взятую из аналогичного файла для CDB.

Линк на внутреннюю папку разработчика

Итоги по билду: набрано 3.6+13.2=16.8 баллов из 8+22=30 возможных, значит билд готов на 56%, выявленные баги снимают -2-8-2=-12 баллов.

Токсичный тестер

Кислотность, как качество тестировщика
Эпитет "токсичный" применяется к человеку не так давно, поэтому не всем ещё понятно его значение. И зачастую им подменяют ранее известные "упорный", "пристрастный", а то и утрируют смысл "заботливости". На сколько мне известно, применять определение кислотности начали молодые люди применительно к своим родителям или знакомым, которые постоянно пытались оградить неразумных от ошибочных шагов. Детям казалось, что им навязывают поведение скромных, ограничивают бесшабашность. Конечно же постоянная опека им надоела и взрослых стали называть "кислотными", отравляющими подросткам жизнь. Также, не желая разбираться в истоках проблемы, которая на самом деле крылась в самих "якобы не-кислотных", более сообразительных приятелей относили к изгоям. А ведь эти, названные "кислотными", на самом деле идут более верным путём.
В качестве примера могу предложить отрывок из шоу "Уральских пельменей", когда в баре собрались друзья вечером пятницы. А герой Мясникова им уже заказал и столик, и питьё с закуской. Благодаря тому же wi-fi-ю в момент разрешил споры, на что приятели и обиделись. Соглашусь, друзья собираются вечером в пятницу пообщаться. Но ведь Мясников предупредил ссоры своими зачитываниями неопровержимых фактов. Почему же его относят к "кислотным"? Да потому, что у них изначально не было тяги к спокойствию. Как же пятница может закончиться без мордобоя?! Более привычный финал для пахавших всю неделю умом мужиков. Мясников не дал случиться проблеме, уберёг от разногласий, а его отвергают. В ком корень зла? Угу, в тех, кто не желает думать, кто "а-ля на стиле" с нацепленной улыбкой.
Это довольно показательная миниатюра для понимания "войны" между командой разработки и тестировщиками. Мы тоже, как Мясников, знаем и предупреждаем от неверных шагов. А нас в конце концов обзывают "кислотными". Так что не расстраивайтесь, а гордитесь таким званием. По моему мнению, это более красочно описывает наши профессиональные качества. Если в вас недостаточно кислотности, то важные баги могут просочиться в публикуемый билд. Хотите добиться чистоты продукта, наращивайте в себе упорство и уверенность в знаниях. Пусть наших вопросов жуть, но в этом и состоит наша круть!  

Foreign or local

Прочтение статьи "Тестирование локализации" Кристины Джеквони (Kristin Jackvony) в переводе Ольги Алифановой всколыхнуло во мне нижеследующие мысли.
* Благодарность автору за список, по которому можно автоматически строить тестирование приложения перед передачей пользователям из разных стран.
* Из личного опыта и по рекомендации программиста: если размер формы не критичен, то самое удобное расположение элементов - в один столбец, а не колоноками. Это позволяет не заморачиваться о длине подписей, что может быть критично на разных языках при масштабировании элементов интерфейса (например, ширина кнопки) по длине текста языка локализации.
** Особого внимания заслуживает свойство wrapped (перенос на следующую строку) у каждой подписи.
* Иметь все переменные в одном юните со всеми используемыми переводами - удобство для техписателя при проверке грамматики. Или же для всех подписей в продукте использовать внутреннюю базу (xml, sqlite), где хранить как основной язык приложения, так и все переводы. Такая структура приложения упрощает программирование и поддержку.
*Для лёгкого включения в тестирование локализации путешествуйте по разным странам, узнавайте их уклад и пристрастия напрямую, воспитывайте в себе толерантность. Понимание жизни других помогает в тест-дизайне локализации.

Поспикаем?

Всё чаще и чаще меня мучает вопрос - не является ли англо-американским засилием обилие новых слов в речи современников? Почему русско-говорящие не используют давно имеющиеся синонимы, а транслитерируют?
Вот мой маленький словарик на каждый день:
Backlog, Scope - объём дел
Case - случай
Casual - повседневный
CheckIn - отметина, засечка
CheckOut, Lock, Book - занимать, блокировать, бронировать
Copy-Paste - взять-вставить
Estimate - оценивать, планировать
Install - развернуть, поставить
Feedback - отзыв
Look - вид, взгляд
Message - мысль, сообщение
Post - объява
Push - вывалить (данные во всеобщий доступ)
Save - сохранить
Selfie - себяшка
Update - обновить, заменить
Ещё немного примеров смотрите в форуме тестировщиков.
Хуже всего то, что молодёжь всеми силами впихивает заимствованные термины в повседневку, особенно в письменной речи. В состоянии ли понять непосвящённый фразу типа "эстимируй скоп и закомить юзерский фидбек в бэклоге"? Совсем по-иному читается "estimate the scope and commit the user feedback to backlog" или "оцени объём работ и добавь ответ пользователя в список задач". По-моему, такая "модность" - часть той самой холодной войны, шагами которой мир порабощается Англией и англо-говорящей Америкой. Вот так вот по мелочи - сначала заговорим не на родном русском, а потом и другие культурные традиции сменим на западные. Тем самым нас изнутри перевоплощают в США, где высшими ценностями являются материальные, а не культурно-духовные.
Почему новинки Российской индустрии называют англоязычно? Где работа Министерства Культуры по возрождению языка? Запретами, естественно, ничего не добьёшься. Нужна акция посерьёзнее, мудрее. Почему-то эсперанто не распространяется так быстро, как английский транслит, хотя предназначение у обоих одинаковое - сгладить трудности перевода.
Для новичков IT-индустрии большинство терминов является абракадаброй. И зачастую сами монстры-айтишники с трудом поясняют смысл частоупотребимых слов. А ведь это ведёт к недопониманию и раздражению в команде. Начальник, реплики которого требуют постоянного перевода, увольняет тех, кто способен донести его мысль на доступном наречии каждому члену команды, потому что считает этот акт доброй воли "подсиживанием серого кардинала". Сам же не желает говорить на языке межнационального общения без весомых на то причин: 95% команды русскоговорящие и ведут 99% дел. Никакой необходимости вести первичную документацию и переговоры на английском нет, поскольку за период более полутора десятка лет шеф не смог привлечь к мелкой работе ни одного иностранца. При этом переводчица вынуждена заниматься не своей непосредственной деятельностью, а замещать тех.поддержку. Не говоря уж о том, что отсутствие тех.знаний ведёт к серьёзным проблемам компании. В подобных командах очевидна необходимость сбора словаря внутрикомандных терминов.
Замещая язык, мы постепенно отказываемся от всей своей культуры. Радует только, что патриотизм в россиянах ещё есть и не в одной моей голове такие мысли: Никита Михалков, Владимир Жириновский и Николай Цискаридзе через СМИ давно уже просят возвращаться к родному словообразованию.

Cheat-sheet for desktop app

За пятнадцать лет работы с десктопными продуктами у меня сформировался определённый список обязательных действий при проверке новой фичи. Его необходимость назрела через год-полтора после начала карьеры тестировщика, а пополнялся он регулярно после выпуска очередной версии и получения отчётов об ошибках от пользователей. Недавно меня просветили, что такие списки называют "cheat-sheet". После заглядывания в словарь мне вспомнился термин "бомба", практиковавшийся в студенческое время и являвшийся не шпаргалкой, писанной мелким шрифтом, а полноценным ответом на экзаменационный билет. Его писали обычным почерком на стандартном тетрадном листе дома, а во время подготовки в экзаменационной аудитории черновик для ответа заменялся на "бомбу", создавая впечатление у преподавателя только что написанного конспекта для ответа. Фактически cheat-sheet является "бомбой" для тест-дизайнера, так что термин вполне верен. Используя чит-лист можно приступать к тестированию сразу при поступлении новой фичи к вам в работу.
Наличие чит-листа в команде разработки может служить профилактикой багов, так как программисты могут ориентироваться на контрольные точки тестировщиков при написании корректного кода. А новому члену группы тестирования по подробному чит-листу можно доверять не только перепроверку исправленных багов, но и принимать новые фичи.
Как уже отмечалось ранее, чит-лист формировался в течение многих лет и на основании запросов об уровне качества, в основном конечных пользователей. Некоторые пункты могут показаться весьма специфичными, но это не значит, что вашему приложению это никогда не понадобится. Некоторые пункты из этого списка перекочевали в чек-лист выпуска версии.

1. Размер формы/окна. У формы должен быть задан минимальный размер и размер по-умолчанию. Он не должен превышать 768 пикселей по-вертикали и 1024 по-горизонтали.
2. Элементы на форме. При первом открытии окна, при выставлении размеров по-умолчанию, при уменьшении до минимальных размеров окна все элементы должны быть видны в видимых границах окна, блока. В случае, когда невозможно все элементы показать, то оставить наиболее значимые, а для остальных добавить горизонтальный и/или вертикальный скроллер.
3. Пустоты. На форме не должно быть неоднозначных пустот. Это ассоциируется у пользователя с невозможностью приложения отрисовать дополнительные элементы. Расстояния между элементами желательно выставлять одинаковые, но не настолько отстающими друг от друга, чтобы у пользователя возникало желание растянуть элементы на пустое пространство.
4. Выравнивание. Элементы на окне должны быть выровнены иерархично по-вертикали, по-горизонтали с соблюдением колонок. Стандартные расстояния 6-12-24 пикселей. Значения в редакторах центрированы по-вертикали, по-горизонтали: символьные прижаты к левому краю, числовые – к правому, в особых случаях центрированы, заголовки столбцов выровнены аналогично значениям, кроме центрированных заголовков групп.
5. Масштабирование. Элементы окна не должны обрезаться, наезжать друг на друга при 120DPI, 125% и иных параметрах монитора. В случае, когда невозможно все элементы показать, то оставить наиболее значимые, а для остальных добавить горизонтальный и/или вертикальный скроллер.
6. Несколько мониторов. Окна и диалоги должны быть привязаны к главным (родительским) окнам, чтобы не было проблем показа зависимых (дочерних, модальных) окон на не активном мониторе. Основное окно приложения должно открываться на основном мониторе при первом запуске, на пользовательски-выбранном при последующих запусках, на доступном мониторе после отключения пользовательски-выбранного.
7. Операционная система. Используйте новые возможности компонентов при их расширении (animated progress bar, touch screen и другие), но не затирайте полезные старые свойства (например, полноценная работа клавиатурой, а не только мышью). Список поддерживаемых версий операционной системы должен соответствовать перечисленному в системных требованиях продукта.
8. Подписи элементов. У элемента в коде программы должно быть две подписи через слеш на английском и русском языках. В режиме своего языка (английского по-умолчанию) не должно быть видно текстов на втором языке.
9. Хинт. У сложно-названных элементов окна и у действий со сложным функционалом (таких как check-box, link и другие) должен быть хинт, текст которого не равен подписи элемента. Стандартные кнопки OK, Close, Cancel, Yes, No не должны иметь никаких хинтов, если клик по ним выполняет только одно стандартное действие.
10. Хелп. У каждой формы должен быть хелп, вызываемый по горячей клавише F1, с достаточным описанием функционала.
11. Значение подписей. Функционал должен однозначно соответствовать названию элемента.
12. Стили подписей.
12.1. Все слова с большой буквы, кроме союзов, предлогов менее трёх символов в названии
12.1.1. окна,
12.1.2. пункта меню,
12.1.3. кнопки,
12.1.4. закладки,
12.1.5. заголовка столбца,
12.1.6. группы,
12.1.7. ветки дерева.
12.2. Только первое слово с большой буквы, кроме названий продуктов или важных возможностей, в названии
12.2.1. check box,
12.2.2. radio button,
12.2.3. label,
12.2.4. значений в ячейках таблиц/гридов,
12.2.5. значений списка,
12.2.6. в текстах хинтов,
12.2.7. в текстах статусных строк.
12.3. В сложных словах через дефис все части с большой буквы.
12.4. Шрифт по-умолчанию Tahoma 8 без стилей.
12.5. Имена продуктов с применением жирного и наклонного стилей.
12.6. Имена продуктов из нескольких слов не дробить по строкам текста.
12.7. На последней строке текста не должно быть только одного слова.
13. Размер дочернего окна. Диалоги и внутренние (дочерние) окна выравнивать по главному окну, оставляя возможность доступа основного (родительского) окна по клику мышки или горячими клавишами.
14. Сохранение, восстановление при закрытии, открытии. Пользовательские размер, позиция и статус окна должны сохраняться при закрытии окна и приложения, восстанавливаться при следующем открытии.
15. Элементы управления. Форма должна поддерживать полноценную работу мышки, клавиатуры и других, доступных в операционной системе, элементов управления курсором и объектами окна (touchpad, голосовое управление, горячие клавиши, перетаскивание и другие).
16. Горячие клавиши. Главным действиям желательно назначать горячие клавиши и показывать их значение в главном меню. Стандартные горячие клавиши должны работать в привычных для пользователя Windows элементах окна, желательно дублировать их значение в пунктах меню (контекстном, главном).
17. Версии БД и привилегии. Недоступные в рамках прав элементы окна должны быть серыми/выключенными/невидимыми, чтобы избежать появления ошибки “ORA-00942: table or view does not exist” особенно для пользователей базы данных Oracle без DBA прав.
18. Браузеры/вьювера. Выходные документы должны учитывать интерфейсно-функциональные особенности браузеров/вьюверов, перечисленных в системных требованиях продукта.
19. Межмодульная зависимость. Новые внедрённые возможности в одном модуле или продукте не должны исключать аналогичную работу в смежных модулях и продуктах. Продукты и подобные друг другу модули должны быть консистентны.
20. Лимиты лицензии. Ограничения триального и лицензионного ключей должны быть полностью поддерживаемыми и не ограничивать работу продукта неописанными в хелпе лимитами.
21. Инсталлятор/апдейтер. Инсталлятор должен устанавливать полноценную новую версию в соответствии с системными требованиями продукта. Апдейтер должен разворачивать обновление без ущерба для имевшегося функционала.
22. Опции, настройки. Новая опция должна иметь значение по-умолчанию, сохраняться и восстанавливаться при закрытии/открытии формы с настройками и приложения, по возможности иметь дубликат в функциональном модуле.
23. Демо-данные, примеры. Пример использования продукта соответствует версии продукта, системным требованиям, содержит достаточное количество данных для демонстрации использования новой фичи.
24. Функциональное соответствие требованиям задачи.
25. При необходимости нагрузочное, негативно-стрессовое, регрессионное, интеграционное и тестирование безопасности.

Примечание: продукты компании Conquest Software Solutions являются интерфейсами для работы разработчика базы данных Oracle и имеют единые модули.