Показаны сообщения с ярлыком нормы. Показать все сообщения
Показаны сообщения с ярлыком нормы. Показать все сообщения

четверг, 8 июля 2021 г.

Безоглядное родительство

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

Погода благоприятствует прогулкам, и на днях пред моими глазами на бульваре произошёл конфликт поколений. На скамейке отдыхала старушка и ела мороженое. Мимо шли мать с полугодовалой дочкой на руках и отец, одной рукой толкавший коляску, а другой держа за ручку двухгодовалого сынишку. Бульвар - место общественное и там постоянно проводят много свободного времени горожане. Конечно же, муниципальная собственность оборудована необходимыми социально полезными объектами: лавочки, спортивные снаряды и детские качели, санитарный уголок и продуктовые палатки с напитками и закусками. Семейство нагулялось и двигалось к парковке. Поравнявшись с вкушающей сладость старушкой, внимательная мамаша остановила своих родичей и стала допытывать сыночка: "Хочешь пи-пи? Давай, давай сейчас, а то до дома не дотерпишь." Уговорив дитя опорожниться, она обменялась с отцом детьми и сделала пару шагов до ближайшего деревца на газоне, снимая с малыша штанишки. 

Мамаша нарушила правила посещения общественного места, не воспользовалась санитарным местом и позволила любимому сыночку подпортить окружающую среду. Поскольку всё это происходило прямо напротив поедающей мороженое старушки, то её желудок отреагировал соответствующим образом и перестал благополучно принимать сладость. За поведение, не соответствующее общепринятым нормам, взрослая женщина осмелилась сделать замечание молодому семейству: "Молодые люди, вы плохо воспитываете своих детей. Опорожняетесь на газоне вместо специально отведённого места. Этим вы нарушаете экологию, да к тому же испортили мне аппетит и настроение." 

Думаете, родители извинились перед ней? Нет! Они нагло посмеялись над отрыжкой старушки: "Детская моча деревьям не помеха." Понятное дело, что любящая мамаша готова зад целовать своему сыну, но такое безоглядное чувство демонстрирует её ограниченность. Мало того, что подобное поведение наглого семейства оскорбляет окружающих, но дети, наблюдающие поведение своих родителей, станут копировать его и впоследствии, то есть лет через двадцать ситуация вполне может повториться. А на месте отдыхающей старушки может оказаться та самая мамаша или не остановивший её отец семейства. С медицинской же точки зрения мать подвергла сына опасности подцепить клеща с ветки дерева, не приучая его пользоваться санитарным местом для справления нужды. Полагаю, что отец в этой ситуации оказался более благовоспитанным, поскольку он не потащил сына до неподалёку стоявшего их автомобиля, чтобы помочить колесо, как это принято у настоящих мужиков. Но с другой стороны, он проявил слабость и показал себя подкаблучником, не отведя сам сына в кабинку биотуалета. Но это не удивительно, поскольку скорее всего его воспитывала такая же безумно любящая мамаша. 

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

Для группы разработчиков их ПО тоже становится столь же близким детищем спустя некоторое время. Они его поддерживают, совершенствуют. Но у некоторых эта забота приобретает эгоистический характер. Кто-то из производителей счастлив тем, что конечный пользователь получает качественный по всем параметрам продукт, а эти генерят код только лишь для самого факта наличия сложного кода. По сути он никому не нужен, но он есть, создан, функционирует зазря, даже при всей его сложности и вычурности. Немного об этом уже было сказано в статье "Программа или дитя" (https://tjupka.blogspot.com/2020/11/blog-post.html). Здесь же хочу затронуть ту губительную сторону дела, когда ПО пожирает команду.

У каждого старшего члена семьи существует свой взгляд на воспитание младшего поколения. Кто-то продолжает династию, иные вкладывают силы и средства в будущего гения, пытаясь воплотить в чаде свои несбывшиеся мечты. Также и в группе разработки, при отсутствии единой цели каждый тянет одеяло на себя. Инвестор спонсирует только то, что даст быструю и максимальную прибыль, словно случайный папаша, получивший девять месяцев назад пятиминутное удовольствие. Аналитик продвигает те идеи, которые на его взгляд станут единым универсальным решением на все случаи, как дедушка, воплощающий в жизнь идейные заветы. Да и нам, тестировщикам, важны лишь те задачи, что запросил конечный пользователь, аналогично безумным мамашам, что готовы в лепёшку расшибиться ради капризного дитяти. 

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

Ещё один подвох кроется в типе команды разработки. Многие шефы сейчас бравируют так называемыми "тёплыми, семейными" отношениями. Но никогда не раскрывают истинного стиля. И недаром лекторы Стратоплана настойчиво предупреждают избегать таких коллективов. Да, вас там будут "иметь и в хвост, и в гриву за просто так", без всякой благодарности и учтивости взвалят на вас всё самое муторное, как будто так и надо. Нет! На работе спать нельзя. В прямом и переносном смысле. Как только вы начнёте замечать благосклонность босса, то сразу постарайтесь выяснить напрямую причины и ожидаемые последствия таких перемен. Иначе вы внезапно окажетесь тем самым мальчиком для битья, виновным во всех проблемах. 

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

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


понедельник, 13 апреля 2020 г.

Взгляд назад

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

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

четверг, 12 сентября 2019 г.

День программиста

Большинство IT--шников считает своим профессиональным днём 13(12) сентября.
Первым представителем этой отрасли производства считается Ада Лавлейс - женщина.
На днях СМИ были обескуражены (ведущий федерального ТВ канала даже не сдержался в выражениях) новостью об отмене конференции IT--шников в Германии. По-моему, причина вполне очевидна, поскольку Европа толерантна и хорошо знает истоки.
А организаторы SQADays-26 незадолго до этих событий вынуждены были приглашать меня по телефону, не смотря на очень низкие отклики о предыдущем докладе.
Оценки слушавших в С-потоке.
Полагаю, оргкомитет SQADays быстро вынес урок из конфликта в Европе. Либо и у них наступил кризис - в дорогой Минск не захотели ехать большинство российских докладчиков или все выложились на юбилейной конференции и за полгода-лето ничего нового не выжали из своего опыта. Ещё один момент приходит на память. После столь неудачного моего выступления Рина Ужевко, будучи руководителем оргкомитета SQADays-22, весьма недальновидно отказала мне пообщаться с коллегами на тему "Девочку или Мальчика?". А ведь ещё два года назад можно было предупредить руководителей групп разработки о столь полезном привлечении работников, исходя из гендерных особенностей. Рина побоялась таких разговоров. А вот Андрей Бреслав на TechTrain-2019 поднял вопрос о женщинах-программистках. Актуальненько!

суббота, 4 мая 2019 г.

Облегчаем чемодан

Сезон отпусков начался, а значит грузоперевозки смещаются в сторону пассажиров. Всё больше авиа-компаний предлагают билеты без оплаты багажа или снижают вес ручной клади. Даже железнодорожные и автобусные турникеты проверяют объём чемодана. Как же при таком натиске оплаты за каждый перевес умудриться моднице выглядеть в отпускные дни или на корпоративных, командировочных тусовках разнообразно и соответственно случаю? На каждый день нужны 2-3 наряда, к которым подходит разная обувь. Не уместно в утренних кроссовках для зарядки прийти на ужин в ресторан, или в пляжных шлёпанцах в офис.
Для уменьшения количества нарядов уже давалась подсказка в виде костюма-перевёртыша. Из четырёх деталей двустороннего цвета можно скомпоновать уйму нарядов: длинный сарафан складывать в юбку или мини-платье, два рукава могут быть длинными или короткими, четвёртый элемент - накидка - может стать шляпкой или топиком.
Многофункциональные части наряда
Но как же к разным нарядам уложить в чемодан столько же разных туфель, босоножек, шлёпок, танкеток? Некоторые производители обуви предлагают сменный верх для толстой подошвы, другие меняют каблук. Но, к сожалению, платформа не всегда в моде, а разница высоты каблука не самым лучшим образом влияет на супинатор. Подобрать же удобную колодку - задача всегда очень индивидуальная. Считаю, что для каждой высоты каблука должен быть своя основа. Поэтому предлагаю разделить отпускную обувь на три части: подошва, каблук и верх. Их легко и просто можно уложить в чемодан. Если же они из дерева или композитного пластика, то и общий вес багажа значительно снизится.
Подошва без каблука и верха, вид сбоку
Подошва без каблука и верха, вид на отверстие для крепления каблука методом поворотной защёлки
Виды съёмного каблука - шпилька, устойчивый
Верх шлёпанцев можно сшить из кусочков кожи или ткани
Верх босоножки можно изготовить самостоятельно из ниток или ткани
Верх классических "лодочек" лучше закупать у обувщиков-профессионалов
Другой вариант экономии - одна подошва с каблуком, но сменным верхом и колпаками на каблук. Цветовое сочетание каблука и верха быстро сменить, если верх и колпак крепить на винтики. При этом винтик каблучного колпака будет служить подбивкой, то есть можно его делать из пластмассы для снижения уровня звука при ходьбе.
Разноцветные колпаки на каблук
Ещё одно преимущество от обуви со сменными деталями - материал производства. Ведь это вполне может быть вторсырьё - пластик бутылочный.
Обувщики и текстильщики, давайте сделаем приятное и дамам, и носильщикам их чемоданов - значительно сократим количество вещей и вес багажа.  

понедельник, 15 апреля 2019 г.

Обратная совместимость

Регрессионное тестирование для каждого продукта проводится в своём направлении. В случае обнаружения критичного бага у пользователя должна быть возможность отката до предыдущей версии. Но если в результате такого отката данным будет нанесён урон больший, нежели неудобства новой версии, то считайте такую проблему не просто регрессией, но и фатальной.
Очередной пример вышеописанной регрессии предоставила компания ConquestSS сразу в двух продуктах ClearSQL ver#7.1 и SQLDetective ver#5. Когда в 2015 году для ClearDB персональные данные (пароль к БД) стали шифроваться, то моё замечание о невозможности восстановления паролей через возврат к предыдущей версии восприняли как негативный и нежелательный тест. Разработчик в новой версии добавил кодирование пароля, но не делал конвертацию старых данных. Тогда не было владельцев продукта, готовых обновиться до новой версии. На стороне пользователя потеря паролей не проявилась. Да, соглашусь с мнением, что пароль - это не те данные, которые стоит хранить даже в зашифрованном виде, но у разработчиков ConquestSS и к любым другим настройкам аналогичное отношение. Старые, привычные установки не конвертируются в новую версию, а затираются значениями по-умолчанию без предупреждения. О чём не раз жаловались юзеры. Алгоритм перевода на новые настройки давно известен (сохранить старые, добавить новые параметры, предупредить о новых возможностях и вариантах восстановления прежних), но в среде программистов ConquestSS им напрочь пренебрегают.
Поскольку ни в Online Help, ни в Release Notes ничего не сказано о том, что после апгрейда пропадут данные, то считаю своим долгом тестировщика предупредить текущих пользователей ClearSQL ver#7.0 и SQLDetective ver#4 о необходимости сохранить прямо сейчас ветки реестра "HKEY_CURRENT_USER\Software\ClearSQL\DB Connect" и "HKEY_CURRENT_USER\Software\SQLDetective\Splash\ConnectionHistory" соответственно продуктам или Preferences в файл. Это позволит вам вручную восстановить в предыдущей версии утерянные при апгрейде пароли. Напоминаю, что в ClearSQL ver#7.1 (and higher) и SQLDetective ver#5 пароли к БД, сохранённые в предыдущих версиях, обнуляются при первом же запуске без какой бы то ни было возможности восстановления.
О простоте кодирования паролей в ClearSQL ver#7.0 и SQLDetective ver#4 уже говорилось в статье "Telegram in application with DB connection". Команде разработки потребовалось полтора года после моего напоминания для перенесения алгоритма более серьёзного кодирования паролей из ClearDB ver#4 в ClearSQL ver#7.1 и в SQLDetective ver#5. Так что, перед обновлением до сегодняшних версий не поленитесь и сделайте себе памятку, ведь столь удобная галка "сохранить пароль" может сыграть с вами очень злую шутку - не восстановит значения в новой версии, и даже механическая память рук ничем не поможет.
А всем тестировщикам ПО рекомендую не только проводить тест на обратную совместимость, но и вести профилактическую работу по предотвращению багов. Вроде бы удобство - опция для сохранения и авто-восстановления данных, но не для всех значений она может поддерживать законы безопасности приложения. Ещё одним примером такой юзерской прихоти является отдельная возможность выгрузки в XML файл всех сохранённых на машине коннектов к базе. В своё время мне пришлось потратить немало усилий, чтобы из прикреплений к OSD сообщению удаляли эти записи, потому что они несут персональную информацию, зачастую бесполезную для техподдержки ConquestSS. Но полагаю, что тот же юзер, который предложил сохранять пароли, сам и предложил экспортировать коннекты. А ведь это первый путь к хакерству. Если пользователь меняет комп, то в Online Help есть подробная инструкция по переносу настроек. Насколько часто нужна фича экспорта-импорта всего списка коннектов и кому? Ответ очевиден - только тому, кому временно стал доступен чужой ПК. Да, через сохранение всех настроек (Preferences) в файл тоже быстро можно скопировать все коннекты, но при этом ещё много локальных параметров (ключ лицензии, опции анализатора) придётся корректировать после импорта. Так что, считаю фичу экспорта-импорта коннектов вредной, а не полезной. И рекомендую подобные им новшества пресекать на первоначальном этапе разработки. Тогда не придётся выдумывать "защиту от дурака" в виде излишних шифрований или подтверждений опасных шагов. А владельцы продуктов и особенно администраторы баз должны перестать использовать опцию сохранения паролей, дабы хоть малость усложнить нежелательным элементам доступ к данным. Хотя, подобрать пароль, зная имена схем и баз, можно довольно просто. О чём немало говорили и Pete Finnegan, и Александр Поляков.

четверг, 17 января 2019 г.

Инфо-обмен

Команда из экспертов по информационным технологиям не только помогает другим обрабатывать информацию, но и сама вынуждена обмениваться знаниями.
В школе нас научили, что прежде чем передавать кому-то информацию, её необходимо систематизировать. На этом принципе основаны все учебники: тема, цели и задачи, оперируемые субъекты, основной материал, закрепление, проверка усвоенного. Цель моей статьи - описать knowledge management в группе разработки ПО. Задача - показать варианты обмена знаниями.
Будем считать, что группа разработки ПО состоит из руководства (шефы, директора), продавцов и техподдержки (сбыт-снабжение), разработчиков (аналитики, программисты), отк (тестировщики и пользователи). Какими знаниями они должны делиться друг с дружкой? На мой взгляд - всеми, касающимися продукта и процессов производства, распространения. Любой момент знаний в одной области может сыграть решающую роль в смежной. Вся группа нацелена получить максимальную выгоду и не только в денежном эквиваленте, а, например, в виде отзыва: "Именно это я давно хотел!". Моё совмещение техподдержки с тестированием на протяжении многих лет обязывало глубоко вникать в предметную область, что дало возможность генерировать множество полезных идей, воплощённых в выпускаемых продуктах. К сожалению, каждый раз приходилось заниматься самообразованием, а потом, терпя презрительные взгляды аналитиков, доказывать пользу моих идей. А если бы разработчики вовремя делились своими знаниями, то скорее всего идентичные предложения внедрялись бы от их имени, без "оскорбления их статуса".
Поскольку знания - это информация, то передавать и усваивать её человечество научилось несколькими способами:
- на слух: лекция, прослушивание аудио-записи, улавливание звуковых сигналов аппаратуры, диалог;
- просмотр видео и картинок, невербально мимикой и жестами;
- чтение текстов и схем;
- сенсорно через запахи и тактильность;
- очень редко с помощью телепатии.
Фантасты, конечно, предлагают и иные варианты, но современные технологии пока могут предложить только скорочтение и поиск по индексированному содержимому, доступные не искусственному интеллекту.
Переход поступающей информации в знания и есть процесс обучения. Курс "методика преподавания [предмета]" не ограничивается освоением таких методик, как лекция и практическое занятие. Обучать можно через игру и зазубривание, доказывая и веря на слово учителю, совершая открытия и отрицая гипотезы, строя логические цепочки и впитывая множественность хаотичных потоков. Пока мы в роли ученика, студента или стажёра, наши усваиваемые знания контролируются и оцениваются в явном виде (оценки в журнале и зачётке, контрольные работы, экзамены). В большинстве случаев объём и качество получаемой информации были в прямой зависимости со статусом в обществе через рейтинг отметок.
Аналогично кадровики рекомендуют изменения в зарплатах и карьере, исходя из данных матриц достижений (некоторые называют их матрицами знаний и навыков). Для большинства же работников приятнее осознавать свою значимость в проекте за счёт эксклюзивных умений и владения важной инфой. К сожалению, такие индивидуалы реже других готовы делиться знаниями, аргументируя тем, что ему самому они дались недёшево и просто так выкладывать новичку свои мозги не в его интересах. Подобному сотруднику предложите составить курс лекций с соблюдением всех правил методики преподавания, дайте в качестве дополнительной нагрузки (естественно с оплатой) учеников и обяжите создать подробное описание всех своих предыдущих и текущих дел, работ. Со временем он либо переквалифицируется в преподавателя и уйдёт в учебное заведение, если выдаваемые им знания довольно общие, либо он сбросит с себя нимб всезнайки и в дружеских беседах станет делиться тем, что приобрёл благодаря вашей компании. Для ускорения осознания снобом временности и ничтожности своей уникальности можно подсунуть ему в число учеников дотошного и любопытного новичка. Но это из разряда жестоких шефов.
По-моему, наиболее экономичный и эффективный способ передачи знаний новичку команды - это библиотека видео-записей. Рассказ вчерашнего новичка очередному стажёру - это игра в испорченный телефон. Обязательно забудутся важные моменты, готовый сотрудник тратит время на уже выполненную работу, вопросы остаются без ответа, либо переадресуются в исходную точку. Так было в Conquest:
- о работе тестировщика мой рассказ передавался в телефонных беседах более пяти раз, поэтому у последнего кандидата взгляд на работу отдела тестирования резко контрастировал с моим изначальным;
- о возможностях продуктов вначале рассказывал сам шеф, в качестве репетиции вебинаров для потенциальных покупателей. Но моё предложение записать хоть одну конфу для последующего сокращения своего же рабочего времени было отвергнуто. Взамен, он эту обязанность возложил на меня. Моя запись о возможностях одного из ведущих продуктов положила основу для библиотеки аудио- и видео-записей собраний (передача внутренних знаний новичкам, демо новых фич, обсуждение разработок, стендапы и ретроспективы) и сэкономила мне кучу времени впоследствии (текучка кадров была очень стремительной);
- видео-лекции о внутреннем распорядке (регламенты собраний, как оформлять код и документацию, схема утверждения задач и глобальная структура продуктов, структура движения ответов техподдержки) тоже следует делать один раз, поскольку попугайские повторения тим-лида раздражают не только его самого, но и слушатель перестаёт воспринимать информацию, выданную без эмоций, на автомате.
Хотя видео и аудио-записи пока ещё с трудом поддаются индексации для последующего поиска и актуализация содержимого равна полной переделке, но этот вариант передачи информации на сегодняшний день является наилегчайшим для восприятия. Аудио- и видео-обмен знаниями эффективен тем, что вполне легко можно применить способ закрепления - троекратное повторение мысли в различных интерпретациях (например, теорему Пифагора предлагают не только стандартно "квадрат гипотенузы равен сумме квадратов катетов", но и как графическую и стихотворную аналогию с "Пифагоровыми штанами").
Второй по восприимчивости тип передачи инфы - это картинки, схемы. Визуализация текста ярче запоминается. На этом факте был основан метод опор Шаталова. По этому же принципу создаются комиксы, столь популярные сейчас во всех возрастах. Mind-карта, созданная в процессе обсуждения разработки, вполне отчётливо может служить стенограммой встречи и готовой весомой частью техзадания или хелпа. Матрицы переходов состояния - лёгкий и удобный вариант описания теста. Flowchart, Call Tree и многие другие виды диаграмм - лучший способ визуализации продукта. Тем более, что современные технологии позволяют частичное редактирование и поиск для актуализации содержимого во всё более многих форматах (SVG, XML,..).
На мой взгляд собрания, типа стэндапов и ретроспектив, вполне подходят для совмещения обмена информацией в целях оповещения всей команды о ходе дел и параллельного обучения не только скрытым или сложным местам разрабатываемого продукта, но и новым, сторонним технологиям, которые вполне могут повлиять на развитие продукта. Если внимательно слушать каждого выступающего на стендапе, то обязательно появятся вопросы. Это упражнение было моим советом новичкам для повышения их авторитета в команде - шеф подмечал такое неравнодушие к изложению темы, как глубокое погружение в продукт. Тем не менее, осведомлённость деталями всегда способствовала качеству продукта - более главной цели при приобретении новых знаний. А в рамках еженедельных ретроспектив всегда полезно отчитаться перед всей командой о том новом, что удалось узнать о разрабатываемом продукте, его альтернативах, сторонних технологиях для улучшения своей работы. Небольшой рассказ или обычное перечисление узнанного в течение 3-5 минут экономит время сразу всей команде (известно становится, к кому можно будет в последствии обратиться за деталями, основы теории доносятся каждому одновременно), а по результатам заинтересованности составляется план обсуждений и разработок.
Классика жанра передачи знаний - текст в книгах и учебниках, статьях и научных работах, wiki всеобщего и внутреннего пользования. Для удобства и эффективности восприятия придерживайтесь общепринятых стандартов в структуре документа, отмечайте важные моменты, будьте краткими и содержательными при создании текстов, используйте простой язык и синтаксические конструкции. Немаловажна помощь каталогизации всей библиотеки. В последнее время актуальным стал словарь внутренних терминов и сокращений, а новообразованные слова от креативных сотрудников особенно требуют расшифровки. Например, от слов "эстимация" и "обфускация" новый сотрудник, знающий английский на уровне средней школы, входит в ступор. Также стоит составить список запрещённых к использованию слов и тем, поднимаемых на собраниях или в чатах. Например, шеф заставлял вместо "elucidate, describe" использовать только "explain", набрав в русскоязычную команду ребят из Восточной Украины под запретом стала тема мировой политики. Отрицательные моменты в познании нового через прочтение тоже, конечно, есть: самообучение без возможности задать сопутствующие и более подробно разъясняющие вопросы, нехватка условий (задания с ответами или примерами, оборудование для проб) для закрепления знаний, затраты времени на осознание (перевод) слов и терминов. Зато затраты на создание, хранение и актуализацию текстовых документов являются наименьшими в линейке типов передачи инфы. 
Передача знаний тактильно и по запаху возможна для некоторых продуктов: игры, кино, реабилитация здоровья, симуляторы редких и опасных профессий. Формы хранения, актуализации и передачи информации подобного типа пока ещё являются дорогостоящими и малодоступными широкому потребителю. Поэтому в качестве задания на закрепление мной излагаемого материала предлагаю эксклюзивным владельцам знаний тактильности и запахов описать способы передачи своего превосходства. К сожалению, мои примеры ограничиваются лишь 20 годами хореографии, развившими во мне мышечную память. Её применение помогает в тестировании довольно часто. Вы когда-нибудь задавали себе вопрос: "Почему в трёхпальцевой комбинации клавиш для перезагрузки 'Ctrl+Alt+Del' вы используете левые или правые клавиши 'Ctrl' и 'Alt'?" Как вас научили расставлять пальцы в первый раз, так вы и пытаетесь нащупать клавиши на любой клавиатуре. Пользуетесь обеими кистями рук или одним жестом Фиксиков? Чертыхаетесь на новом девайсе, когда не нащупывают в привычном месте нужную клавишу? А замечали за собой, что, прежде чем включить зарядку девайса, поглаживаете пальцами штекер? Да, это срабатывает ваша мышечная память для определения корректного положения "папа-мама/верх-низ".
Телепатия, как способ передачи знаний и прочей информации, некоторыми владельцами или заказчиками продукта считается наиболее приемлемым способом пояснить свои запросы. Вспомните те нередкие случаи, когда у собеседника кончались свои слова, а вы красиво и точно умудрялись описать его хотелки. Только они не учитывают тот факт, что подчинённые изначально не владеют чтением мыслей. Эта способность приобретается с годами при наличии постоянного контакта (наблюдение за процессом разработки, подслушивание обсуждений, получение информации из всех доступных и закрытых источников) и умении строить логические цепочки, в дальнейшем позволяет сотрудникам предугадывать желания руководства.
Соблюдая условия жанра, подведём итоги. Знаниями, которые вам кто-то дал или вы их приобрели самостоятельно, когда-нибудь надо делиться, передавать другим. Эффективность передачи знаний зависит от вашей подготовленности, но вы всегда получите дополнительную пользу - глубже поймёте суть и расширите собственный интеллект. Библейская заповедь о возврате розданного работает быстро и в ощутимом количестве. Знания не уходят в пустоту, существует много видов хранения и обогащения информации. Учитесь сами, обучайте других и затраты окупятся.

среда, 19 декабря 2018 г.

Храни меня..

Главное в работе тестировщика - сравнивать реализацию со стандартами. Для операции сохранения объекта стандартов нигде не прописано, значит мы в своих исследованиях должны оперировать привычными действиями от большинства крупных продуктов. Но с появлением Windows 10, как минимум одно приложение Notepad/Блокнот перестало быть логичным: окно редактора не закрывается по нажатию кнопки "х" с новосозданным файлом. Особенно странным выглядит это поведение на фоне всех остальных подобных редакторов, например, WordPad и MS Word.
Возможно аналогично размышляли и разработчики ClearSQL, когда программировали свой алгоритм для операции "Save As". По их мнению все изменения должны сохраняться как в новом проекте, так и в исходном оригинале.
По результатам моего возмущения на основе вышеописанных багов у меня родились две схемы об операциях сохранения объекта. Под объектом подразумеваю файл, проект приложения, строку таблицы или пакет базы и тому подобное.

Расширенная схема операций с объектом
1. SAVE / Операция доступна как для новосозданного объекта, так и для всех последующих его вариаций
1.1. объект существует
1.1.1. объект изменён
1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление
1.1.1.1.1. замена предыдущей версии объекта его новым вариантом / Обработка ошибок может выполняться на уровне операционной системы
1.1.2. объект не менялся
1.1.2.1. проверки файловой системы: доступ на запись/перезапись, изменение, удаление; разрешены изменения параметров объекта
1.1.2.1.1. замена параметров: даты-времени сохранения, без изменения даты создания объекта
1.2. новый объект создан
1.2.1. выбор места хранения нового объекта / Диалог выбора сервера/диска, папки для хранения объекта
1.2.1.1. присвоение имени новому объекту
1.2.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
1.2.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться  на уровне операционной системы
1.2.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
2. SAVE AS.. / Все изменения сохраняются только в новый объект. Первоначально открытая версия остаётся неизменной на момент открытия объекта в редакторе
2.1. выбор нового места хранения  / Диалог выбора сервера/диска, папки для хранения объекта
2.1.1. присвоение имени новому объекту
2.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
2.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
2.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
3. COPY TO..  / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
3.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
3.1.1. присвоение имени новому объекту
3.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
3.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
3.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
4. ARCHIVE / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
4.1. выбор одного или нескольких объектов для операции
4.1.1. уменьшение объёмов объектов / Функция стороннего архиватора
4.1.1.1. переформирование нескольких объектов в один / Функция стороннего архиватора
4.1.1.1.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
4.1.1.1.1.1. присвоение имени новому объекту
4.1.1.1.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
4.1.1.1.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
4.1.1.1.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
5. BACK UP / Операция доступна только для объекта без изменений или со всеми сохранёнными изменениями
5.1. выбор одного или нескольких объектов для операции
5.1.1. сжатие, группировка объектов в один объект или папку / Опциональная функция стороннего копировальщика
5.1.1.1. выбор места хранения / Диалог выбора сервера/диска, папки для хранения объекта
5.1.1.1.1. присвоение имени новому объекту
5.1.1.1.1.1. проверка существования одноимённого объекта / Обработка ошибок может выполняться на уровне операционной системы
5.1.1.1.1.1.1. проверки файловой системы: достаточность свободного пространства для всего содержимого объекта; доступ на запись/перезапись, изменение, удаление / Обработка ошибок может выполняться на уровне операционной системы
5.1.1.1.1.1.1.1. создание нового объекта в (файловой) системе / Операция выполняется (операционной) системой
6. DUPLICATE / Операция выполняется на основе последней сохранённой версии объекта. Количество дубликатов и новые уникальные идентификаторы объектов изменяются в процессе операции.
6.1. определение количества копий
6.1.1. авто-определение места хранения новых объектов / Используется внутренняя настройка редактора
6.1.1.1. проверки: прав на создание новых объектов, на объём свободного пространства / Обработка ошибок может выполняться на уровне операционной системы
6.1.1.1.1. авто-присвоение новых имён объектам  / Используется внутренняя настройка редактора
6.1.1.1.1.1. создание новых объектов / Внутренняя функция редактора
7. CLONE / Операция выполняется на основе последней сохранённой версии объекта. Копия возможна только одна, уникальный идентификатор объекта изменяется в процессе операции.
7.1. авто-определение места хранения нового объекта / Используется внутренняя настройка редактора
7.1.1. проверки прав на создание нового объекта, на объём свободного пространства / Обработка ошибок может выполняться на уровне операционной системы
7.1.1.1. авто-присвоение нового имени объекту / Используется внутренняя настройка редактора
7.1.1.1.1. создание нового объекта / Внутренняя функция редактора
8. Закрытие редактора с сохранением объекта / Диалог Save или Save As.. для сохранения объекта открывается в перечисленных случаях
8.1. кнопка ОК
8.2. кнопка Yes to All
8.3. кнопка "х"
9. Закрытие редактора без сохранения объекта / Редактор закрывается без предложения о сохранении изменений объекта в перечисленных случаях
9.1. кнопка Cancel
9.2. кнопка No to All
9.3. кнопка Skip
10. Параметры объекта, устанавливаемые/изменяемые в редакторе / Настройки объекта определяются в параметрах редактора, но могут изменяться в процессе сохранения
10.1. формат/расширение файла
10.2. тип данных столбца в таблице БД
10.3. статус подобъекта в проекте
11. Полезняшки/Удобства
11.1. горячие клавиши
11.1.1. Ctrl+S
11.1.2. Ctrl+Shift+S
11.1.3. самонастраиваемые/внутренние для редактора
11.2. стандартные окна и диалоги операционной системы
11.3. авто-предложение места хранения, локализация папки
11.4. фильтр расширений файла
11.5. авто-предложение нового имени объекта
11.5.1. по шаблону
11.5.2. постфиксы/префиксы
11.5.3. с добавлением даты-времени

Краткая схема обращения с объектом
1. Запустить редактор
2. Открыть объект в редакторе
2.1. редактор оставляет исходник как резервную копию в оригинале (место, имя, другие параметры)
2.2. редактор делает копию объекта во временном пространстве, но с темже именем
2.2.1. редактор отображает объект для последующей работы
2.2.1.1. в объект вносятся изменения
2.2.1.1.1. выполнить Save
2.2.1.1.1.1. резервная копия заменяется рабочей версией
2.2.1.1.1.2. обе идентичны
2.2.1.1.2. выполнить Save As..
2.2.1.1.2.1. рабочая версия объекта сохраняется в новое место с новым именем
2.2.1.1.2.1.1. новая версия объекта копируется во временное рабочее пространство, но с темже новым именем
2.2.1.1.2.2. резервная копия остаётся со старыми параметрами: место, имя, без модификаций
2.2.1.1.3. выполнить Clone, Duplicate, Back Up, Archive
2.2.1.1.3.1. проверка на наличие изменений
2.2.1.1.3.1.1. рабочий объект отличен от оригинала, вносились изменения
2.2.1.1.3.1.1.1. предупредить об изменениях
2.2.1.1.3.1.1.1.1. предложить применять операцию к объекту с изменениями
2.2.1.1.3.1.1.1.1.1. изменения объекта сохраняются / Сохранение в авто-режиме или через диалоговое окно
2.2.1.1.3.1.1.1.1.1.1. выполняется операция для рабочей версии, идентичной оригиналу
2.2.1.1.3.1.1.1.2. предложить откатить все изменения и применить операцию к исходной копии
2.2.1.1.3.1.1.1.2.1. рабочая версия с последними несохранёнными изменениями уничтожается
2.2.1.1.3.1.1.1.2.1.1. создаётся новая рабочая версия объекта из оригинала
2.2.1.1.3.1.1.1.2.1.1.1. выполняется операция для рабочей версии, идентичной оригиналу
2.2.1.1.3.1.2. рабочий объект и его оригинал идентичны, изменений не вносилось
2.2.1.1.4. закрыть редактор / Закрыть окно редактора можно: из меню Exit/Close, по кнопкам интерфейса "х" или Close, по нажатию горячих клавиш Alt+F4 (стандарт в Windows). При наличии изменений в объекте закрытие редактора зависит от ответа в диалоге о сохранении объекта.
2.2.1.1.4.1. предупредить о наличии изменений
2.2.1.1.4.1.1. диалог о сохранении объекта закрывается по кнопке OK, Yes, Yes to All, Save
2.2.1.1.4.1.1.1. изменения объекта сохраняются  / Сохранение в авто-режиме
2.2.1.1.4.1.1.1.1. оригинал заменяется рабочей версией: запись поверх или уничтожение оригинала и копирование рабочей версии на место оригинала
2.2.1.1.4.1.1.1.1.1. удаление рабочей версии из временного пространства
2.2.1.1.4.1.1.1.1.1.1. закрытие редактора
2.2.1.1.4.1.2. диалог о сохранении объекта закрывается по кнопке No, No to All
2.2.1.1.4.1.2.1. оригинал остаётся неизменным
2.2.1.1.4.1.2.1.1. удаление рабочей версии из временного пространства
2.2.1.1.4.1.2.1.1.1. закрытие редактора
2.2.1.1.4.1.3. диалог о сохранении объекта закрывается по кнопке Cancel, Close, "x"
2.2.1.1.4.1.3.1. оригинал остаётся неизменным
2.2.1.1.4.1.3.1.1. рабочая версия остаётся в прежнем состоянии
2.2.1.1.4.1.3.1.1.1. редактор остаётся открыт с рабочей версией объекта
Дальнейшие операции (редактирование, перемещение) применяются к рабочей версии, идентичной оригиналу

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

четверг, 30 августа 2018 г.

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 и имеют единые модули.

суббота, 23 июня 2018 г.

Issue review (ГКЧП-2)

В Agile команде оформлением задач занимаются все – QA (по совместительству - тестировщики, аналитики, техподдержка), PM (в теории – главный аналитик, а на деле – только регулятор работ), разработчики (в основном понятии слова их первоочередной обязанностью и является конкретизация условий задачи). А поскольку у каждого человека свой "почерк" (забывчивость правил и отсутствие знаний как признак индивидуальности), то на понимание задачи у программиста и тестировщика уходит не мало времени (см. "Дорогие trivial-ы"). Дабы ускорить общекомандное время разработки продукта нужна унификация оформления. Jira частично помогает автоматизировать процесс, но кроме обязательных полей ускоряют понимание и некоторые пользовательские поля.

Проверку новооформленных задач можно разделить на ступени: достаточность обязательных полей, необходимость данных во вспомогательных полях, лингвистическая грамотность. Не обязательно, а даже желательно, разделить степени ответственности за оформление на разных сотрудников – от тех.писателя до заказчика.

Рассмотрим поля в Jira, заполняемые в команде Conquest Software Solutions при создании задач.

* Project Name. Корректность выбора продукта может проверять любой член команды, знающий все разрабатываемые продукты команды, чтобы идентичная задача была выполнена во всех глобальных и интеграционных модулях. Если вовремя не оформить задачу на все связанные продукты, то на доработку может потребоваться в несколько раз больше времени, нежели программист продумает один алгоритм для всех продуктов в едином скрипте.

* Issue Type. У тестировщиков постоянная дилема – баг или фича. От типа задачи зависят тексты заголовка и описания: для бага заголовок пишется в утвердительном наклонении (Проблема есть там-то при таких-то условиях), для новшества – в повелительном (Сделать что-то где-то по другому, новому). В зависимости от правильно выбранного типа задачи можно автоматизировать создание текста в поле Description. Проверка корректности поля Issue Type неразделима с проверкой полей Summary, Description. От типа задачи зависит список бэклога спринта: планирование новой версии в Conquest Software Solutions с помощью эдона Structure зависит только от объёма разработок, Project Manager при выполнении обязанностей scrum-master не включает ни старые, ни новые баги в план выпуска, эстимация фиксов багов не проводится и для публикации фикс-билда. В первую очередь тип задачи должен проверять на корректность Project Manager или Product Lead.

* Summary. Текст заголовка задачи надо проверять лингвисту, тем более, что его содержимое зависит от типа задачи, а чаще заменяет даже полное описание (Description). Текст должен быть в повелительном наклонении для предложений об усовершенствовании или новинок (Сделать что-то где-то иначе), и в утвердительном – для багов (Проблема такая-то есть там-то при таких-то условиях). Удобно создавать Summary беря за подсказку два правила "Что-Где-Когда" (в одном предложении вся суть) и "краткость – сестра таланта" (текст не должен быть более 5-7 слов и без знаков препинания). Единовременно человек запоминает не более 7 символов. Хорошим тоном у публицистов считается однозначность восприятия заголовка при отсутствии знаков препинания.

* Components. Список модулей, в которых проявляется баг или нужны дополнения, лучше других проверит сотрудник, кто проверяет и Project Name. Программисту дешевле составить сразу один алгоритм на все модули, нежели дорабатывать их после возврата задачи. Тестировщику тоже дешевле составить комплексный тест-план, зная полный список мест для интеграционной задачи.

* Affect Versions. Точное соответствие версии продукта, где был выявлен баг, а также наличие бага в текущей разрабатываемой версии сокращает время программисту для поиска причин ошибки или истории её появления. При составлении Release Notes по импрувам точный номер билда, отличный от текущего опубликованного, показывает временность предложения. Для техподдержки и QA точный номер билда, в котором импрува не было, сокращает время поиска билда, работавшего благополучно, без регрессии.

* Priority. Blocker-Critical-Major-Minor-Trivial. Каждая команда определяет свой список приоритетов. О смысловой нагрузке лучше договориться заранее, так как руководитель или заказчик понимают даже слово Blocker/Fatal по разному: кто-то блокером/фаталом считает лишь ту проблему, при которой продукт не запускается, а кому-то достаточно грамматической опечатки. Сочетание с Business Value и Issue Type проверяется старшим по продукту.

* Business Value. Пользовательское числовое поле, аналогично Severity. Со значениями обязательно договориться внутри команды. Старая BTS имела простую систему – от 0 до 99, новая была усложнена Project Manager: наивысший 10 может быть только у Blocker, Critical и в случае "пятиминутки" (см. "Дорогие trivial-ы" ) у Trivial; 11 разрешено давать Critial или Major, 12 как минимальное только для Major, Minor могут быть со значениями 13, 14, 15, и т.д.; Trivial в большинстве должны быть 15 и более. Логичнее и проще, конечно, основываться на обычных баллах от 0 до 100 или от 1 до 10(5). Но если выбрана сложная зависимость от Priority, то проверка на корректность оформления обязательна, и лучше от имени старшего программиста или заказчика.

* Environments. Не для всех задач нужны особые условия, но если их не упомянуть (продублировать) в собственном поле, то при кодировании и проверке тестировщиком будет перерасход времени. На этапе оформления задачи системное окружение лучше проверять разработчикам или системным аналитикам.

* Labels. Система пользовательских лейбл упрощает фильтрацию задач в Jira. Наличие или отсутствие особых лейбл при оформлении может быть тесно связано со значениями полей Affect Versions, Fix Versions, Priority, Business Value, Issue Type. Композицию этих полей следует модерировать в несколько стадий. Примеры лейбл:
actual (отмечаются задачи во время процесса актуализации после выпуска очередной версии, не может быть у новооформленной),
internal (задача с такой отметкой не входит в Release Notes, имеет невысокий приоритет проверки, содержимое нужно только для внутреннего использования командой),
fix_in_component (отметка об особенности правки, влияющей на множество иных модулей и продуктов, требует полного перечисления модулей/продуктов/скриптов с исправленным компонентом для полноценных интеграционных тестов),
fix_in_official (фикс должен войти в текущую опубликованную версию, лейбла помогает фильтровать задачи перед выпуском фикс-билда, фикс и тестирование проводятся в первую очередь, обязательно наличие последнего опубликованного билда в Affect Versions),
fix_in_previous (фикс должен войти в предыдущую опубликованную и до сих пор поддерживаемую версию, лейбла помогает фильтровать задачи перед выпуском фикс-билда, фикс и тестирование проводятся в первую очередь, обязательно наличие предыдущей версии в Affect Versions),
fix_in_rc (фикс должен войти в ближайшую публикуемую версию, лейбла помогает фильтровать задачи перед выпуском новой версии, фикс и тестирование проводятся в первую очередь, обязательно наличие планируемой версии в Fix Versions для импрувов),
non_actual (отмечаются задачи во время процесса актуализации после выпуска очередной версии, не может быть у новооформленной, признак для автозакрытия программистом или старшим по продукту),
rare (редкие задачи могут иметь только Minor или Trivial приоритет и Business Value не выше 15, фикс и тестирование в таком же низком приоритете, обязательно упоминание условий редкости в Description и Environments),
regression (проблемы, как следствие нововведений, должны исправляться в первую очередь, не может иметь Affect Versions равным опубликованным билдам без исходного импрува, обязательно наличие линков с исходным импрувом),
temporary (не может быть у новооформленной задачи, пометка нужна для отсеивания из Release Notes, промежуток между Affect Versions и Fix Versions не должен перекрывать опубликованные билды),
waiting_for_feedback (некоторые задачи невозможно полноценно оформить без подтверждения заказчика или какого-то специалиста, наличие лейблы оправдывает незапланированный Status).

* Status. Баги планирует оформитель задачи, импрувы – только скрам-мастер и добавляет их в Structure. Любой может проверить корректность оформления совокупности полей Status-Issue Type-Fix Versions-Structure и сообщить о проблемах оформителю или PM.

* Bug_Hunter. Пользовательское поле в помощь к Reporter и Creator. Не всякого пользователя продукта можно добавить в список для выбора в поле Reporter, поэтому строковое Bug_Hunter помогает отсеить задачи конечных пользователей. За оформление поля отвечает сотрудник тех.поддержки, если поле не пустое, то в Description или Comments указывается способ связи с клиентом или его контакты.

* Assignee. Столь удобное автозаполнение по продукту или компоненту не всегда получается актуальным. В одной задаче можно обозначить несколько модулей, а связка с ответственным сделается по одному из модулей в алфавитном порядке. Назначенность задания надо перепроверять старшему программисту или руководителю команды.

* Fix Versions. Трёхзначный номер версии (без билда, только [Major-Minor-Release]) оформляется для импрувов, входящих в бэклог выпуска. Новооформленные баги должны быть с пустым значением. Актуальность поля лежит в ответственности QA.

* Resolution. У новооформленной задачи через клонирование может получиться некорректное значение, сбивающее с толку руководство и исполнителя. Сменить его можно во время перехода статусов.

* Description. Один из самых важных параметров задачи необходимо проверять в несколько этапов. Для ускорения работы и унификации текстов в Conquest Software Solutions были настроены два шаблона Баг и Импрув с точным использованием заголовков, стилей и фонтов, межстрочных интервалов. Для срабатывания (автовставка текста в поле Description) шаблонов необходимо создавать задачу в два этапа: сначала выбрать Product, Issue Type, Components, напечатать что-нибудь в поле Summary, создать задачу в Jira, при этом якобы пустое поле Description автоматически будет оформлено шаблоном в зависимости от выбранного типа задачи:

 шаблон для типа BUG:

Introduction:

[Enter text of issue history. Optionally.]

User wrote:

{quote}

[Enter text from end-user. Optionally.]

{quote}

(OSD=[Enter OSD message number. Optionally.])

Steps to reproduce:

[List steps of actions. Mandatory.]

Actual result:

[Describe actual, detailed result of actions in product. Mandatory.]

Expected result:

[Describe the detailed expected result of actions in product. Mandatory.]

Notes:

[Explain additional information. Optionally.]
  шаблон для типов NEW FEATURE, IMPROVEMENT:

Introduction:

[Enter text of issue history. Optionally.]

User wrote:

{quote}

[Enter text from end-user. Optionally.]

{quote}

(OSD=[Enter OSD message number. Optionally.])

Resolutions:

[Describe the detailed expected result. Mandatory.]

Notes:

[Explain additional information. Optionally.]

При проверке на соответствие стандарту Project Manager отказывал в планировании импрувов, если не хватало пустой строки между абзацами или заголовок не был bold, либо банально удалял задачу и передавал оформление "дубликата" иному сотруднику без пояснения несовпадений с шаблоном и не принимая во внимание возможность смены типа задачи после её создания. Ещё один неудобный момент использования шаблонов заключается в автоматическом перевыборе Assignee в момент применения шаблона, но при этом в истории задачи логгируются изменения от имени автора шаблона.

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

На полноценность текста влияют многие поля: Product (задача может быть склонирована для нескольких продуктов), Issue Type (шаблон зависит от типа задачи), Summary (не должно быть логического противоречия в кратком и подробном описаниях), Affect Versions (в примечаниях указываются отличия версий), Attachments (наличие и соответствие имён упомянутых прикреплений), Components (нет необходимости дублировать модули в полном описании, но есть смысл перечислить затрагиваемые скрипты в комментариях для облегчения составления плана фикса и проверки), Environments (особые настройки желательно перечислять в блоке Notes), Labels (некоторые из лейбл требуют детализации), Bug_Hunter (если в поле есть ID конечного пользователя, то строка про номер OSD не может быть пустой в описании; к сожалению, поиск в текстах Jira подразумевает своё определённое совпадение символов, поэтому фильтр по задачам от юзеров сложный).

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

* Comments. Для новооформленной задачи комментарии не нужны, но проверяющий может указать имя оформителя или иного члена команды через символ "@" для более быстрого реагирования на замечания к описанию.

* Links. "Проверка одной задачи порождает как минимум две новые". У любого бага существует задача-импрув, породившая его. Даже отчёт от конечного пользователя не был бы создан, если бы не появилось что-то новое в продукте. Связь бага с породившим его импрувом – 50% помощи программисту для исправления. TestSession в режиме исполнения и функция клонирования линкуют автоматически. Список линков может быть расширен Jira-пользовательскими настройками, например, "Устаревшая задача + Отменяющая задача".

* TestSession. При подключенном плагине Capture в Jira появляется возможность более подробно описать и выполнить проверку фикса. Оформлением тест-сессии занимается тест-лид, расписывает тест-план и назначает тестировщика-исполнителя. Тест-сессия создаётся только для сложных задач, подразумевающих комплексное тестирование. Полноценность тест-плана проверяет Team Lead.

* Structure. По необъяснимому и упрямому желанию Project Manager в компании Conquest Software Solutions в Structure добавляются задачи только типов Improvement и New Feature. Каждая задача включается в бэклог при оформлении, а не при планировании ближайшей версии продукта. В бэклог задача добавляется до эстимации (оценки затрачиваемого времени) членами команды (аналитик-программист-тестировщик). Поэтому корректность оформления возложена только на самого PM, а для всех остальных членов команды оно всего лишь информативное.

* Due Date. Дата, к которой задача должна быть исполнена, напрямую зависит от планов (Status, Structure, Fix Versions). Заполнение поля производит планировщик бэклога, информация важна исполнителям (в Assignee выбирается только программист, у которого не всегда есть право публикации) и проверяющему исполнение (в Conquest Software Solutions не оформляются отдельные задачи для тестирования и публикации каждого импрува, не переназначаются Assignee, поскольку фактический объём работ тестировщиков никак не учитывается).

* TO-DO. Чек-лист для типа задачи Task. Необязательное к заполнению поле используется в основном для чек-листов выпуска билда, когда мелкие шаги задачи должны выполнять разные сотрудники (QA, DevOps, ..). Полноценность оформления желательно контролировать руководящему составу.

Why "issue review"?
Основная причина необходимости проверки новых задач в том, чтобы сократить время на последующую разработку – отвлекать оформителя от текущих дел более накладно в момент разработки, нежели по горячим следам в день оформления.

Как много времени и сил нужно на проверку? Если эффективно распределить обязанности, то не более 20-30 секунд на каждую задачу. Если всю проверку делать один раз в день/неделю, то "набитый глаз" позволяет ускорять процесс.

Позднее аккумулированный объём знаний ускоряет принятие решений сотрудниками техподдержки при определении причн проблем от пользователей, дальнейшая разработка новинок сразу учитывает имеющиеся нюансы. А в случае большой текучки кадров не приходится искать виновных в недооформленности, поскольку тонкости учтены заранее.
Наименование поля Project Manager, Заказчик Team Lead Лингвист Член команды
Affect Versions 1-2 сек
Assignee 3-5 сек
Attachments 1-2 сек
Bug_Hunter 1-2 сек
Business Value 3-5 сек
Comments 1-2 сек
Components 3-5 сек
Description 2 мин 10 сек
Due Date 1-2 сек
Environments 3-5 сек
Fix Versions 3-5 сек
Issue Type 1-2 сек
Labels 1-2 сек 1-2 сек
Links 3-5 сек
Priority 1-2 сек
Project Name 1-2 сек
Resolution 1-2 сек
Status 3-5 сек
Structure 3-5 сек
Summary 3-5 сек
TestSession 0 сек - 1 мин 3-5 сек
TO-DO 0 сек - 1 мин 3-5 сек
ИТОГО: 14-24 сек 7 сек - 2 мин 12 сек 2 мин 3-5 сек 30-56 сек

Ещё одно преимущество в проверке новых задач всей командой – можно сократить количество собраний о проделанной и планируемой работе. Ознакомление каждого члена команды о направлениях развития продуктов через новые задачи упрощает понимание целей разработки. Получается, что все в курсе всех дел всегда.