Размышлизмы

Многие великие писатели приходят к одной мысли: "Живи так, как хочется тебе здесь и сейчас, а не по велению других. Только тогда почувствуешь счастье. А иначе, будешь лишь существовать." (читай "Чёрный монах" А.П. Чехова, "На дне" М. Горького).
Другие же сами хотят себе счастья, потому и требуют от тебя своего желаемого.
Вот взять, например, советчика. Кого вы себе предпочтёте: старшего брата (СБ), младшую сестру (МС) или собственный ум (СУ)?
СБ
Если у вас возник сложный жизненный вопрос, и вы обращаетесь к старшему брату с просьбой его разрешить, то СБ, обладающий большими жизненными знаниями и опытом станет предлагать вам такие решения, которые потребуют значительных разъяснений. В этом случае вы будете лишь слушателем, учеником, вынужденным принимать чужую точку зрения. А поскольку СБ придётся много аргументировать, то вы заметите своё низкое положение молчаливого незнайки. Говорить будет в основном СБ, а значит ваша потребность в представлении себя миру будет отвергаться. Тем самым ваша самооценка будет снижаться. Если же в конце концов дело разрешиться благополучно, то ваше самомнение повысится только в вашем собственном мирке, хоть и будут в голове бродить мысли: "Правильную идею подсказал СБ. Я - молодец, что её осуществил(а).". Но если ситуация усугубилась от советов СБ, то вам легко и просто скинуть вину  на СБ. Только тогда ваши отношения с СБ вряд ли станут ещё теплее и доверчивее. Обелив себя, потеряете наставника, который может быть в другой раз окажется более прав.
МС
Когда же в качестве свободных ушей вы используете МС, то однозначно ваше самомнение зашкаливает. Вы обеспечите себе  один из пунктов счастья - рассказ о себе любимом кому-то. Да, МС будет внимать все ваши сказки с открытым ртом. Но вот совет от неё вы врядли получите толковый. Может она и выберет что-то, но наугад, без толковых аргументов. И опять в результате негативного исхода дела вы сможете обвинить МС, а не себя. А за положительное разрешение жизненной ситуации будете гордиться лишь собой. Ведь оба варианта были предложены самостоятельно, а МС послужила по-сути лишь жребием. Укрепит ли такой случай семейные узы? Сомневаюсь. Ваше мнение о себе любимом останется при вас и даже может возрастёт, а любовь к ближним врядли увеличится.
СУ
Частично в обоих вариантах уже была затронута золотая середина - разбирать условия и искать выход, опираясь лишь на собственные знания. Да, только в вашей одной голове умещается вся информация о ситуации, требующей решения. И только вы знаете, чего желаете от всего имеющегося положения дел. Рассматривая задачу сам на сам вы обязательно найдёте единственный верный путь, за который никого не будете винить. А значит ваше мнение об окружающих не ухудшится. О, да - самомнение зашкалит! Но разве не это и есть счастье осознания себя в мире? Только с собой вы можете быть откровенно честным и правдивым, ведь никто не узнает вашей тайны. А точное взвешивание положительного и отрицательного исходов дела, желаемого и ненавистного разрешений ситуации однозначно покажет вам узкие места, где приложив усилия вы развернёте ход в нужную вам сторону.

Эпитет "одиночество" присущ тем, кто живёт по первому или второму варианту. А те, кто опирается на третий вариант, не страдают от одиночества, поскольку всегда считают себя "самостоятельными".
Самостоятельные люди не страдают от одиночества.

Кривая LFT

Взлёт и крах секретников

Жила-была одна мелкая компания. За 15 лет вращения на рынке вывела на орбиту три с половиной десктопных продукта. И когда папаше-маркетологу стало нехватать дохода от одного из прикормышей, он собрал QA-щиков в тайную команду по отлову интерфейсных проблем. Назвал он это сообщество LFT - Look&Feel Team - и обязал докладывать ему о всех некрасивых местах. Вполне логичный шаг - лицо компании - это его продукция, а лицо продукта - его интерфейс, неудобство которого грозит уходом клиентов.
На первой сходке подпольщиков HighBoss рассказал о своей идее:
- Мы с вами нацелены на качество. Начнём с простого - встречают по одёжке. В процессе ваших регулярных тестов обращайте больше внимания на дизайн окон и их элементов. Собирайте свои вопросы, замечания в отчёт и рассылайте его всем членам LFT. Раз в неделю будем обсуждать, что нам с этим делать. Пока программистам ничего не надо сообщать. Но баги интерфейсные оформлять с высоким приоритетом, и кто из программистов откажется их править, будет возмущаться за пределами нашей команды.
При наличии якобы-демократии в компании приказы начальства не обсуждаются и потому закипела работа, массово потекли отчёты. За неделю HB был засыпан таким разнообразием взглядов на (не)удобство GUI, что просто не смог предложить какого бы-то ни было вменяемого решения. К тому же наше положение низших чинов - тестировщиков - выполнявших секретную функцию по отлову интерфейсных проблем и не смевших проговориться об этом вышестоящим проггерам, было тягостным. Нервы расшатывались. В команде росло напряжённое противостояние. Нельзя было раскрыть тайну шефа, но сотрудников по-приятельски тоже было жалко.
Естественно, не предупреждённые программисты стали возмущаться от обилия мелочёвки, их унижало откладывание интересных и серьёзных задач. Чтобы как-то предупредить о серьёзности террора НВ-а, пригрозившего несогласным увольнениями, мной была придумана и проведена подготовительная работа для профилактики багов в виде ежедневных подсказок, которые излагались на манер баек  и присказок. Конечно же, в первые пару дней на стендапах разработчики отвергали помощь от напоминаний (где это видано, чтоб qa-щики учили проггеров?), но быстро сами влились в игру и стали формулировать свои Tips, особенно по результатам code review.
Но злость программистов, очевидная и понятная, всё равно не утихала: один баг требовал раздвинуть элементы, другой тутже сдвинуть, одно предложение просило перекраски, другое - монохромности в подобных местах. Тестировщики беспристрастно требовали качества, а разработчики в недоумении грозились уходом. В попытке примирить команды у меня родилось предложение выписать все возможные варианты интерфейсных стандартов и выбрать наиболее приемлемые для приложений ConquestSS. На очередном собрании LFT пришли к неутешительным результатам - всё чужое нам не нравится или не подходит, ведь их оказалось много разных: Windows OS, Delphi, новомодные Google, iOS. Какими бы ни были удобными фенечки мобильников, от них пришлось отказаться в пользу правил поддерживаемой операционной системы (WinOS) и среды разработки (Delphi). К сожалению, дефолтные габариты элементов из среды разработки не очень нравились НВ, поэтому пришлось составлять собственные.  Уговорились на следующем: шеф программистов соберёт список всех используемых элементов, подберёт оптимальные размеры шрифта и интервалов. Параллельно с помощью TestComplete мне удалось составить автотесты для вычисления размеров и интервалов между элементами в одинаковых окнах для всех трёх приложений.

Пример старого и нового интерфейса

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

GDPR - доверяй и проверяй

Возврат к бюрократии или Сотрудник на доверии
(рубрика - Нюх на баги)

Европейское сообщество решилось на усовершенствование охраны данных. Теперь тестировщикам и сотрудникам отделов тех-поддержки необходимо в срочном порядке совершенствовать свои знания в области юриспруденции.
Начать обучение следует с самого документа - "General Data Protection Regulation (GDPR)".
В большей мере вопрос касается персональных, конфиденциальных данных. А есть ли в них различие? Что об этом думают эксперты? Читайте "Experts on the GDPR #3: What is personal data under the GDPR?".
С технической точки зрения эксперты определили облачные сервисы для защиты данных - "Experts on the GDPR #4. Storing encrypted personal data in the cloud: What is the most secure option?", "EU GDPR: соблюдение требований регуляторов в сфере облачных вычислений".
Какая же ответственность теперь будет у сотрудников техподдержки первого уровня и тестировщиков? Для техподдержки объектом пристального внимания становится информация о кастомерах, которую необходимо дифференцировать по территориальному признаку - индивидуальные данные от покупателей и поставщиков следует хранить и обновлять в рамках GDPR, компаньонов из других стран позволено обслуживать в прежнем режиме, только если они не связаны с европейцами. Было бы проще ко всем применить политику GDPR, но Вы уверены, что иные страны не имеют более жёстких условий? Поэтому техподдержка первого уровня - одно из самых важных звеньев в процессе фильтрации данных. Например, баг от пользователя должен храниться во внутренней системе компании разработки, а все контакты пользователя в независимой базе, вплоть до отдельного сервера. Получается, связующее звено "техподдержка" при этом несёт полную ответственность за линковку данных об исправляемом баге и пересылаемом отчёте пользователю. Тестировщику, оформляющему баг в базу при этом придётся унифицировать проблему, применяя переименование и аггрегацию для сокрытия данных от сторонних глаз. А Ваши базы контрагентов и задач готовы к такой конфиденциальности?
Создавая и тестируя базы данных в программном продукте, выпускаемом Вашей компанией, следует более тщательно контролировать простоту наименований таблиц и полей, связей реляционных баз и доступность их описания. В этом плане хороший пример в OEBS, где таблицы и поля имеют нелогичные наименования, в основном состоящие из цифр, что хорошо запутывает взломщиков. Также должны быть усилены тесты по способам и местам хранения данных - физические носители, облачные сервисы, удалённое управление с ограничением прав доступа и функций. При пересылке данных должны использоваться высоко-защищённые от несанкционированного доступа способы, а пересылаемые данные защифрованы в обязательном порядке. Также не менее важно проверять объём информации, присылаемой с отчётом о баге, чтобы в ней не хранилось что-либо, идентифицирующее пользователя продукта. Объём и содержимое пересылаемых данных необходимо проверять на актуальность, необходимость и достаточность, предотвращать скрытые пересылки (без ведома пользователя) паролей, IP-адресов, списков баз и прав доступа, прочих идентификаторов.
Список ответственных за сохранность данных не ограничивается техподдержкой. Компания, выпускающая десктопный продукт и продающая его через свой сайт, вполне может быть распределённой: например, зарегистрирована компания в США, разработчики и тестировщики фактически раскиданы по России и Украине, маркетологи разъезжают по всему миру, сервера с исходниками и данными пользователей могут быть распределены  по всему миру. Удобнее иметь сервера с исходным кодом и задачами поближе к группе разработки, а сервис продаж в Европе. Но при этом копия базы данных покупателей обязана быть у разработчика в оригинале, а не переименованная, поскольку могут быть проблемы, напрямую зависящие от комбинации исходных данных. Такие моменты прописаны в GDPR как доступ к данным по запросу "Art. 15 GDPR  Right of access by the data subject". О предварительных действиях компании разработки рассказано в "How to prepare for Data Access Requests under GDPR", "GDPR data access portal: Logging into the GDPR data access portal, Making a data access request, The data access request excel template, Making a data deletion request, Making a data change request, Making a consent change request".

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

Копим куки

Очень многие сайты, не исключая самых используемых, не в состоянии корректно обрабатывать куки из списка исключений.

Предварительная настройка:
- в FireFox отключить все куки ("Открыть меню / Настройки / Приватность и защита / Принимать куки с веб-сайтов" = отключено)
- очистить имеющиеся куки ("Открыть меню / Настройки / Приватность и защита / Показать куки" = "Удалить выбранные")
- можно перезапустить браузер, но не обязательно.

Пример 1
- открыть сайт "mail.ru"
- в левом верхнем углу набрать свои (полностью корректные) параметры входа в почту:

- по нажатию на кнопку "Войти" неожиданно появляется опять форма для входа в почту с пустыми данными:

- вводим ещё раз свои корректные (!!!) данные. Хотя, очень непонятное явление - может какой вирус желает перехватить вводимую инфу? или сервис настолько наворочен, что впихнул в одну фичу все пять? или мои данные потерялись где-то? или ещё что...

Актуально: после второй попытки входа абсолютно неверное сообщение об ошибке в имени пользователя или пароле:


Ожидаемый результат: сообщение об ошибке должно говорить о некорректно настроенных или отключенных куках браузера.
Решение проблемы: добавить "https://mail.ru" и "https://account.mail.ru" (обратите внимание на протокол) в разрешённые веб-сайты для сбора куков.

Примеры 2, 3
Аккаунты в "Blogger.COM", "Blogspot.RU", "Google.COM" недоступны без включенных куков:






Актуально: неожиданное поведение в виде зацикленных пустых окон с предложением войти или создать аккаунт.
Ожидаемый результат: сообщение об ошибке или предупреждение о выключенных или неполноценно настроенных куках.

Пример 4
Аккаунт в Facebook становится доступным после добавления "https://www.facebook.com" в список веб-сайтов для сбора куков, но очень желательно перезапустить браузер после изменения настроек, чтоб не получить неожиданное сообщение:


Совет тестировщикам: для качественно проведённой работы проверяйте сайты с полностью очищенными куками и выключенными настройками для сбора куков.
Зачем? Понятный и дружелюбный интерфейс - это прямая дорога к увеличению пользователей, т.е. росту дохода компании.

Telegram in application with DB connection

ConquestSS announced that the communication channel Telegram was involved into SQLDetective (SD). It means that PC with installed SD should have opened Internet. As SD works with Oracle DB then application and database settings may be stolen or hacked. For example, SD stores DB connections without encryption, it's possible to store the connection passwords and they are encrypted by very easy method.
So, here are several suggestions for Telegram&SD users:

• install SD into own folder that differs from standard "%ProgramFiles%\SQLDetective 4.7";
• don't save passwords on DB connecting;
• delete the row from the "Last Connections" list that's saved automatically after successful connection;
• use TNS connection type instead of Direct where Host, Port and SID are available without encryption;
• don't use Host, Port and SID in TNS names;
• monitor your DB by DBA tools: DB Examiner, Top Session Locator, Storage Manager, Session Navigator, DB Monitor;
• check DB settings by object wizards: Profile, User, Role, Schedule, Privileges.

Your Oracle DB may be hacked also after involving the Telegram channel to ClearSQL (CS). Settings of database connections are stored in CS settings in the same way as in SD. CS allows to start SQL*Plus from CS with already connected DB user. Sync feature in CS allows to compile scripts into DB.
So, here are several suggestions for Telegram&CS users:

• install CS into own folder that differs from standard "%ProgramFiles%\ClearSQL 7.0";
• don't save passwords on DB connecting;
• delete the row from the "Last Connections" list that's saved automatically after successful connection;
• use TNS connection type instead of Direct where Host, Port and SID are available without encryption;
• don't use Host, Port and SID in TNS names;
• check the script content before running the Sync actions;
• exclude the "Write Back" option from Project Job and Schedules;
• don't store CS Projects in the default "%AppData%\Roaming\ClearSQL\Data" folder, and don't change the "Preferences / General / Folders / Default project location folder:" option;
• turn off the "Preferences / SQL*Plus / Application Run / Use SQL*Plus executable file in active Oracle Home folder if available" option and create an executable file for SQL*Plus starting by password.

Data stolen

ConquestSS shared an article "41 Percent of Consumers Won't Do Business with a Breached Company" about data stolen:
--
According to the Data Breach Statistics collected by Gemalto, 213 thousand records are being lost or stolen every single hour worldwide. If you believe you are not exposed, think of Equifax. We bet they did not expect the leak would ever take place – nevertheless it did.
But for the loss of data itself, such leaks might cause the loss of trust, clients, and partners, and bring about serious expenditures.
To prevent the possible downturn, run regular security audits of your Oracle Database using ClearDB Documenter and detect vulnerable areas early in the lifecycle. Do not stay aside of the problem until it gets inside your Database.
--

Oh, why does ConquestSS talk only about ClearDB Documenter on suggesting to keep the DB security?
Does ConquestSS forget that DBA tools in SQLDetective (SD) are available to monitor DB, fast and easy fix many problems? DBA tools show info in a moment, save statistics, work faster than generation of Security Audit Report (SAR) by ClearDB.
As the most of SAR checks are the result of some select statement execution then SD user may do them by SmartDataset features: QBE, LOV, Filters, Query Builder + Build-In VCS Project. Unfortunately, on Docu generating there is no ability to select only some Checks. But if an SD user creates only necessary SmartDatasets then he/she is able to get results more faster than by SAR generation. If the SD user monitors DB by Database Manager, Top Session Locator, Database Monitor, Session Navigator, Storage Manager then the linked Object Wizards and SQL Editor may fix the detected problems in one click.