С Днём профи-проггера!

Осенью 1986 года было моё первое погружение в IT через членство в клубе компьютерщиков при транспортном ВУЗ-е, а уже в феврале 1987 года результат моих  работ был представлен на внутривузовской конференции. На освоение компьютера и изучение языка ФОКАЛ мне понадобилось около двух месяцев. Да, чтобы начать программистскую деятельность нужны минимальные знания, а чтобы стать тестировщиком понадобится не только развитое логическое мышление, но и много разных навыков по всем стадиям разработки продукта. Официально в моей трудовой книжке запись о должности программиста появилась после двух классов школы и пяти лет института, а в тестировщики переход был только спустя девять лет программирования. В поэтическом плане роль тестировщика меня сподвигла на литературный выхлоп уже на третий месяц в деле, а вот программирование зрело долгие двенадцать лет. Ниже читайте о том, как мне работалось программистом в конце XX века.

Машина тоже чувствовать умеет.
Она с тобой болеет и сопереживает.
Не ладится судьба, - и у неё чой-то замыкает.
А если у тебя идёт всё гладко, тогда и ей не требуется отладка.
Моргнёт глазком зелёным, ритмично засверкает красным,
Засветится экран. И ты в строке, немногим ясной, но всё ж тебе во всём понятной,
Увидишь тот набор значков и закорючек, в которых смысл скрыт того, что он не глючит.
Но тут всё замолкает.
Клавиатура пискнет, принтер щёлкнет, и по модему огонёчки пробегают.
Для связи auto оставляю. И приложения постепенно запускаю:
Одно, второе. Это и вот это. У гороскопа* собственного спрошу совета.
Отмечу в хит-параде** все места, от "Ум за разум" - слово. И в дела!
На день рождения - акростих. Для друга - копию, чтоб от тоски не сник.
Так. На заказ на Delphi код в сто строк пишу лишь мышкой. И успею в срок.
Вот тут подправлю. Здесь чуть-чуть пошире, а остальное отрезаю. Пусть гниёт в корзине.
Пожалуй, всё готово. На проверку. 

Пример: один, второй, … , десятый. Для юзера дубового на этом хватит.

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

----------

*гороскоп - программа написана была дилетантски, для практического изучения языка программирования.

**хит-парад - компьютерная программа для музыкального радио "РИФМА" была разработана, написана и внедрена в рамках семилетнего статуса радио-критика на общественных началах.

Профессионалы в процессе

В 2000-2003 годах офшорная компания RSC создавала и поддерживала программный комплекс "Практик-А", написанный на Oracle Forms (упоминаются актуальные горячие клавиши). Основатели компании в 2002 году отмечали юбилей и предложили всем сотрудникам творческий конкурс. На тот момент в мои обязанности входили тестирование и тех.поддержка (СТП - служба технической поддержки), но тестировщики всюду суют свой нос, поэтому рассказ получился более чем полный. Никакого приза моя работа не выиграла. К сегодняшнему Дню Тестировщика публикую свой опус. Может кого-то из вас он сподвигнет на что-то большее.

Как RSC создаёт "Практик-А".

Этап первичный. Все на старте. У аналитика разгон:

Собрать все нужные нюансы готов, бумажки собирает он.

То с шефом часик поболтает, то с рядовыми день иль два.

За все мучения награда ему - подробностей стопа.

И маркетолог потихоньку в контракте правит пункт "Права":

Для конкурентов нет лазейки, им предстоит всё сызнова.

А тестировщик пишет планы: с кого начать и что потом,

Чем протестировать экраны, чтоб не осталось за бортом

Предупрежденье: интерфейсы - не для слепых и старых дам,

И каждому объекту - место, чтобы не рыться по хелпам.

Этап второй - разгар событий. У каждого заданий тьма.

Тут время маленьких открытий. Без плана - хаос и кутерьма.

С завода аналитик едет в родные стены напрямки,

Где и в жару и в холод лютый рисует, как Малевич, уголки.

Для главного определяет он место в центре, а затем

Для "дочек" сущности вставляет, связуя их в контексте тем.

Пока что он один лишь знает, как будет выглядеть Проект,

Какие будут отношенья, с чем, сколько, видно или нет.

Он программёру составляет набросок действий, чтобы тот

Без промедленья и задержки составил правильнейший код.

Проектировщики в короткий срок набьют пакетов кучи строк.

Ошибки ввода ограничит "primary" или "unique" ключик.

Ну, а для верности значений есть "trigger", "view" и "value check".

Они - такие, они - шальные. И целый день глядят в экраны, как хмельные,

По клаве дробь стучат и мышку тискают, чтоб новый образ формы получить.

"Create"-ом и "insert" таблицу сляпают, а если что не так, то тут же "alter"-нут.

На ввод - "commit"-ы есть, не хочешь - "rollback". Готов проект, на тест несут.

Здесь тестировщицы - вреднюги. Заметят каждый баг и ляп.

Где хелп? И что за сокращенья? Симметрий нет! А выйти как?!

Бедняжка форма стонет, плачет под натиском таких задач,

Считая ввод запоминает и направляет на печать.

Сто раз поправят программёры, сто двадцать тестер скажет: "Нет".

Чтобы Проект стал идеален, не жалко им ни сил, ни лет.

Когда порядок полный на этапе, на все ошибки исправленья есть,

Тут техподдержка и рекламодатель в свою узду впрягают всех.

Новинки или дополненья описаны уже давно.

Вот начался этап внедренья. Для праздника время пришло.

И на заводе оживленье: команда к ним летит от нас.

Научат, сервер установят и юзерам покажут класс.

Горячих клавиш стройный ряд любой проблеме будет рад.

Что делать - "F1" нажмите, не ладится, тогда с "Shift"-ом.

А коль забыли "кто есть в кнопках", то - "Ctrl" с "F1". Всё в нём.

Чтоб сосчитать объёмы строк - с "Shift"-ом "F2". Ну, и потом

"F3" дублирует объект, а с "F4" проблем нет:

Всю предыдущую строку в пустую вставит, как свою.

Неверно? Есть "Shift+F4": очистит строчку, как и было.

Гулять в режимах и по окнам "F5" поможет, а с "Shift"-ом,

Мой друг, уж будь ты осторожен: всё пусто будет в блоке том.

Достопочтенная "F6". Нужна строка? Вот она есть!

Всё лишнее с "Shift"-ом "F6" как зверь голодный может съесть.

На пару кнопок честь возложена запросом базу фильтровать:

"F7", и вводишь всё искомое, "F8" не забудь нажать!

Когда же в форме всё не так - с "Shift"-ом "F7" - она пуста.

"Shift+F8". Сбросьте страх: через принтер - на листах.

Значенье подобрать из списка "F9" Вам поможет быстро,

Лишь с "Ctrl"-ом её нажмёте, иерархией пункт подберёте.

Пора запомнить измененья: "F10" - и итог мученьям.

"Tab" переходит по полям, "Shift+Tab" по ним же, но назад.

Вас "Ctrl+Tab" вперёд ведёт, а всё с "Shift"-ом в окно вернёт.

Не только "Esc"-ом отменяешь, есть "Ctrl+U" им очищаешь.

По окнам "Page Up Down" ходят, когда их с "Ctrl" наберёшь.

А стрелки по строкам поводят, при спешке их с "Shift"-ом нажмёшь.

Есть "Ctrl+E" для тех, кто хочет значенье в поле поменять.

И "Ctrl+Q" в Проекте пашет, чтобы закрыть иль отменять.

А пользователь не лыком шит, чуть что не так, и в СТП звонит.

Скрипты, скрипты… Им нет предела. Исправить то, добавить сё.

На СТП опять облава, успеть им надо пропатчить всё.

Домой вновь едет аналитик с заданьями, чтобы Проект

Шире и дальше развивался, добротно работал много лет.

Всё смогут наши программисты, когда у них есть за спиной

Hi-аналитики - специалисты. А SQL для них - родной.

Команда к трудностям готова, исполнит каждый Ваш каприз.

Для современных технологий есть "Практик-А". На цену не скупись.

P.S.

Коль слишком гладко, не кривитесь, ведь строчки сами легли в ряд.

Кому не любо, не гневитесь, e-mail мой примет всякий баг.

Свои рецензии оставьте. За труд прочтения себя поздравьте.

(июль 2002 года)

Рационализаторы

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

В первой половине 1990-х годов, будучи программистом АСУП-а крупного завода. мне не раз перепадала премия за рационализаторство. Дело в том, что первую свою программу мне пришлось писать для отдела труда. Это был расчёт среднесписочной численности. 

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

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

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

После первой моей программы для расчёта среднесписочной численности последовали ещё несколько самописных, за которые начальнику отдела тоже удалось выхлопотать премии (и себе в том числе). Но когда завод вступил в корпорацию, и она навязала внедрение готового комплекса программного обеспечения (а-ля "ПК Галактика" или "Axapta"), то о премиях за рационализаторство пришлось забыть, поскольку завод тратил эти средства на покупку комплекса. Даже за привязку наших самописных программ или импорт данных из них в комплекс уже не позволялось выписывать рационализаторские премии. Да и сейчас отделы АСУП при крупных предприятиях перестали создавать свои программы, а в основном их деятельность сводится к поддержке готовых продуктов.

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

А как вы думаете, может ли ещё быть взрыв рационализаторства в области создания программного обеспечения, как это было в конце XX-го века?

Программа иль дитя

Конечный результат любой группы разработки - продукт. Если речь о ПО, то каждый из группы разработки относится к своей работе и программному продукту, как к некому детищу, в которое вкладывают свои силы и умения по мере возможности. Даже программист-одиночка и тот не может выпустить программу без минимального тестирования, то есть код он пишет моментально, как Папа оплодотворяет Маму, а потом довольно долго отлаживает и тестирует, подгоняет и исправляет, то есть вынашивает Дитя, как беременная самка. Редко в мире и программном производстве встречаются гермафродиты, которые качественно могут проверить свой же код. Также, как и в большой семье, жить и развиваться Дитя может только при генетической поддержке Дедов, Родителей, при финансовой поддержке богатых Дядюшек и Тётушек. Младенец нуждается в питании, точно также, как и программа в наполнении функционалом. Эта часть жизни очень схожа с периодом, когда продуктом занимается аналитик или ребёнком Няня (бабушка, тёща). Взрослея подростку уже нужны не только био-вливания, но и моральные, а этот период очень схож с воздействием на продукт со стороны техподдержки через отзывы пользователей, а на дитя - Гувернёром. Более научный опыт дитя получает от Репетиторов, а программа становится равнозначно понятной как производителям, так и потребителям за счёт усердий техписателя. Раскруткой и развитием Отрока в семье обычно занимаются Кузены, которые играют с ним, знакомят с обществом ровесников и выводят в свет, подобно рекламно-маркетинговому отделу при публикации программы. На программу в расцвете сил, как на совершеннолетнего человека, начинается охота со стороны пользователей, а на Молодёжь устремляют свои взгляды лица противоположного пола для создания новых семейств, производства и семьи сливаются словно интеграция продуктов. 

Однообразие межродственных и производственных связей и влияний

В последнее воскресенье ноября отмечается день матери. А кто вы есть для своей программы? Как много вы заботитесь о продукте вашей группы разработки? Кому достанутся все лавры, когда закончится проект? Замечают ли ваши сотрудники ваш в клад в дело? Или, как и во всех семьях, воспринимают всё как должное, без необходимости благодарности? Группа разработки, задумайтесь пока не поздно и оцените труд тестировщиков по достоинству. Ведь только в тестировании и материнской заботе ребёнок и программа формируются в нечто полезное обществу.

Publishing cheat-sheet

Эта статья будет полезна тем, у кого разрабатывается десктопный продукт, распространяемый через инет-магазин.
Компания Conquest Software Solutions вышла на рынок с одним десктопным продуктом в 2002 году, с 2005 года стала продавать его через свой сайт, а с 2007 расширяла линейку продуктов. На сегодняшний день это 4 (SD, CS, CDB, FADEX) платных продукта, 1 (DV) бесплатный вспомогательный и 2 веб-продукта (site, WDV). Публикация некоторых из них всегда связана с дочерними, но в основном шаги к успешной публикации одинаковы. Несколько вариантов установки и обновления продукта упрощают работу конечному пользователю, но в теже несколько раз усложняют уровни проверок при публикации. Если в день получения бага от юзера тестировщик - это его адвокат, то в день выпуска QA становится на тёмную сторону и готов быть не только судьёй, но и прокурором для всех юзеро-хотелок.
До тех пор, пока публикацией заведовали только единственный тестировщик и единственный веб-разработчик, процесс протекал без сбоев. Но случалось так, что у кого-то был отпуск, а выложить билд надо было срочно. Тогда процесс не соблюдался в точности, потому что план действий лежал только в голове тестировщика, а веб-программист нажимал кнопки по его запросу. В итоге, конечный пользователь испытал проблемы со скачкой.
Шеф однажды спросил у меня, почему когда я выкладываю билды, то юзер никогда не жалуется. Мой ответ был прост: действия отработаны до автоматизма, и в день билда на листочке с Release Notes публикуемого продукта все пройденные этапы из моей головы перекочевывали на визуальный элемент. К сожалению, хоть и некоторые шаги были одинаковы для продуктов или типов (официальный, бета, специальный) билдов, но автоматизировать процесс даже частично было не на чем (фин.директор жадничал на тулзы, а бесплатных для самописных Delphi-элементов не было и нет). Тогда шеф решил частично помочь. Поскольку BTS у нас была самописная, то в Oracle базе он добавил таблицы, столбцы и триггеры на них, то есть автоматически формируемый список шагов для публикации.

Шаги делились на период ДО закрытия сайта для заливки и ПОСЛЕ операционные. Один триггер срабатывал для таблицы билдов и версий в момент добавления планируемого выпуска: в таблицу чек-листа добавлялся стандартный набор записей с указанием порядка действий для публикации определённой версии. В день публикации выпускающие тестировщик и программист проставляли дату-время каждой записи. Это значительно уменьшило количество проблем "заместителям публикаторов". А когда весь список очищался (таблица велась в "SD/Built-In VCS/SmartDataset" и активно использовались встроенные утилиты редактирования и фильтрации), то срабатывал следующий триггер, отправлявший e-mail нотификации руководству и иным заинтересованным лицам об успешном окончании работ с подробной инфой о выпущенном билде. 
На момент создания первого чек-листа выпуска он состоял из десятка пунктов, в основном касающихся сайта. Но со временем этот список стал пополняться и детализироваться проверками инсталлятора, апдейтера, лицензионных артефактов. Необходимость в расширении списка диктовалась процессом разработки, который касался различных сторон продуктов и сайта. Несколько систем апдейта (с сайта, из файловой системы, через инсталлятор или OSD Updater), заказанные пользователями, частая смена лицензирования, улучшения в системных требованиях увеличивали и количество пунктов чек-листа. Большей частью пункты дробились и конкретизировались.
С расширением штата и переходом на Jira+Confluence ведение чек-листа обзавелось документацией.

К сожалению, в Jira 2014 года не существовало аналога нашим чек-листам. Поэтому решено было оформлять задачи типа TASK (Feature, Improvement, Bug не очень подходили по стилистике, к тому же фича чек-боксов Jira Plug-in TODO была возможна только для одного типа задач) в каждом из выпускаемых продуктов.

Для удобства работы были одобрены следующие мои предложения по оформлению задачи:
- Product = [ProductName]. Для каждого продукта создавались свои задачи, в префиксе которых значились буквы короткого имени продукта, но они же дублировались и в Summary для упрощения фильтрации;
- Summary оформляется по формату "Publish [ShortProductName] [Major].[Minor].[Release]  [major|minor|release|spec-build|fix-build] [official|beta]". По короткому имени задачи было ясно, что конкретно будет публиковаться - бета или спец.билд, новая версия или текущие исправления. Например, "Publishing SD 4.7.2 release official" - публикация всем второго релиза платной версии 4.7 продукта SQLDetective, "Publishing SD 5.0.1b spec-build" - выкладывание специального билда бета-версии 5.0 продукта SQLDetective;
- Type = "TASK". К сожалению, только для одного типа задач админ Jira смог прикрутить поле TODO;
- Priority = "Major". Важность задачи велика, но не критична и не блокирует иную работу. К тому же есть дополнительное поле Business Value с самым высоким значением;
- Affected Versions = [LastPublishedBuild]. Последний опубликованный билд давал информацию всем заинтересованным сторонам: скрам-мастер подбирал задачи для бэклога и отчитывался перед вышестоящими, исходя из дат билдов опубликованного ранее и текущей; тех.писатель собирал выполненные задачи для Release Notes, отсекая временные; выпускающий тестировщик ориентировался с билдами и версиями для проверок апдейтера;
- Labels = "internal". Задача не должна входить ни в какие RN и для этого фильтруется лейблой;
- Status меняется по стандартному workflow: создаётся со значением Open; когда становится известна дата публикации, то меняется на Planned и заполняется поле Due Date (эти же данные используются для пина в Slack); процесс публикации сопровождается статусами In Progress + Testing; и финализируется Done|Close;
- Component = "Core". У каждого продукта обязательно существует модуль Core;
- Description = Summary + некоторые детали или примечания об особенностях публикации (кому спец.билд);
- Assignee = выпускающий тестировщик. Хоть в выпуске и участвует несколько членов команды, но большинство шагов исполняет именно тестировщик. На него же и запишется всё время работы - чаще это один рабочий день, если не случалось откатов билда и завершения работ в иной день;
- TODO = чек-лист шагов публикации, выстроенные в порядке исполнения и с префиксами для задействованных членов команды: PT=ProductTester, WT=WebTester, PD=ProductDeveloper, WD=WebDeveloper, TW=TechWriter, DO=DevOps, PM= ProductManager. Пример и подробности будут чуть ниже, а пока немного примечаний. В Confluence поначалу была оформлена таблица с полным списком, их пояснениями и отметками для типов публикаций (официальная, бета, спец.билд), а позже для ускорения работы были созданы конкретные списки по продуктам. Но в них отпала необходимость, когда была освоена фича Jira по клонированию задач. Сразу после окончания публикации (потом и в сам список этот шаг был записан) уже закрытую задачу клонировали и редактировали следующие поля: Affected Versions = только что опубликованный билд; обнулялись чекеры TODO и поля Issue Links, Fixed Versions, Due Date; в Summary и Description увеличивался номер версии. Время от времени список актуализировался, поскольку некоторые процессы удавалось нивелировать (форматирование текстов RNs, LicAgreement, ReadMe в разных форматах - txt, rtf, doc) или автоматизировать (генерация SampleDocu, очистка компа, проверка подписи файлов), или убедить РМ в избыточности и отказаться от объёмных проверок (нагрузочные тесты очень долго были в первых шагах), заменив на более нужные (результаты проверки сайта фиксировались прикреплением скриншотов) или новые (техпрогресс расширял области применимости продуктов, а значит и увеличивал количество багов). Необходимость детализации и разбиения на мелкие шажки усугублялась после очередных "пинков" следующему публикатору, которому приходилось ещё и ещё раз пояснять смысл и назначение чека. А точный порядок шагов сократил сообщения в чате, где передавалась очерёдность, с трёхстрочных до одной фразы "твой ход". А он уже открывал задачу с чек-листом и видел не проставленные чеки, точно зная, что от него ждут. Единственная проблема - после проставления каждого чека необходимо было выполнять сохранение в базу Jira, а иначе очерёдник либо не увидит ваших чекеров, либо ставя свои затрёт ваши;
- Issue Links = список задач, прилинкованных по типу "blocks the TASK", без закрытия которых нельзя начинать публикацию. В простонародье эта часть звалась "КакогоБагаБилд". Поскольку РМ в Jira Structure планировал и отслеживал только Features+Improvements, то включаемые в билд баги решено было мной линковать к этой задаче. И поскольку возможности Jira ограничивались показом только первых пяти прилинкованных, то во время работы (за несколько дней до публикации тестировались именно эти блокеры чек-листа публикации) неудобство просмотра объёма незавершённых работ исправлялось обычной отлинковкой. Принцип сокращения списка был взят мной из самописной BTS, где у меня была отфильтрована база по запланированным на тестирование задачам и без даты окончания теста. Привычка - вторая натура, поэтому и блокеры выкидывались за ненадобностью. Но со временем команда стала извлекать из такой линковки свою выгоду: РМ стал отчитываться руководству по списку блокеров, техписатель фильтровала исправленные баги для написания RNs, программисты опирались на список блокеров только для оправдания занятости хот-багами вместо текущих разработок, группа веба опиралась только на этот список из-за невозможности включить их задачи в автобилдер. Единственная задача, которую никогда не выкидывали из списка блокеров, была с полным отредактированным текстом RNs, поскольку именно их впиливали в билд в последнюю очередь и пересобирали продукт. Видели бы вы глаза представительницы Atlassian на конференции SQADays-21, когда ей были описаны эти "танцы с бубнами" вместо полноценного использования Jira Structure. Но РМ ни за какие коврижки не соглашался вести бэклоги фикс-билдов с одними только багами в "его" Jira Structure, даже после моего рассказа о том, что бэклоги можно делать составными и отчитываться более точно руководству о затраченных усилиях. Из-за его упрямства команда только ещё больше отстраняла тестировщиков от программистов: спрос за импрувы (велись в Jira Structure) был с программистов, спрос за баги (велись блокерами чек-листа) был с тестировщиков. То есть в команде всегда было два разных бэклога, а не единый. Единственным аргументом было то, что баги никогда не проходили стадии эстимации, поскольку проггеры о багах отзывались: "Баг от импрува отличается тем, что его быстрее исправить, чем понять по тексту сколько это займёт времени", и никогда не планировали их или декомпозировали;
- Fixed Versions = публикуемый билд (четырёхзначная версия) выбирается во время закрывания задачи, а на момент оформления ставилась трёхзначная версия без указания билда. Она использовалась для планирования и иной фильтрации.

Примерный список чекеров (поле TODO)	Пояснения (статья в Confluence)
PT_All planned bugs fixed?	Проверить список багов - блокеров публикации, запланированных на фиксирование, и разработок из Structure
PT_Smoke tested?	После инсталляции проверить основной функционал на триальном и лицензионном ключе.
PT_Internal files in the setup program are correct and they are enough for first start or update, upgrade?	Проверить корректность и достаточность служебных файлов для инсталляции и апдейта
PT_The setup program tested against all supporting OS?	Проверить инсталляцию и открытие приложения на всех ОС из списка System Requirements
PT_Stress test passed?	Шеф не различал нагрузочные и стресс-тесты, а также слышать не хотел, что для тестирования больших данных нужно много времени. На выпуск давался только один день, и он наивно полагал, что мы проверяли обработку монстров на выпускаемом билде. Очевидно, что подобному пункту не место в чеклисте. Но если у вас есть автоматизтрованные регресс-тесты, которые выполняются за минимальное время, то слово stress меняйте на regress и смело оставляйте.
PT_DemoProject or SampleDocus included into installer and updater?	Примеры использования продукта включены в инсталятор, апдейтер. Версия примеров актуальная. Проверку этого пункта вполне можно совместить с иными (smoke, инсталлятор с ключом, апдейтер и апгрейд)
PT_Copyright date correct in the program, readme file?	Имя компании и год лицензирования проверить в файлах и интерфейсе продукта (About, Welcome Window, Preferences, ReadMe, …)
PT_The setup program correctly shows the program name, default installation path, etc.? The setup program shows "beta" in the program name and installs to the beta folder?	Проверить инсталлятор на корректность имени проги, установочного каталога, иконок., префиксы beta и др. Проверить инсталляцию на чистую машину(предварительно почистить реестр и папки ОС), на имеющуюся старую версию.
PT_License agreement file in the setup program is for an official/beta version? It's the latest version.	Проверить текст лицензионного соглашения на отсутствие/наличие Beta примечаний
PT_Release notes shown in the application on first start up?	"What’s New?" показывается при первом запуске нового приложения
PT_Readme file in the setup is for an official/beta version?	Проверить файл ReadMe на отсутствие/наличие Beta примечаний
PT_The trial key file in the setup program is for an official/beta version?	Проверить наличие и длительность триального ключа в файле инсталлятора и апдейтах
PT_Check license limits: trial, after trial, lic numbers.	Проверить триальный ключ на ограничения в период действия и вне его пределов, лицензионный ключ на количество юзеров при совместной работе.
PT_All executible files, including updater and installer e-signed?	Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении имеют электронную подпись
PT_All files checked by several antiviruses?	Все исполняемые файлы в инсталляторе, апдейтере и рабочем приложении не имеют препятствий антивирусами
WD_Close site. Make back-up.	Закрыть сайт для доступа обычным юзерам и сохранить копии заливаемых страниц и прочих файлов. Начало заливки считалось по американскому времени (для Москвы это 16-00). Все предыдущие пункты выполнялись с 10-00 утра (автосборка утреннего билда) до 15-00 или 16-00 часов дня, при сбоях билд пересобирался или сообщалось шефу о стоп-билде.
WD_All pages and child sites are updated? The product teaser on the website shows correct product version?	Каждый продукт имеет свою первоначальную страницу и коротко-названные сайты, которые надо обновлять самостоятельно. Некоторые продуктовые рекламные заставки могут размещаться на общих сайтовых страницах, но должны быть актуальны
WD_The setup file uploaded to the website?	Инсталлятор залит на сайт. Проверить скачивание через страницы Free Download, Upgrade/Update или Buy Online. Веб-разработчик обычно единым шагом заливал инсталляторы и апдейтеры во все места, менял номер версии и оформлял RNs. Так что разбивка сайтовских пунктов больше касалась веб-тестировщика.
WD_The OSD updates uploaded to the website? The OSD updates uploaded to the website to both folders (non-beta and beta if it's official publishing)?	Апдейты загружены на сайт. Проверить OSD Updater на скачивание Core и Kits, апдейт с беты на официальную
WT_Website pages and news ready? All modified webpages copied from the test website to the live website?	Веб-разработчик заливает обновления страниц сайта, а веб-тестировщик проверяет готовность сайта
WT_Copyright date correct in website?	Имя компании и год лицензирования проверить на сайте, прикрепить скриншоты
WT_Release notes availabe on the website?	Зайти на сайт и найти соответствующие выпускаемому билду Release Notes, сделать скриншот и прикрепить его к таске публикации.
WT_License is the same in website (updater from site) and application (installer, updater from file system, About).	Тексты лицензионного соглашения идентичны на сайте, в инсталляторе, апдейтере, продукте.
WT_The setup program available to download, correct and can be installed? Renaming folders enabled?	Скачать с сайта инсталляционный файл и установить на чистую машину, на старую версию в триале и лицензионно, проверить смену имён папок
WT_KeyGen works for current version? New key delivired? KeyDeliveryProcs includes data from the previous version?	Генератор ключа на сайте формирует файл для текущей версии и отправляет линки или сам файл всеми задуманными способами, смена версии продукта или генератора ключа не препятствует процессу обновления
PT_Release notes availabe in OSD Updater?	Запустить OSD Updater и проверить наличие Release Notes текущей и промежуточных версий.
PT_BETA release notes not visible in OSD Updater?	OSD Updater не должен показывать Release Notes для Beta версии, если выпуск официальной. В бета-версии должны быть видны RNs официальной и беты.
PT_OSD Updater updates the previous official/beta version to the new version? The product version on the website displayed correctly?	Проверить возможность апгрейда со старой версии триально и лицензионно, из файловой системы и с сайта. В личном кабинете юзера на сайте и в общедоступных местах скачивания актуализирована версия продукта
WD_Open site.	Обычно заливка и проверка обновлений через сайт занимала около часа времени, поэтому в 17-00 (окончание рабочего дня в Москве и 9 утра в Америке) можно было открывать сайт и рапортовать руководству об успешной публикации
DO_VCS branched, Slack pins updated, Jira builds updated, Installers renamed?	По окончании работы с опубликованным билдом начинается работа со следующим: разветвляется СКВ кода, в чате и на доске версий БТС убираются выполненные задачи и оформляются новые, в файловой системе перименовываются инсталляторы (добавляется постфикс "_р" - public)
TW_Wiki topics updated?	Одно время тех.писатель вела топики в Wiki и актуализировала инфу о доступных версиях, фичах. Но редакторы Wiki запретили эти статьи, т.к. они стали более рекламными, нежели информационными.

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

Пока RNs собирались вручную и хелп-примеры готовил первый член команды, публикация была неожиданностью для всех:

или

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

или

Со временем шефу скучно стало ждать выпуска и моё предложение использовать канал билдов для связи в день публикации было поддержано:

И процесс потёк, как по маслу:

Новичков вливали постепенно:

или

Позже шеф просто умилялся:

Бывало, конечно, что новички, стесняясь общего канала, молча проставляли чеки. Тогда РМ дёргал весь отдел качества фразой: "Что там с выпуском? Почему тишина?" и приходилось его "посылать" в Jira, дабы не отвлекать народ от важных дел.
Но в целом польза от ведения публикации через чек-лист велика. Благодаря наличию чек-листов выпуска для каждого продукта, трёх физических машин и двух виртуальных мне удавалось делать перепубликации четырёх продуктов в один день!

И укладывались в ровно отведённый час. Перевыпуски, конечно, случались, но никак не по причине пропуска какого-то пункта публикации.

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

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

Оценки слушавших в С-потоке.

Полагаю, оргкомитет SQADays быстро вынес урок из конфликта в Европе. Либо и у них наступил кризис - в дорогой Минск не захотели ехать большинство российских докладчиков или все выложились на юбилейной конференции и за полгода-лето ничего нового не выжали из своего опыта. Ещё один момент приходит на память. После столь неудачного моего выступления Рина Ужевко, будучи руководителем оргкомитета SQADays-22, весьма недальновидно отказала мне пообщаться с коллегами на тему "Девочку или Мальчика?". А ведь ещё два года назад можно было предупредить руководителей групп разработки о столь полезном привлечении работников, исходя из гендерных особенностей. Рина побоялась таких разговоров. А вот Андрей Бреслав на TechTrain-2019 поднял вопрос о женщинах-программистках. Актуальненько!

День красоты

9 сентября - Международный день красоты и тестировщика. Да, качество - это всегда красиво!

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

Если тестишь долго-долго, то достигнешь дна тех.долга.

"Быстро поднятое не считается упавшим", - бормотал админ, запуская сервер.

Команда разработки не выдержала очередной кризис и вся отправилась на небеса.
Глядят, а там админы уже распоряжаются: проггеров - налево в ад, тестировщиков - направо в рай.
Подходит очередь РМ-а. Его спрашивают.
- Кем был в команде?
- Процессами и людьми управлял.
- А что полезного сотворил?
- Ничего не производил.
- Юзеров обманывал?
- Не знаю, я их не видел.
- Тогда возвращайся бестелесно и докажи, что ты был членом этой команды.
- А как это? И куда попаду после дел своих?
- Будешь лабать код, никому не нужный, - пойдёшь к проггерам в ад. Будешь правду выяснять и помогать пользователям - отвезём в рай, как тестировщиков.
Развернулся РМ и записался на курсы пользователей.

Было у Отца три сына: старший умный был детина, средний был и так и сяк, младший вовсе был дурак.
Кто стал аналитиком, кто - автоматизатором, а кто и скрам-мастером.
Только Мать отказалась рожать дочь со словами: "Вы её в тестировщицы определите, а мне жаль девочку. Вы ж на ней все пахать станете, и станет она некрасовской бабой.".

Привычка кодить

Прогноз проблем по привычкам программиста

(рубрика - Нюх на баги)

Исходя из многолетнего опыта работы программистом, аналитиком-внедренцем, в тестировании и техподдержке могу заверить вас, что у каждого разработчика есть свой почерк написания кода. И не важно насколько строгие правила кодирования приняты в компании: кто-то играет с порядком параметров, кто-то с наименованиями объектов, кто-то с самописными или стандартными подпрограммами. Одно и тоже действие можно написать, используя стандартные функции (тогда тестировщикам заранее известны слабые места кода), а могут сочинить универсальный или сложно-запутанный код, от которого тестировщикам можно будет ждать всяких непредвиденных ситуаций.
Поэтому, чтоб тестирование не получалось всегда неожиданностью, ниже сопоставлены некоторые человеческие особенности с написанным программистом кодом. А именно, с самым распространённым действием – чаепитие или кофе-брейк. В зависимости от того, как программист готовится или завершает чайно-кофейную церемонию, родились связки с его фирменными ошибками. Когда же сфера IT перешла в удалённый режим, и команды стали распределёнными, естественно пропала возможность наблюдать за общением программиста со "своей кружкой". Но, оказалось, что по скриншоту рабочего стола тоже можно определить тип программиста.
В начале карьеры мои обязанности ограничивались программированием и техподдержкой. В те времена о тестировании вообще никто не говорил и не слышал, потому что сами программисты выполняли аналитику, кодирование, отладку, внедрение и поддержку. Но в силу того, что отпуска в своём большинстве давались полностью (вплоть до 40 рабочих дней), то кому-то приходилось замещать сотрудника в ответственные дни отчётов. В до-САПР-овские времена, когда не было "Галактика" или "Axapta", автоматизация предприятий проводилась собственными силами, а это значит весь код был самописным, без особых корпоративных стандартов. В то время легко было определить почерк кодера: кто-то давал переменным и объектам особенные имена (короткие, нелогичные, без привязки к функционалу), кто-то использовал особые конструкции или ранее-написанные собственные блоки. И если вдруг в отсутствии замещаемого сотрудника падал код, то заместителю поначалу приходилось тратить не мало времени на понимание такого легаси. Вспомните себя студентом, переписывающим пропущенные конспекты лекций от разных однокашников: не с первой страницы начинаешь бегло читать чужой почерк. Также и с легаси-кодом – не с первого блока кода понимаешь логику прописанных команд.
После перехода из универсальных программистов в разряд всемогущих тестировщиков в моём арсенале разнообразия почерков программистов стало больше. При чём сюда добавились и аналитики, и конечные пользователи, присылающие своё видение на проблемы продукта. Высоким словом "разработчик" в некоторых компаниях называют программиста, совмещающего роль с аналитикой. Поэтому, как продумаешь логику, так она и отработает в коде. В моём докладе о лёгкости тестирования кода с помощью утилит аудиторов кода уже говорилось об основных причинах самых заковыристых багов. Они-то и кроются в особенностях почерка кодировщика. А коль скоро характер программиста не перевоспитаешь, то и его фирменные баги вы сможете вылавливать в первую очередь. На счёт скорости обнадёживать вас не буду, но направления для поиска вам будут очевидны.
Итак, типы почерков программистов делю на 6 групп.
Чистюля (аккуратист, педант)
На его рабочем столе никогда не бывает ничего лишнего, весь минимальный набор (клавиатура, мышь, за редкостью чистый лист и карандаш) расставлен "под линеечку", ни пылинки-соринки, ничего мешающего рабочему процессу. Если говорить об иконках на рабочем столе операционной системы компа, то там могут быть лишь стандартные приложения, либо всё необходимое разнесено по папкам. Свою кружку моет сразу после чаепития и убирает на строго отведённое место в закрытом шкафу.
Исходя из описанного поведения, программист-чистюля привык писать код так, чтобы объём и логика кода строго соответствовали описанному заданию, все переменные после использования были очищены. Вроде бы всё должно быть прекрасно, но программист-педант опасен тем, что программа часто недостаточно обрабатывает исключения, не прописанные в ТЗ, либо умышленно опущенные из-за их стандартности, он же привык, что всё разложено по полочкам и ничего лишнего не мешает его взгляду. Перед использованием переменных программист-аккуратист забывает проверить их на корректность объявления и присвоения значений, он же привык, что его кружка всегда чистая. Поэтому код от программиста-чистюли надо проверять исследовательским методом на неописанные в ТЗ ситуации, нагрузочные и интеграционные тесты делать на передаваемые и входящие переменные. В качестве профилактики можно применять правило Code Review, результатом проверки которого является список параметров процедуры, использованных не по назначению.  
Хозяйчик запасливый
Его рабочий стол напоминает склад тысячи мелочей, ящики тумбочки еле закрываются от всего "очень нужного", вполне вероятно он оккупировал и рядом стоящий шкаф под свои полезняшки. Иконок на рабочем столе компьютера видимо-невидимо, разбросаны по всей площади и на первый взгляд в хаотичном порядке. Скорее всего кружку для кофе или чая он держит на своём же рабочем столе, чтоб она всегда была "под контролем", моет её тщательно перед чаепитием. В силу привычек, программист-хозяйчик пишет код "с запасом", программирует неописанное в ТЗ, но на его взгляд возможное при исполнении программы. Код запасливого программиста надо проверять на избыточность объявленных переменных, на достаточность алгоритмов без половинчатого кодирования единичных исключений. Код хозяйственного программиста может быть похож на "лапшу", поэтому в качестве профилактики надо применять оптимизацию блок-схем и сокращать запланированное ему время на написание кода.
Всезнайка
Ученость всезнайки видно по обилию литературы на столе, рабочий стол компьютера – это научный отдел всемирной библиотеки или линки на всевозможные новостные каналы. У него отдельные кружки и стаканы, бокалы для чая, кофе и прочих жидкостей. Их много, и все они разные. Исходя из жизненных пристрастий, код всезнайки заумен, изобилует сторонними библиотеками, возможна перестраховка в виде шифрования. Проверку стоит начинать с поиска "мёртвого" кода. Множество унифицированных вспомогательных функций можно единожды привести в соответствие, но их использование заумным программистом усугубляет интеграционные баги. Обязательной профилактикой для всезнайки служит публичный процесс Code Review, нагрузка по передаче знаний и умений сотрудникам всех отраслей, что позволяет ему понять причины собственных ошибок. Не ограничивайте свои тесты программы от Всезнайки только теорией от гуру, поскольку его сочинение может оказаться слишком навороченным. Пример о граничных значениях: обе функции определяют принадлежность значения к определённому числовому промежутку, но описанный способ матрицы можно применить только к функции "if_cycl" при тестировании "чёрным ящиком".

Рубаха-парень (общительный)
Любитель поболтать вместо кодирования опознаётся по количеству средств связи на рабочем столе. Это могут быть как различные виды телефонов, смартфонов, раций, так и иконки чатов, конференций, аудио-видео коммуникационных каналов. "Свой парень" предпочитает чайно-кофейные кружки из общей кухни, за которыми не надо следить и мыть. У общительного программиста вместо кода на первом месте коммуникации, поэтому программа может быть просто недописана, либо блоки после копи-паста недоправлены. В первую очередь продукт от ультра-разговорчивого программиста надо проверять на точное соответствие ТЗ в области полноты и законченности, каждый из новых пунктов проверять на корректность, не допуская частичной выборки классов эквивалентности. В качестве профилактики по недопущению им багов предлагается не отвлекать его от работы, а общение на нерабочие темы выносить только в перерывы.
Фантазёр жизнелюбивый, живчик
Радость жизни в код не впишешь, и по хаосу на рабочем столе его легко выявить. Среди иконок не мало игр. Кроме компьютера на столе бытовое множество вещей, будто дом или объект его увлечения переехал на работу. Разнообразные чайно-кофейные кружки, в том числе и чужие, можно найти не только на столе, но и в тумбочке, или на чужом столе. Он не замечает даже, когда меняет бокалы, стаканы на общественные или соседские. Это признаки (законы) общежития, и они отражаются в его коде в виде опечаток, обилия неоптимизированного кода, неочищенных переменных и параметров без присвоенных значений. Из-за лёгкого отношения программиста к жизни тестировщику нужно тщательно проводить регрессионные и нагрузочные тесты. Профилактикой может быть работа в паре с Чистюлей или Всезнайкой до момента, когда за него будут выполнять более 30-40% задач.
Пофигист (разгильдяй, тупокодер)
Бардак и грязь на столе, немытые кружки, минимум иконок – признаки тупокодера. Его код не низок, не высок, не узок, не широк, то есть на первый взгляд в точности соответствует ТЗ. Но опасайтесь недописанных блоков, недопроверенных опечаток, неучтённых исключений, незакрытых уязвимостей. Все виды и методы тестирования актуальны для кода от пофигиста. Растормошить его можно доверить любому увлечённому общим делом сотруднику.

Рекомендации по определению типов: смотрите когда и как тщательно программист моет кружку (до или после чае-кофе-пития), сколько их у него и в каком они состоянии, что ещё имеется на рабочем столе, изучите расположение иконок в его операционной системе. Проанализируйте баги и их причины, составьте таблицу в разрезе программистов. Обычное наблюдение даст вам понятие о почерке программиста: сопоставьте типы кодеров и их фирменные баги. Впоследствии можете начинать тестирование с фирменных багов, это ускорит Вашу работу и повысит качество продукта, потому что будете находить проблемы, казалось-бы не очевидные, но вполне вероятные на стороне конечного пользователя.
И ещё несколько подсказок.
Типы могут пересекаться в одном программисте, поэтому подглядывать за поведением кодера стоит регулярно, особенно перед передачей задачи на тестирование.
Не буду скрывать, к некоторым перечисленным типам относится и мой стиль кодирования.
Наиболее действенна профилактика багов, когда в неё вовлечены все сотрудники. Для этого можно на стендапах или ретроспективах выделять время для напоминалок, а сами правила формулировать в стишках, песенках, поговорках или анекдотах. Например, для забывающих очищать переменные упомяните лозунг "Уходя гасите свет" с расшифровкой о нагоревших киловаттах для пустоты. Также действенны публичные Code Review с привлечением тестировщиков в качестве слушателей. Такие собрания полноценно заменяют митинги о передаче знаний.
Надеюсь, у каждого из вас уже есть свой список типов программистов и их фирменных багов. Это хорошее подспорье для увеличения скорости проверки продуктов.

Нюх на баги - развитие тестировщика

Повышение профессионализма тестировщика традиционными методами

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

1. знание теории тестирования
Знаниями теории тестирования обладает выпускник общего курса о тестировании. Но теорию можно изучать и самостоятельно, без особых лекций. Литературы по теории тестирования на сегодняшний день не мало, новые знания аккумулируются и распространяются на конференциях, в блогах, форумах и чатах/соц.сетях. Но теория без практики – ничто, поэтому теоретик в тестировании может рассчитывать только на уровень "юниор". Уровень знаний в теории тестирования имеет градацию: общие понятия (ручное-автоматизированное, стадии тестирования, планирование-результаты) для desktop-web-mobile-hard/iot, соответствие качества по стандартам iso-9126 functionality-usability-load-law-maintainability-reliability-efficiency-portability. Владение теорией тестирования помогает быстрому вхождению новичка в любую команду разработки программного обеспечения. Теоретику тестирования проще формировать планы работ и выявлять узкие места продукта и процесса разработки.

2. владение методами проведения тестирования
Тестировщик-практик без знаний теории тестирования образуется из числа программистов и пользователей. Владение некоторыми, но полноценно, методами тестирования позволяет выявлять сложные места продукта без излишних затрат времени тестировщика, иных сотрудников, вспомогательных дорогостоящих средств. Узконаправленный специалист глубоко копает, поэтому можно быть спокойным за качество кода, если это бывший программист, и за качество функционала, если тестировщик выявился в среде пользователей. Однозначно, не существует тестировщика, равнозначно владеющего всеми методами проведения тестирования, поэтому не стоит надеяться на высоту профессионализма у отличника-теоретика всех методов. Практик одного или нескольких смежных методов тестирования (ручное-автоматизированное, code-functional, smoke-integrated, load-stress, usability-law) всегда имеется в списке кандидатов. Полезным может быть только узкий специалист, но владеющий несколькими методами. Развивать и увеличивать количество методов можно на курсах, самостоятельно, в рамках практики и текущей работы. Передача навыков более эффективна внутри команды путём проведения мастер-классов. В овладении методами и вспомогательными средствами тестирования нет ничего лучше специализированных курсов, вебинаров и сообществ. При подборе специалиста с глубоким знанием определённого метода тестирования руководителю необходимо чётко знать цель тестирования, какая область продукта вызывает максимум подозрений о провальности.

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

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

5. знание языка кодирования
День тестировщика отмечается 9 сентября, когда была обнаружена букашка в процессе отладки программы. Тестировщики первого уровня тестирования – дебаггеры – выявляют проблемы на уровне кода. Прямые кандидаты в тестировщики кода – это программисты, но, благодаря наличию утилит аудита кода в среде разработки, в число дебаггеров могут входить обычные выпускники средней школы. Качество кода – исчислимая величина, правила кодирования стабильны, соответствие кода техническому заданию проверять просто и высоко-полезно. Синтаксис языка кодирования эффективно изучать на специализированных курсах, но затраты в таком случае могут превосходить скорость вхождения в проект, поэтому тестировщику можно использовать комментарии программистов в коде, обсуждения code review и другие совещания вместо учебников. Чисто-написанный изначально код обнуляет затраты на исправление багов.

6. вспомогательные продукты для проведения тестирования
Наличие утилит, облегчающих и ускоряющих работу – путь к успеху. Автоматизация, нагрузочное и стресс-тестирование реализуемы на сторонних приложениях. Логирование положительных и отрицательных действий – большая помощь тестировщику в локализации проблемы. Закупка компанией сторонних приложений окупается только при наличии готовых специалистов по их использованию. Помогалок больших и малых, сложных и простых, бесплатных и дорогих имеется в достаточном количестве на рынке и курсах тестировщиков. На чём остановить своё внимание зависит от направленности тестируемого продукта, одного уникального помощника всем тестировщикам пока не создали.

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

Дорогие trivial-ы

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

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

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

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

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

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

Документор кода или псевдокод

Осенью 2016 года сотрудникам, рекламирующим и распространяющим продукт ClearSQL, мной было предложено позиционировать его не только для разработчиков, но и для тестировщиков. Но пользу утилит аудиторов кода они оценили только недавно, начав серию статей с Псевдокода (https://www.youtube.com/watch?v=pFCAALkJ9RU).
Именно Псевдокод является самым простым и доступным способом оценки полноты и качества кода. Фактически, это комментарии к коду, понятные любому человеку.
Комментарии псевдокода добавляются в основной код со специальными тегами. За счёт этих тегов можно вычленять только комментарии (обычный текст, который можно брать из текста технического задания от аналитика продукта) или композицию комментариев со строками кода. В ClearSQL есть возможность генерить Flowchart (блок-схему, UML диаграмму) по комментариям псевдокода. Нижеследующие скриншоты сняты из редакторов кода, псевдокода и диаграмм приложения ClearSQL 6.9.
Текст кода с комментариями псевдокода:

Диаграмма flowchart кода:

Текст псевдокода:

Диаграмма flowchart по комментариям псевдокода (UML формат, слева-направо, со строками кода):

Если аналитики балуют программистов составлением тех.задания в виде блок-схем, то сравнение UML диаграммы от аналитика с Flowchart по комментариям псевдокода даст моментально объём тех.задания, не покрытого кодом или не продуманного аналитиком. В нижеследующем примере видно, что программист обработал не только граничные значения (есть/нет звонок), но и промежуточный результат (абонент занят).
Блок-схема аналитика (нарисовано вручную в Paint):

Диаграмма flowchart по комментариям псевдокода со строками кода:


Программистам, ленящимся писать комменты к коду, нет смысла тратить время и способности сочинителя обычных текстов, потому что можно сначала вставить в пустой скрипт текст от аналитика

закомментировать эти строки (можно с тэгами псевдокода)

разбить их на логические куски

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

Наличие комментариев в коде имеет ряд преимуществ:
* из-за текучки кадров следующему программисту будет быстрее и проще разобраться с чужим кодом (легаси);
* maintainability index (уровень качества кода) любого кода достигается больше минимума в 85 за счёт 3/10 комментированных строк (но только если это не временно неиспользуемый код, а именно пояснения к коду = полезные комментарии);
* по комментариям к коду не только легче разобраться с его предназначением, но и можно улучшить свои знания языка программирования;
* наличие комментариев в коде ускоряют восстановление истории задачи и добавляют уверенности при смене или потере VCS и BTS, так как нет смысла искать изменения по системе контроля версий или по баг-трекинговой системе;
* сертификация программного обеспечения подразумевает наличие документации, которую легко и быстро можно вычленить из комментариев псевдокода, а не писать с нуля, как это было в моей практике.

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

Идеал QA

Тестировщику-универсалу по-силам и 12 программистов на одного, но более привычно проверять работу 5-7 программистов.
А про штат в топовых компаниях читайте "Как тестируют лидеры отрасли: идеального QA не существует".

Помоги мне, тесты гибнут

1. Невероятно, но где-то существует команда, в которой программисты хотят тестировать.
А зачем в ней вообще тестировщики?
Читайте "Как сделать так, чтобы тестировщики позволили себе помочь".

2. Утопичная идея научить истинных программистов мыслить также широко, как тестировщик - и со стороны пользователя, и со стороны заказчика, и со стороны того же самого кодировщика. Все три роли имеют разные генеральные линии, которые чаще всего как лебедь, рак и щука тянутся к противоположному
Читайте "Тестирование и контроль качества — ответственность каждого"