QA, QC или иначе

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

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

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

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

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

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

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

Загадки QA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

День красоты

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

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

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

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

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

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

Гендерность на страже качества

Девочку или Мальчика? 

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

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

ЗАДАЧА	КОМУ	ПОЧЕМУ
локализация бага, отсеивание незначимых причин	М	Женщины думают «не тем местом», что мужчины — в основном, лобными долями мозга. А они отвечают не столько за логику, сколько за интуицию и эмоции. Мужчины же, решая любую задачу, включают всю свою «мозговую» аналитику, да еще активно подсоединяют зоны, обрабатывающие зрительную информацию. У сильного пола в шесть раз больше серого вещества. Зато у слабого – в десять раз больше белого. Но именно серые нервные клетки отвечают за интеллект. А белые клетки – это отростки нейронов, которые лишь распределяют задачи между разными отделами мозга. У женщин крупнее гиппокамп – важнейший, «записывающий на корочку», элемент мозга. У Ж намного лучше память. У М лучше развито правое полушарие. При осмыслении слов мужчины пользуются преимущественно левым полушарием, а женщины — обоими.
проведение теста с одновременным привлечением зрения, слуха, речи и моторики, либо проведение параллельно двух-трёх тестов	Д
составление шагов теста	М
проверка шагов теста на полноценность охвата	Д
сбор статистики	М
анализ статистики	Д
однообразные тесты ежедневно	Д	Мужское сердце бьётся в среднем 70 раз в минуту, женское — 80 раз в минуту. Для Ж. время летит быстрее. Женщины в большей степени переоценивают длительность временных интервалов. М. выносливее при большой нагрузке. Ж. выносливее при малой нагрузке. Мужчин очень утомляет монотонная работа. Они от нее «звереют». Женщин монотонная работа успокаивает. Она для многих из них часто является отдыхом.
частая смена направленности тестов	М
ускорение и повышение нагрузки в короткое время	М
актуализация и повторная проверка багов	Д
тесты с чётким соблюдением времени	М
срочные смоук-тесты	Д
многообразие новых сложных тестов	М
в качестве перерыва -  выполнение мелких однообразных тестов	Д
многозадачность в исследовательском, комплексном, предвыпускном, интеграционном, параллельном и тому подобных тестах, либо совмещение должностей (QA+support+manager)	Д	У женщин мозолистое тело, которое служит своеобразным «кабелем» между правым и левым полушариями мозга, толще и соединений в нем на 30 % больше. Этому способствует женский гормон эстроген. Большое количество соединений объясняет способность женщины вести несколько не связанных друг с другом дел
составление и проведение опроса, сбор статистики для usability	Д	У мужчин сильнее развито левое полушарие, отвечающее за логическое мышление, у женщин — правое, отвечающее за эмоции и творчество. Женщины очень остро воспринимают настроение собеседника и могут перехватить его переживания. У женщин эмоции связаны с обширной областью обоих полушарий, и их функционирование может происходить одновременно с действием других функций. У мужчин область эмоций располагается только в правом полушарии, что означает возможность ее функционирования в отрыве от других функций мозга. Например, мужчина в споре может оперировать логикой и словами, задействовав левое полушарие, и не испытывать эмоций по существу вопроса.
актуализация, review задач через постановку уточняющих вопросов	М
однозначные положительные тесты	М
тесты, связанные с социализацией, эмоциональной восприимчивостью продукта, вариативностью пользователя	Д
функциональные тесты на полноценность управляющих устройств (клавиатура, джойстик и т.д.)	Д	Ж. более симметричны. Точность левой руки у женщин во всех возрастных периодах выше, чем у мужчин. То есть левая не так сильно отстает от правой. У мужчин асимметрия более выражена. Среди мужчин в 2 раза больше левшей и гораздо больше заик.
раскладка управляющих устройств для левши (мышь, меню и т.д.)	М
нагрузочные и стресс-тесты, растянутые на несколько дней	М	Во время сна электрическая активность мозга мужчин падает примерно на 70%, у женщин лишь на 10%. Восстановление мозга сном эффективнее у мужчин.
тесты гаджетов для детей и лиллипутов	Д	Среднестатистический мужчина на 10% выше среднестатистической женщины
нагрузочное тестирование голосовых записей	М	У мужчин тип дыхания брюшной, в отличии от грудного у женщин. На брюшном дыхании больше раскрывается диафрагма, а значит дольше длится фраза без забора воздуха.
тесты гаджетов, не проверенных на токсичность	Д	У Ж. сильнее иммунная система. У женщин гораздо реже заболевания приобретают хроническую форму. Некоторые исследования показывают, что Ж. более чувствительны к боли. Мужчины более стрессоустойчивые. Женщины более подвержены различным фобиям и депрессиям.
функциональное и дымовое тестирование симуляторов боли (физической, психологической)	Д
нагрузочное тестирование симуляторов боли(физической, психологической)	М
представитель тестировщиков на обсуждении разработок	М	У мужчин в левом полушарии есть центр, отвечающий за речь. У женщин за речь отвечают два центра: побольше – в левом полушарии, поменьше – в правом. Речь мужчин отличается обилием терминов и богатым запасом слов, в то время как женщины в речи опираются на интонации и эмоции. Ж. говорит с собеседником, М. чаще – с самим собой. Всем известно, что дамы могут часами разговаривать с собеседником, причем, обсуждают они одну тему. А вот мужчины могут вести разговор сразу на несколько тем и легко «перескакивать» с одной на другую, объединять совсем разные вопросы. Речевая грамматика у девочек лучше. По крайней мере до 11 лет. Женщине сложно удержать знания в тайне, т.е. легче ими делиться со всеми.
проверка грамотности в оформлении задач, документации, продукта	Д
предоставлять отчёты и доклады, обучать теории	Д
составление и написание документации, ясных и чётких описаний задач	М
проведение тестов с параллельным устным комментированием шагов и результатов	Д
прохождение теста по чек-листу, диаграмме переходов состояний, контрольным точкам	Д	М. видят дорогу, а Ж. указатель. Женщины лучше считывают эмоции, которые выражает лицо, но запоминать и узнавать лица у них получается хуже, чем у мужчин.
составление плана теста	М
прохождение теста по flowchart	М
подбор тестовых данных для фоторобота	М
подбор тестовых данных для видео-игр	Д
цветовое различие и сочетание	Д	На сетчатке человеческого глаза размещаются почти семь миллионов рецепторов-«колбочек», которые отвечают за восприятие цвета. За их действие отвечает Х-хромосома. У женщин их две, и палитра цветов, которую они воспринимают, шире.  Дальтонизм – в основном мужская особенность. В той или иной мере им страдают порядка 8% мужчин и всего лишь 1% женщин. У женщин развито периферийное зрение. У некоторых из них оно достигает 180 градусов. У мужчин зрение сфокусированное (туннельное), а у женщин – рассеянное. Поэтому мужчины лучше видят на большие расстояния, но их зрению не хватает широты охвата.
определение и сопоставление расстояний	М
окуляры для 3D с охватом 360 градусов	Д
составление плана проверки лабиринта, карты, навигатора	М
стратегическое тестирование	М
комплексное тестирование	Д
прослушивание входящих звонков	Д	Женщины лучше различают высокочастотные звуки. Женщины лучше мужчин распознают изменения тона и поэтому прекрасно замечают смену эмоций у собеседника. Мужчины «слышат» направление звука. Голос у мужчины ниже и грубее, чем у женщин (за это отвечает тестостерон). У женщины большая часть впечатлений связана с восприятием речи.
тесты гаджетов объёмного звука	М
запись высокочастотных звуков	Д
запись низких тонов звука	М
составление тестовых данных для аудио-проигрывателей	Д
клавиатура для слепых	Д	Кожа женщины в 10 раз чувствительнее, чем кожа мужчины. А если мужчина занят делом, то чувствительность кожи падает еще больше, и он почти не чувствует боли. Вкус у мужчин менее чувствительный, но в оттенках горького и соленого они разбираются лучше, в то время как женщины лучше улавливают тонкости сладких блюд. Температура мужского тела в среднем на 0,2 градуса выше, чем у женщин. Болевой уровень выше у мужчин, но тактильный у женщин.
автомат соки-воды для взрослых	М
автомат соки-воды для детей	Д
нагрузочные тесты спортивных тренажёров	М
usability игровых автоматов, гаджетов IoT и ЗОЖ	Д
тестирование IoT гаджетов, 5D кино и игр на соответствие запахов, звуков	Д	Ж. более остро чувствует даже самые «утонченные» ароматы, т.к. в носу у женщины расположено гораздо больше рецепторов. В ощущении запаха мужчины уступают женщинам. Слуховые и обонятельные анализаторы у мужчин развиты слабее.

Ещё немного подсказок:
- если какой-то навык у девочки-тестировщицы неполноценно развит, то похвалите её прилюдно за уже достигнутое, либо пригрозите аналогичным наказанием. Это станет стимулом её самостоятельной работы;
- поскольку для достижения цели мальчику нужно её чётко видеть, то для улучшения и расширения навыков мальчика-тестировщика достаточно ему пообещать некое вознаграждение (повышение по службе или оклада);
- тесты с обязательным пошаговым исполнением эффективнее выдавать мальчику, т.к. девочка большой объём работ перекомпанует по собственному усмотрению для снижения затрат, объединит аналогичные на её взгляд подзадачи;
- отчёт о проделанной работе с результатами анализа собирать у девочки после каждого шага, у мальчика по окончании всей задачи;
- регрессионные тесты на старые задачи поручайте девочкам, т.к. у них более длинная память и они могут выявить больше отклонений;
- для более продуктивного результата от мальчика чаще меняйте ему направленность задач, но не объединяйте однозначные тесты, ставьте чёткие цели;
- если на отдел тестирования пришла большая куча разнообразных задач, то их группировку эффективнее доверить девочке, которая привычна к наведению порядка;
- из-за высокой планки чувства ответственности девочек надо ограничивать в глубине и времени тестов, чтоб они не доводили проверки до абсурда. По этой же причине не стоит всю ответственность за качество сваливать на плечи тестировщиц, это может их глубоко ранить и они замкнуться или уйдут;
- "Женщины! Они изумительны! Они фантазируют - и чудом оказываются правыми. Конечно, это не совсем так. Женщины подсознательно замечают тысячи мелких деталей, бессознательно сопоставляют их - и называют это интуицией.", - А. Кристи "Убийство Роджера Экройда", глава 13 "Ствол гусиного пера";
- помните визуализацию полов: М – треугольник с вершиной внизу (со всей силой к цели = от основания к вершине), Ж – треугольник с основанием внизу (расширение воспринятого = от вершины к основанию).

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

График показывает, что с увеличением мужских качеств уменьшаются женские и наоборот.

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

Лето, баги, огород

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

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

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

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

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

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

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 сек

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

ГКЧП - Где, Как, Что Править?

Команда разрабатывает несколько десктопных продуктов с некоторыми едиными модулями, какие-то продукты являются как самостоятельными, так и частью других, собственный сайт для поддержки продуктов как самостоятельный продукт тоже имеет тесные связки с десктопными.
Самописная система ведения задач была удобна, но недостаточна для распределённой команды. Поэтому был выполнен переход на Jira. Каждому продукту было присвоено своё имя в BTS (Bug Tracking System), а несколько глобальных модулей (код исправляется в одном скрипте, а при компиляции каждого продукта исправления автоматически попадают в билды) были перенесены из старой BTS в новую в продукт Global Modules, также задачи по сайту были импортированы в отдельный продукт Jira.
В старой BTS возможно было использовать единый список версий продуктов, а для закрытия багов приписали небольшой интерфейс. В Jira, к сожалению, нет возможности использовать сквозной список версий продуктов, поэтому в продукте Global Modules приходится создавать дубликаты номеров билдов по каждому скомпилированному продукту (но этот утомительный ручной труд был автоматизирован спустя 3 года мучений).
Пока команда состояла из 7 программистов и одного тестировщика, то проблем с описанием и пониманием задач не случалось. Когда же команда разработчиков сменилась на 70% и вдвое увеличилась, то появилась необходимость расшифровывать устоявшиеся понятия и правила. А чтобы не тратить на каждую задачу драгоценное время старожил, создавались документы с описанием корпоративных правил. Для более быстрого и эффективного запоминания всех сложностей, придуманных PM, мной была предложена мнемоника.

ГКЧП
или Как Правильно Читать баГ/импрув?
Где, Как, Что Править?

ГДЕ
* Определяем продукты, в которых надо фиксить. Это видно из номера:
     Prod_1-[issuenumber] - только в Product_1;
     Prod_2-[issuenumber] - в Product_2 и может быть в Product_3;
     Prod_3-[issuenumber] - в Product_3 и скорее всего в Product_2;
     GM-[issuenumber] - в Product_1, Product_2, Product_3 и может быть на сайте;
     WEB-[issuenumber] - на сайте и может в Product_1, Product_2, Product_3
* Определяем модуль или функционал, как часть продукта. Это видно из поля Component.
* Определяем список версий, в которых нужно внести исправления. Для этого на сайте смотрим номер текущей версии (Support -> Release History -> [ProductName]) и сравниваем его с номером билда, в котором выявлен баг/импрув. Это видно по значению поля Affect Versions. Если баг/импрув из числа GM, то номер Affects Versions префиксован кратким наименованием продукта. Если номер версии совпадает с точностью до релиза, то правку вносим только в текущие поддерживаемую и разрабатываемую. Если версия отлична по Мажору/Минору, то сверяемся в поле Label по наличию значений FIX_IN_PREV_VER и/или FIX_IN_OFFICIAL_VER.
* О том, нужен ли фикс в предыдущей версии или в будущей-разрабатываемой версии говорит поле Label со значениями FIX_IN_PREV_VER и/или FIX_IN_OFFICIAL_VER.

ЧТО
* Определяем объём работ по совокупности значений полей Summary, Description, Attachments. Обычно структура Description нижеследующая:
     [Шаг / Модуль]
     [Пункт / Страница]
     [Что не так?]
     [При каких условиях?]
     Как должно быть?]
         example:
         [Шаги примера]
* Пояснительный скриншот или лог бага, или длинный пример хранится в поле Attachments (атач).
* У кого уточнить детали бага/импрува видно из полей BUG_HUNTER или Reporter.

ПРАВИТЬ/ПРОВЕРЯТЬ
* Если фикс был возвращен на доработку, то в поле Comments имеется причина.
* Проверять фикс надо как с default настройками, так и с описанными в Description или Environment.

ХАОС (порядок автотестов)

ХАОС – хорошие автоматизированные общие скрипты

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

ЧТО

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

ГДЕ

Очевидно, что скрипты авто-тестов необходимо хранить в той же Системе Контроля Версий (СКВ), что и исходники выпускаемого продукта. Опыт показывает, что наиболее удобно выделять место под авто-тесты в рамках конкретного продукта или модуля. В дереве СКВ одноимённые подпапки "Авто-тесты" упрощают поиск при их запуске в CI (Continuous Integration) среде. Наличие скриптов в СКВ способствует более корректному их редактированию в зависимости от версии выпускаемого продукта.

КАК

Хотя скрипты авто-тестов и будут хранится в непересекающихся местах, но к их именованию также необходимо применить общие правила: уникальность в рамках проекта и модуля (префиксы по имени продукта, модуля), аббревиатура авто-теста (или использовать расширение имени файла, если их запуск отличен от основного приложения), для CI не эффективен постфикс версии, но краткое назначение скрипта должно быть в имени файла (примечание: нумерация порядка исполнения или версий продукта в имени файла малоэффективна, потому что привносит излишнюю уникальность в быстроменяющемся проекте). Содержимое скриптов должно удовлетворять всем принятым правилам кодирования в конкретной команде: именование переменных, использование глобальных параметров, наличие и объём комментариев, форматирование, использование достаточных команд без избытка кода по прямому назначению. Правила кодирования должны быть однозначно прописаны во внутренней документации, их пополнение и корректировка производится после очередного совместного обсуждения кода (public code review).


Команда, соблюдающая правила, непременно побеждает.

"В чём сила, Брат? В правде!" (С*)

Копим куки

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

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

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

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

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

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


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

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






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

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


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

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

Осенью 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

Тестировщик выявляет баги, QA добивается исправления багов и нацелен на их предотвращение.