Краткие аннотации к книгам по тестированию

Старый текст, написанный для рабочего интранета.

Gerald M. Weinberg. Perfect Software: And Other Illusions about Testing. Если кого и можно назвать «дедушкой тестирования», так это Джери Вайнберга. За свою карьеру он написал просто безумное количество книжек, в основном про процессы и подходы, в разработке софта. При всем этом, почему-то, ни одна из его книг не выходила на русском языке.
«Иллюзии» чем-то похожи на «Психбольницу в руках пациентов» Купера — такой же научно-популярный подход к освещению тестирования. Книга полезна как тестировщикам, желающим сделать свою работу не такой унылой, так и менеджерам, желающим лучше понимать, что у нас там в тестировании такое творится. Читать далее «Краткие аннотации к книгам по тестированию»

Выживай, интроверт

Не всеми вещами в жизни мы можем управлять с уверенностью, примерно так в мою социальную ленту и вынесло статью «как выжить интроверту в ИТ». статья настолько, гм, наивная, что пройти мимо и не оттоптаться на ней было совершенно невозможно. Читать далее «Выживай, интроверт»

Мой опыт использования часов на Android Wear

Долго читать: если вам внезапно захотелось приобрести смарт-часы, совершенно не факт, что это должны быть часы на андроиде, и не факт, что они должны быть смарт.

Ходит легенда, что в одной хорошей компании существовала такая черная команда тестировщиков: они одевались в черное, ходили по проектам, подкалывали программистов и могли за небольшое время напрочь затестировать любое приложение. Все их боялись.
Я уверен, в Google существует такая черная команда разработчиков. Они одеваются в футболки с логотипом, и они приходят на те проекты, которые залежались, и которые надо окончательно угробить. Убили Buzz — перешли на Wave. Убили Wave — перешли на Glass. Ну и что там еще у Google было. В какой-то момент эта команда, определенно, занялась Android Wear. Читать далее «Мой опыт использования часов на Android Wear»

Практическое QA для тестировщиков

Историю со сравнением QA (quality assurance), QC (quality control) и месте в них тестирования к настоящему времени уже достаточно подробно обсудили, и вроде бы всем уже все понятно. Если нужно освежить контекст, то вот у «Лаборатории качества» об этом неплохо написано, почитайте.

В общем, (и как обычно без доказательств и скучных ссылок на стандарты) обеспечение качества представляет из себя набор мероприятий и практик, направленных, разумеется, на повышение качества (продукта). Условно можно разбить все QA-активности на две части: процессную, куда входит настройка процессов разработки, определение критериев, найм, обучение и безжалостное увольнение сотрудников и тому подобное; и практическую. Практическая часть заключается в адаптации и подборе подходящих существующих инструментов и подходов, помогающих влиять на качество. Для серьезного влияния на процессы и организацию нужны определенные полномочия, которых, как правило, у тестировщиков нет; так что оставим это специально обученным QA-менеджерам, и пусть они рисуют свои формочки и воркфлоу в JIRA, а вот некоторые практики вполне реально попробовать внедрить самим на уровне команды. Читать далее «Практическое QA для тестировщиков»

Что же не так с регрессионными тестами

Вот сидит разработчик, методично покрывает свой код модульными тестами. Ему интересно, как новый метод будет себя вести в разных условиях.
Вот сидит тестировщик, методично выполняет тесты, иногда автоматизированные, иногда нет. Ему интересно найти баги в коде разработчика.
А вот сидит «автоматизатор» и пишет регрессию. Ему интересно, чтобы на уже протестированном коде регрессионные тесты проходили. Поэтому он старается сделать так, чтобы в любой даже не очень понятной ситуации, actual как может сильнее было равно expected.

Столкновение концепций

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

Типичный диалог Windows

Еще одно распространенное явление — это то, что разработчики софта чаще всего сидят на Windows или Linux (последнее, впрочем, редкость), но дизайнер почти гарантированно будет на маке. Просто так принято в профессии, пока у тебя нет макбука — ты и не дизайнер даже, собственно. Зато с макбуком все гораздо лучше.

Типичный диалог MacOS

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

Типичный результат работы дизайнера на макоси в приложении для Windows.

Можно только догадываться, как в этом плане обстоят дела с разработкой мобильных приложений для экосистем iPhone и Andriod.

И снова здравствуйте

Это, наверное, третья где-то попытка восстановить блог, и десятая — вести его на регулярной основе.

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

Такие дела.

Как занимаются тестированием в Google

Гойко Аджич в своем блоге пересказывает выступление директора по тестированию Google, Джеймса Уиттакера, на конференции Agile Cambridge, ну, а я перевожу его пересказ.

Джеймс Уиттакер, директор по тестированию в Google, рассказывал вчера на конференции Agile Cambridge о том, как в Google занимаются «Инжинирингом тестирования». Он сравнил тестирование программного обеспечения с медициной – в частности, с уходом за пациентами в больницах.

Уиттакер начал с того, что 20 лет назад разработка программного обеспечения была похожа на массовое производство, и стоимость исправления проблемы после выпуска был гораздо выше, чем до него. «Мы уже не делаем программное обеспечение таким способом», сказал Уиттакер, добавив: «вы можете использовать приложение Google Docs, в это же время оно будет обновляться, и вы даже не заметите этого». Уиттакер делает вывод, что время, требующееся, чтобы исправить ошибку до и после выпуска, для их программного обеспечения в настоящее время абсолютно одинаково (обратите внимание — время, но не цена).

Вместо раннего исправления ошибок и встраивания качества с самого начала, Уиттакер предлагает подойти к программному обеспечению, как к пациенту в больнице. «Тестирование, как и лечение — постоянный процесс», сказал он, добавив, что для оказания эффективной помощи врачам необходимо быстро оценивать состояние больного. Для этого они используют карту пациента, которая дает им историю болезни и лечения, и мониторы, которые позволяют наблюдать за жизненно важными показателями, такими как частота пульса.

«У меня нет карты, чтобы показать мне проблемы, и монитора жизнедеятельности», говорит Уиттакер. Для него, как у директора по тестированию, эта информация была доступна, но хранилась в нескольких база данных, запросы к которым нужно было строить вручную, поэтому он поставил своей команде задачу уменьшить количество SQL запросов.

В результате, команды разработчиков Google создали несколько инструментов, предоставляющих функциональность карты пациента и мониторов жизнедеятельности (при этом они избежали ситуации «тащите самую крутую машину, начальник идет»).

Характеристики, возможности и компоненты

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

Как выяснилось, для вывода о состоянии программного продукта, информация должна быть структурированной и упорядоченной. «Докторам проще — все их пациенты выглядят одинаково», говорит Уиттакер. Чтобы иметь возможность делать осмысленные заключения о состоянии программного обеспечения, они стали собирать желаемые характеристики своих продуктов. Например, в число желаемых атрибутов Chrome OS входят стабильность и надежность. «Всякий раз, когда продажники используют наречие или прилагательное, мы создаем характеристику», говорит Уиттакер. Эти характеристики затем собираются в облако тегов, чтобы обеспечить видимость относительной важности разных характеристик.

Для каждой характеристики собрали список программных компонентов, которые на неё влияют. Для Chrome ОС это заняло около 20 минут. После этого, собираются возможности, начиная с глаголов, которые используются при описании функциональности. Например, возможностями Chrome OS являются «подключается к Интернету», «показывает веб-страницу». Получение списка 304 возможностей Chrome ОС заняло около двух часов. Сомневаясь, что возжности на этом исчерпываются, они провели ревью списка, и получили в конечном итоге 314 возможностей.

Возможности, компоненты и характеристики «определяют нашего пациента», говорит Уиттакер. По его словам, особенность Google в том, что у них очень низкое соотношение числа тестировщиков к разработчикам. В «богатых» командах оно достигает одного тестировщика на четверых или шестерых разработчиков, типичным является соотношение один к четырнадцати, а в некоторые командах один тестировщик на двадцать восемь разработчиков. Виттакер говорит: «Если разработчикам нужно что-то протестировать, они должны попросить вежливо и быть готовым к отказу. Команде тестирования нужно понять, что тестировать, и вы должны убедиться, что весь ваш код связан с набором возможностей, связанных с компонентом, связанным с характеристикой». [Тестировщики] расставляют риски по матрице возможностей и характеристик, и риск определяет, куда направляются ресурсы тестирования. В результате, разработчики уделяют большое внимание качеству своих продуктов.

Использование «обходов» в качестве тестовых стратегий

Подобно тому, как врачи используют виды лечения (например, витаминотерапию или химиотерапию), чтобы обсудить весь комплекс действий с коллегами и пациентами, Уиттакер рекомендует использовать «обходы» (tours) для описания тестовых стратегий. Он привел несколько примеров «обходов», использующихся в Google — таких, как: проход по переулкам (посещение мест, куда до этого мало кто заглядывал), ночная экскурсия (запуск программного обеспечения в лаборатории на ночь, без выключения) и поход по шотландским пабам (охватить тестами всю систему целиком). Эти обходы служат языком паттернов высокого уровня для действий и проверок в течение тестовой сессии, без углубления в детали низкого уровня. Они помогают команде обсуждать глобальные проблемы и общаться более эффективно.

Head-Up дисплеи

Монитор в комнате больного говорит зашедшему врачу все необходимое о жизненных характеристиках пациента. Ему не нужно куда-то идти, чтобы выяснить подробности. Уиттекер считает, что видеоигры являются отличным примером того, как head-up-дисплеи представляют сложные данные на экране в очень доступной форме. «[Игрокам] не приходится писать SQL запросы во время игры», говорит Уиттакер, доказывая, что тестировщики тоже не должны писать SQL запросы, чтобы получить важные показатели программного обеспечения. Затем он показал несколько примеров систем, которые они разработали в Google для отображения основных показателей своих продуктов.

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

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

Значит, тестирование похоже на медицину?

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

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

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

Вредные стороны тестировщиков

— Что хуже: безграмотность, бескультурие или безразличие?
— Я не знаю, и мне похер!

Не уверен, что выбрал правильное название. То, о чем я собираюсь рассказать, по большей части относится к общей психологии, к общим же проблемам в сфере информационных технологий, и иногда просто к последствиям неправильного выбора профессии. Должен также отметить, что значительная часть нижеизложенного относится ко мне самому: человеку свойственно замечать в окружающих свои собственные проблемы. Тем не менее, все эти «особенности», как мне кажется, приводят к общему неприглядному виду отрасли, и профессии тестировщика в том числе. Большую часть примеров я набрал на собеседованиях, и, думаю, те, кто тоже этим занимались, найдут похожие детали.
Итак, за что я ненавижу тестировщиков, как встречаемых лично, так и виртуальных, например, посетителей профессиональных форумов?

Свой самовар. Привычки – это нормально. Отсутствие адаптации к команде – уже плохо. Я обычно делаю скидку на то, что большинство тестировщиков происходят из больших компаний, со своими правилами, дресс-кодом и прочими заморочками. Их поведение определяется тем, как их учили, и менять это поведение они не хотят, потому что так удобнее им. Наиболее яркий пример – нежелание осваивать принятый словарь – набор ключевых слов в описании проблем. Когда тестировщик приносит свой словарь с собой, в базе ошибок появляется невероятное количество дубликатов. «Был убит ударами молотка», «поскользнулся и ударился о молоток 5 раз», «множественные раны, нанесенные тупым предметом» – все это описание одной проблемы, но разным языком. Я считаю важным для тестировщика, чтобы он работал с принятым в команде словарем, процессами, и так далее. Иногда становится очевидно, что что-то в команде делается не так, но худшим аргументом будет «нас учили по-другому». Никого не волнует, как тебя учили. И как ты привык. Команда заинтересована в успехе команды.

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

«Стимулированная» апатия. Бывает очень похоже на первый случай, но есть нюанс. Нанимают на работу тестировщика, показывают, где лежат лопаты, дают ключ от ящика с ними, говорят, где копать, – и бросают. Метод Тургенева, безусловно, имеет право на существование, но Герасим все же за собачку свою переживал. В нашем же случае самомотивация работает некоторое время, а потом – оп! – и уже неинтересно. Или например, совершает человек ошибку, и ему больше не дают серьезных задач. «Чукча, покорми собак и смотри, ничего не трогай!» Лопата заменяется на напильник, получается этакая Золушка, углы заметать и фаску снимать. Можно подумать – а где же здесь вредные привычки, ведь во всем виноваты окружающие? На самом деле, связь (или общение) обычно требует участия как минимум двух сторон. Тебе кажется, что тебя бросили? Крикни что-нибудь сам – если нужна помощь, расскажи о том, что делаешь, дай людям знать, что ты еще не умер. Поставили в угол с напильником? Съешь «Растишку», сделай что-нибудь действительно хорошее, и похвастайся. В крайнем случае, если ничего не помогает – просто собери удочки и иди сверлить лунки на другом катке. Только не будь овощем.

Неуверенность, скрывающая безответственность. Здесь несложно спутать симптомы. Иногда тестировщик обращается за помощью к программисту, или к другому тестировщику, когда он чувствует неуверенность и хочет исследовать проблему более глубоко. Это хороший признак. В других же случаях он, обнаружив проблему, долго ищет, с кем бы поговорить об этом, ищет программиста, чтобы удостовериться, что он действительно нашел «баг», долго с ним это обсуждает, и в результате спускает все на тормозах. Одно из худших последствий такого поведения – проблема теряется, благополучно переживает все итерации тестирования, потом всплывает у пользователя и возвращается уже в виде инцидента. Нормальное явление – когда обнаруживаются не все ошибки, такое бывает, и приводит только к улучшению тестирования. Ненормальное – когда уже обнаруженные ошибки замалчиваются. Помните легенду о появлении термина «баг» в тестировании? Каждая ошибка должна быть аккуратно пришпилена булавкой к странице, описывающей её поведение. Багрепорт – это точка зрения, и каждая точка зрения заслуживает поддержки. «Я закрыл свой багрепорт, потому что программист сказал, что это не ошибка» — хороший пример безответственности. «Программист сказал ,что это не ошибка, но я нашел еще двоих и мы ему навешали люлей» — уже чувствуется движение в правильную сторону. Если ты высказал свою точку зрения, потрудись её отстоять, попытайся понять, почему она не совпадает с другими.

Любовь к процессам, скрывающая неумение работать. В речи такого тестировщика наиболее часто можно встретить: «давайте договоримся», «не буду тестировать без спецификаций», «не буду программировать без ТЗ», «уйди, противный!», «а вот если бы у нас был RUP…». Время течет. Мир вокруг меняется. Практика показывает, что в большинстве случаев универсального решения не существует. Почти каждая проблема требует своего собственного подхода. Ничем не поможет инструкция «перенеси вес на правую ногу, сделай шаг левой», когда ты в невесомости. Вообще эта часть должна быть в главе «апатия», потому что люди ведут себя так, когда им все равно. Тебе все равно? Займись чем-нибудь интересным.

Самоуверенность. Вот это, пожалуй, моя болезнь. Применяемый мной подход к тестированию хорошо описан в анекдоте о технаре, которому предлагают изучить китайский язык. «Методичка есть? Сейчас докурим и пойдем сдавать». Этот принцип позволяет очень быстро выявить серьезные проблемы, лежащие на поверхности, но упустить массу мелких дефектов, которые убьют продукт. Не понимаешь, что тестируешь – не берись. Понимаешь – сверь с кем-нибудь в команде, что понимаешь правильно. Только не надо на несколько дней уходить в подвал и приносить потом оттуда дохлую крысу.

Деградация. Что тут сказать? Резюме такого человека выглядит примерно следующим образом: «Админ. Программист. Программист. Тестировщик.» Все мы знаем, что люди часто ошибаются в выборе профессии, и потом внезапно находят свою родную специальность. Был крановщик – стал пианист. Был пианист – стал слесарь. Другие люди точно так же ошибаются, но «залипают» в своей области. Поступление в университет: проходит зачисление на «высшую» специальность, непопавшие в студенты бегут в деканат, быстро переписываются на следующую по списку специальность, идут на зачисление. И так далее. Такое поведение вполне можно понять, самокопание и разочарование свойственно человеку. А тестирование принято считать «низшим классом» в ИТ-отрасли. Вот они и думают, «раз я плохой программист – может, попробовать тестирование? Я плохой тестировщик – может, пойти компы собирать?» Нет, не может. Я в разговорах постоянно ссылаюсь на некий опросник, который я проходил в еще прошлом веке в Центре профориентации. Очень просто, 3 или 4 шкалы: человек-человек, человек-природа, человек-знаковая система, еще что-то. Если ты видишь, что в ИТ не получается – остановись и подумай. Может быть, ты всю жизнь мечтал быть лесником, но большие города и зарплата от полутора штук заставили тебя переступить через собственную мечту. Печальное зрелище.

Профессиональная стагнация. Королева сказала Алисе: «нужно быстро бежать, только чтобы не остаться на месте» (не уверен в точности цитаты). И это совсем не сказка и вовсе не гипербола. Начинающий тестировщик читает пару книжек, работает пару лет «обезьяной» на каких-то проектах, наконец находит вакансию своей мечты, устраивается на новую работу, и – торжественно засыпает на ней. Ему уже не надо подавать ключи, он сам крутит гайки, и, в общем, вполне этим доволен. «Что читаете в интернете? – Нууу, захожу на этот, форум такой, тестировщиков». «Работаете над этим проектом несколько лет? А на чем написано приложение, и как это влияет на тестирование? – Эээ… как-то не приходило в голову узнать». «Как себе представляете автоматизированное тестирование? – Не знаю, я им не занимался». Большие люди самых разных специальностей все как один повторяют: «первые десять лет работы я только учился, потом начало что-то получаться». Некоторые спрашивают на форумах – «Чем бы заняться тестировщикам в промежутке между проектами?» Самый простой ответ – учиться дальше.

Художники. Необходимым условием существования этих людей является система багтрекинга с поддержкой приложения файлов. Багрепорт чаще всего выглядит так: «Увидел ЭТО. Смотри аттач.» Скриншот – это фотка графического интерфейса. Интерфейс меняется. В результате уже по прошествии небольшого времени из картинки нельзя понять, что происходит, и в чем проблема. Некоторые говорят, что снятие скриншота экономит время. Я пробовал – написание детального отчета действительно занимает больше времени, чем снятие картинки – редактирование её в пейнте – приложение её к отчету… Но мне нравятся хорошо сформулированные багрепорты, которые остаются актуальными даже через несколько лет, и которые отлично ищутся по ключевым словам.

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

Бездумная автоматизация. «Как автоматизировать тестирование биллинга?» – спрашивает такой тестировщик на форуме. Он не задается вопросом, что такое биллинг, как его протестировать, ему просто нужно, чтобы все крутилось само. Вообще это странная тема. Я никогда не работал в компаниях, применяющих средства тестирования графического интерфейса, так что могу только предполагать, как это выглядит. Большие пацаны читают рекламу средства тестирования (как правило, мягко обходящую тему затрат на это дело), звонят в отдел кадров и нанимают отряд обезьянок. Надо же ведь просто кликать по кнопочкам, значит подойдут и идиоты. Пучок за пятачок. Не знаю, как там у них все это проходит, но читал недавно у кого-то, что до 90% времени, потраченного на автоматизацию GUI – просто зря потраченное время. На самом деле, автоматизация – очень полезная штука, и часто она стоит затрат, но думать, что автоматизация тестирования – это когда робот вместо тебя кнопает по кнопкам и кликает по ссылкам, совсем неправильно. И уж совсем неправильно заниматься автоматизацией, когда не понимаешь, зачем это и чем это поможет конкретно тебе и твоим коллегам.

Вертикальная карьера. Лично мне кажется, что во всем виновата неправильная реклама. Существуют, в принципе, два направления развития – рост вверх по карьерной лестнице, и «утолщение» в профессиональном плане. По каким-то причинам считается, что вертикальная линия более правильная. Да, в каких-то случаях это так. Но многие забывают, что реальный рост – это в большей степени не расширение полномочий, а увеличение ответственности. На этом строится стандартная шкала «взросления» – Junior-Engineer-Senior, где джуниор не стыдится попросить помощи, а сениор в основном только и делает, что помогает другим. В нашем же случае кандидат, претендующий на позицию «ведущего специалиста», заявляет: «ну, я могу раздавать задания». Ну надо же! Говоря в терминах собеседования при найме – решите сразу, кто вам нужен. Талантливый управленец или талантливый специалист. Если действительно нужен управленец, и кандидат проявляет хорошие способности к этому – почему бы и нет? Если он из разряда «кто не умеет – учит» – оно того не стоит.

Ссылки по теме:

Губная гармошка для здоровья и хорошего настроения

Оригинальная статья с сайта Harmonica Masterclass в архиве

Счастливые жители Великобритании // goodnewsnetwork.org
Счастливые жители Великобритании // goodnewsnetwork.org

В течение многих лет я слышал положительные отзывы о гармошечных программах для пациентов с легочными заболеваниями и о пользе, полученной их участниками. Из разговора с доктором Дэннисом Бако во время обеденного перерыва на моем Harmonica Masterclass Workshop в Long Beach California, получилось то, что вы видите ниже. До выхода этой книги, не существовало специальной гармошечной методики для легочных больных, но было очевидно, что для обучения таких людей должен применяться методический подход. Представленные обучающие материалы заполняют этот пробел.

Для начала нужно было разобраться в легочных заболеваниях. После некоторых изысканий стало понятно, что ориентироваться нужно в первую очередь на больных с ХОЗЛ (хроническими обструктивными заболеваниями легких). Обычно в эту группу включают больных эмфиземой, хроническим бронхитом и астмой. Ниже приводится основная информация об этих заболеваниях.

Дыхание

Большинство людей считают «дыханием» сжатие и расширение грудной клетки, однако на самом деле значительную роль в перемещении воздуха играет диафрагма. Диафрагма – тонкая мышца, отделяющий грудную клетку от брюшной полости – движется вверх и вниз, как батут, и изменяет давление в легких. Когда диафрагма движется вниз и грудная клетка расширяется вместе с легкими (на вдохе), давление внутри легких становится отрицательным и в них поступает воздух. В результате этого альвеолы (пузырьки в легких) расширяются и наполняются воздухом (стенки альвеол столь же тонки, как стенки мыльного пузыря). Свежий воздух контактирует с мелкими кровеносными сосудами (артериальными капиллярами, окружающими альвеолы), и кислород попадает в кровь, где прикрепляется к красным кровяным тельцам. В то же время диоксид углерода (отходы метаболизма) проникает через венозные капилляры в альвеолы. Когда диафрагма расслабляется и движется вверх вместе со сжатием грудной клетки, воздух вместе с углекислым газом покидает легкие.

Эмфизема

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

Хронический бронхит

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

Вся поверхность вронхов пронизана клетками с небольшими волосками – ресничками. Другие клетки выделяют специальный секрет – слизь, которая покрывает реснички. Миллионы ресничек перемещают слизь по направлению ко рту. Инородные частицы, попадающие внутрь при вдохе, захватываются слизью и выносятся по трахее наружу, а далее проглатываются или отхаркиваются. При хроническом бронхите поверхность бронхов воспаляется, опухает и выделяет слишком большое количество слизи. Припухлость воздушных проходов уменьшает доступный объем, увеличивает сопротивление и затрудняет дыхание. Часть воздушных проходов может быть даже заблокирована лишней слизью. В свою очередь, слизь не отхаркивается наружу из-за суженных проходов, тем самым увеличивая вероятность легочных инфекций, вызывающих длительное повреждение легких.

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

Проблема №1 – ХОЗЛ вызывают задержку воздуха в альвеолярных мешочках. При эмфиземе – из-за потери упругости, и при бронхите – в результате раздражения и опухоли, воздушные проходы стремятся сузиться или сжаться во время выдоха. Это приводит к затруднениям при выдыхании и к застаиванию воздуха.

Традиционное решение. «Дыхание через сжатые губы» помогает ослабить сжатие воздушных проходов благодаря увеличению сопротивления потоку воздуха. Давление внутри воздушных путей повышается, благодаря тому, что воздушные проходы и мешочки остаются открытыми, пока диафрагма и мышцы живота выталкивают воздух из легких. Этот прием выполняется следующим образом: вы вдыхаете через нос, держа рот закрытым. Сжимаете губы, как при свисте или поцелуе, и выдыхаете медленно, постепенно напрягая мышцы живота, чтобы вытолкнуть воздух. Поддерживайте давление, достаточное для получения звука, но не торопите выдох. Поддерживайте расслабленное состояние и выдыхайте как минимум вдвое дольше, чем вдыхаете. При вдохе считайте от одного до двух, при выдохе – до четырех. Всегда выдыхайте вдвое дольше, чем вдыхаете.

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

Проблема №2 – потеря эффективности мышц диафрагмы. Диафрагма – основной «дыхательный» мускул. Это большая куполообразная мышца, расположенная сразу за легкими и отделяющая грудь от брюшной полости. До 80% усилия при дыхании – результат работы диафрагмы. Другой способ – «грудное дыхание». Сайт DHD Healthcare утверждает, что «реберное дыхание раздвигает кости грудной клетки вверх и в стороны при помощи внешних межреберных мышц, увеличивая объем груди и создавая частичные вакуум. Расширения легких из-за пониженного давления недостаточно для вентиляции нижних легочных долей, и вентиляция легких ухудшается, так как именно нижние доли взаимодействуют с большей частью крови благодаря силе тяжести. Дыхание неглубокое, с небольшим перемещением живота». Больные часто используют «вспомогательные дыхательные мышцы» – шею, грудь, руки и плечи. Из-за чрезмерного вздутия легких, у больных эмфиземой и бронхитом развивается плоская диафрагма, которая не может работать достаточно эффективно для циркуляции воздуха в легких, и человек использует вспомогательные мускулы для компенсации этого.

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

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

Проблема №3 – больные ХОЗЛ испытывают трудности как при вдохе, так при выдохе. В большинстве случаев это объясняется потерей упругости легких и жесткостью нижней части грудной клетки, включая мышцы, хрящи, сухожилия и кожу. Подвижность грудной клетки особенно страдает из-за неглубокого дыхания.

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

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

Проблема №4 – потеря радости жизни, независимости, депрессия. Многие больные с хроническими заболеваниями страдают от депрессии и понижения качества жизни.

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

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

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

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

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

Игра на гармошке – не единственный способ борьбы с болезнью, но она помогает вести здоровый и активный образ жизни. Не отказывайтесь от специальных упражений, рекомендованных вашим врачом, используйте гармошку как дополнение к ним. Клинически не подтверждено, что игра на гармошке оказывает серьезную помощь при ХОЗЛ, но глядя на людей, знакомящихся с этим инструментом, становится очевидно, что польза его безгранична.

Дополнительные материалы (на английском языке):