Цитата недели: Никто не знает, сколько стоит качество

Недавно к нам приезжали менеджеры из далекого и туманного. Кроме корпоративного похода по ресторанам и их полных ужаса взглядов (погода то была в районе -24) я еще запомнил несколько стратегических целей и цитат.

Наш самый главный менеджер Ивет несколько раз повторила эту фразу:

Никто не знает, сколько стоит качество.

Мир не перевернулся от этой фразы, но с тех пор я много думал. А правда - сколько стоит качество? 

Что туда входит:

- совокупная заработная плата и различные материальные и нематериальные блага специалистов по обеспечению качества (премии, страховки, бонусы, тренажерные залы),

- рабочее место (компьютер, программные средства, сервера и серверное ПО, электричество, уборщицы и пр),

- выплаты по неустойкам связанными с простоями клиентов - в связи с сбоями в системе и вовремя не обнаруженными дефектами,

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

- наверное что то еще , чего я пока не знаю Ж).

Как рассчитать сколько стоит качество? Ведь любой продукт (программный - не исключение) изначально обладает каким то качеством. Это уже позже идут формальные оценки на предмет того у кого качество выше (прям мужской подход - "мое пузо больше"). Но все равно оценивая формально, наверняка мы не можем точно определить, какое из качеств продукта сколько стоит. Фичу - да, фичу оценить можем. Ее заказывает клиент и мы ее продаем. Но клиент платит за функционал, который работает. А качество... Ну да, качество может быть от 0 до +100.

Другая сторона медали - доверие клиента. Мы разрабатываем продукт. Клиент доверяя нам - покупает продукт, надеясь на определенный уровень качества. Если его не будет, кто проиграет? Сколько мы потеряли в будущем, халатно отнесясь к своим обязанностям?

Вопрос - зачем кому то знать сколько стоит качество? Чтобы попросить половину этой суммы у начальства и обещать, что другую половину тратить не придется ))

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

Замечательный человек Yourdon Edward в своей книге процитировал не менее замечательного Kevin Huigens. Собственно Кевина цитировали несколько раз, мне больше всего понравился вопрос "Если ваш коллега собирается стать менеджером безнадежного проекта, что бы вы ... посоветовали ему не делать ни при каких обстоятельствах"

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

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

Kevin Huigens

Любите не компании, а людей.

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

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

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

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

Мне так же говорили - нужно ценить ценности компании. Я же думал о том, что ценить нужно прежде всего ценности отношений между людьми. Ценности любой компании в том чтобы выжить на рынке (чтобы они не писали в своих миссиях). А это чревато ох каким отсутствием человеческих ценностей, которые мне близки, во времена кризиса.Спрашивали ли Microsoft/IBM/etc: мы вас увольняем, но вы ведь продолжаете любить нас? Как бы мне хотелось увидеть эту статистику.

Сейчас я уже полгода в новой компании. И я стараюсь, искренне стараюсь, наладить отношения со всеми, с кем пересекаюсь. Иногда это бывает сложно, по причине что люди разные, и я всех сразу понять не могу. Любить...рано еще наверное любить, но с некоторыми общаться гораздо приятнее, и даже не только о работе (в не рабочее конечно же время!ж) )

Давным давно мне посчастливилось прочитать Тайм Менеджмент Для Системных Администраторов. Мне очень нравиться то, что думает автор. И хочется процитировать. Если в очередной раз нарушил копирайт...совесть меня не замучает, но извиниться могу.

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

Раньше существовал так называемый «неявный общественный договор». Мы работаем на фирму 40 часов в неделю, а она платит нам, чтобы у нас были средства к существованию, и что-то отчисляет в пенсионный фонд нам на старость. Это была честная сделка. Но теперь корпорации отбирают у нас все больше времени без какой бы то ни было  компенсации. Профессионал работает 60-70 часов в неделю, а потом подпадает под массовое сокращение штатов из-за ошибочных решений бестолковых топ-менеджеров, зарплата которых в 100, если не в 1000, раз превышает его зарплату. 

В 1990-е годы я работал в AT&T/Lucent,  и нам постоянно напоминали, что могут уволить нас в любой момент независимо от того, насколько хорошо мы справляемся с работой. Нам говорили, что надо радоваться переходу от гарантированных пенсий  к принципу «каждый сам за себя» в соответствии с новым пенсионным планом, принятым фирмой. И при этом в последние годы моей работы в этой компании руководство было поражено и встревожено снижением лояльности сотрудников. Лояльность - улица с двусторонним движением.

Томас Лимончелли

Собственно, я не призываю "не любить компании", в которых нам приходиться работать. Я говорю о том, что мне больше нравиться ценить те человеческие отношения, которые мы зарабатываем в этих компаниях, и сердечно относиться к тем людям, которых начинаем считать друзьями. Даже если между вами пропасть: вы тестировщик, а он разработчик ;)

PS. Да, кстати, мое мнение может не совпадать с официальным мнением компании, в которой я работаю сейчас или работал раньше.

Главное - это быть уверенным в том, что главное это главное. С. Кови

В последнее время замечаю за собой манию к тушению пожаров и переработке, даже когда в этом острой необходимости и нет (наверное нет - я даже в этом не уверен).

Не знаю следует ли своим советам Стивен Кови, но мне сейчас нужен хороший совет. Как начать жить спокойно. Как не перерабатывать. Как успокоить нервы. Как высыпаться за 8 часов. Как перестать мучаться из за совести (которая пилит, пилит -  что можное еще что то сделать, а ты домой - к семье). Нужен совет. Совет на оставшуюся неделю:

Главное - это быть уверенным в том, что главное это главное. 

С. Кови

Совет о том, что нужно уметь ставить приоритеты. Выше приоритетов ведь еще никто не прыгал ж).

Сам постараюсь следовать ему. И вам того же желаю.

QA NewComer Checklist

Адаптации нового сотрудника в новой (ом) компании\проекте\команде. 

Более быстрый и более дешевый ввод в проблемную область нового специалиста.


Как можно быстрее, и как можно качественнее обучить новичка...

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

Я не так часто в своей жизни менял работу (смотря с кем сравнивать ;) ) .  Но мне приходилось и учиться, как новичку и обучать новичков. Данная заметка - мой взгляд на непростую ситуацию, когда хочется и быстро и хорошо: разделить успех сытых волков и тучных овец.

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

Собственно я столкнулся на своей новой работе с так называемым Newcomer Checklist. До этого мне приходилось читать, в потом и создавать официальные документы. Плюсы от таких документов конечно же есть, но были и минусы: подписать один документ своим начальником, зам ГД по кадрам + генеральным директором - дело не одного дня. А вот  Necomer CheckList это страница в wiki подобной системе, в которой просто по пунктам указано:

1. Программы, аккаунты, права доступа и соответственно процедуры получения программ, аккаунтов, прав доступа.

2. Общие процедуры: оформление отпуска или отгула, ведение календаря или табеля учета времени, внутренние ссылки.

3. Процедуры и процессы (например, в моем случае, по обеспечению качества), шаблоны (тест планов/спецификаций/тестовых сценариев), руководства пользователя и линки на информацию по проблемной области.

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

После выполнения всех пунктов чеклиста, я немного расширил страницу и добавил ответвление: QA Necomer Checklist, но смысл остался примерно тот же самый.

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

Сложного ничего нет. Нужно  просто обновлять страницу по мере необходимости. Информация же не меняется сразу и вся ;)

Форма чек листа помогает настроить новичка на нужную волну и отслеживать, как продвигается его адаптация.

Wiki подобная система ликвидируют ограничения формальных письменных документов.

Собственно сплошные плюсы проекту.

Как говорил мой преподаватель философии: "Это нужно обдумать".

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

Не то что бы я очень сильно любил цитировать американских президентов, но цитировать наших было бы весьма рискованно: "мочилово", "посадки" - тюремная романтика, а если вспомнить царя Бориса...

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

И снова, как и прошлую, эту цитату я "вспомнил" у Сергея Архипенкова:

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

Рональд Рейган

Хорошая мысль для этой недели. У ДеМарко (Deadline. Роман об управлении проектом) помнится тоже мелькало нечто подобное:

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

А лично я вспоминаю слова своего коллеги о своем начальнике: "Хороший начальник. Не мешает работать".

Все мы любим, когда нам не мешают.

Все мы любим когда нам доверяют.

Но только не все, к сожалению, выдерживают этой проверки доверием.

Так уж случилось, что данная цитата недели моя первая цитата в блоге. И собственно первая заметка в блоге в 2010 году.  Именно поэтому, я бы хотел вам пожелать (пока Старый Новый Год еще не наступил) в этом и следующих годах такой работы, на которой вам никто бы не мешал. На которой у вас был бы "замечательный" начальник, которвй тем не менее просил бы хотя бы раз в неделю объяснить - чем конкретно ты занимаешься, и как там дела с теми заданиями, которые он тебе дал в прошлом году ;).

Идеальная автоматизированная система управления качеством программных продуктов

Если бы вы могли получить то, что хотите, какую бы идеальную систему для управления процессом обеспечения качества, вы бы пожелали?

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

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

Когда я только пришел на работу, централизованно можно было только собрать совещание. Когда я уходил, проектировщики могли выгружать из своей системы данные технологам в их систему. Наши экономисты уже автоматически формировали отчетность, в том формате которую требовали бухгалтеры и финансисты. Централизовано работала электронная почта с одним доменом и службой Active Directory. Централизованно же мы закупали ПО и лицензии. Пытались влиять, опять же централизованно, на закупку/распределение компьютеров. На внутреннем веб-сайте с использованием IIS+IE+Active Directory   работала система одного окна для поисковых систем по архиву, внутренним базам данных. Было чем гордиться. Почти  пять лет я потратил на автоматизацию и объединение разрознненых систем и процессов.

И вот то же самое начало я вижу и сейчас (про то же самое я, кстати, читал и в How We Test At Microsoft): отсутствие централизации в процессе обеспечения качества, и самое главное - отсутствие единого продукта для автоматизации работы специалистов  по обеспечению  качества (и тестировщиков).

Что же мы имеем:

Excel - незаменим при построении тестовых roadmap-ов, собственно тестов и даже для создания документов.

Word - тоже полезен для создания документов. Отчеты, спецификации,... (если бы не корпоративные политики давно бы использовал только Open Office Write и Calc, кстати говоря).

Jira - наше все: баг трекинг, трекинг фич, планирование релизов, оценка времени и регистрация информации по проектам, накопление статистики, формирование репортов. Наверное Jira можно использовать и как систему хранения документации (версии, история), но это, как мне кажется, тяжелое решение.

MS Project - диаграмму Гантта никто не отменял.

HP Quality Center - хранить тесты, планировать регрессионные тесты...ну хоть что то же нужно автоматизированно готовить - хотя бы регрессионные тесты.

Confluence/TWiki/Sharepoint/ - коллективный разум должен хоть что-то после себя оставлять в виде файлов, ссылок, статей и картинок.

Тузлы для автоматизации, программирования, статического анализа, хранения кода... Это уже детали.

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

А что бы я хотел иметь?

Я бы хотел иметь систему. Одну. Чтобы я мог сам построить workflow.  Чтобы я видел версию документа не в SharePoint, а мне приходило оповещение, поскольку я в роли тестировщика указан в данном проекте.

Хочу полноценную систему документооборота с архивом.

Хочу систему управления требованиями в том же виде, что и в Word или Wiki, но если я помечаю абзац как требование - это требование начинает жить своей жизнью: с версионностью, историей изменений, приоритетами и подтверждениями.

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

 А представьте, как прекрасно выглядят деревья тестовых сценариев с различными тегами (или категориями, или ярлыками).

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

А если вам нужно узнать среднее время для прохождения помеченных вами или выбранных системой автоматически тестовых сценариев '=sum(...' уходит в прошлое. Ведь для этого есть специальная колонка!

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

О да, моя система могла бы многое. Если бы вы спрашивали о фиче1, вам бы предлагали фичи, который рассматривались с этой фичей раньше (фича66, фича121).

Моя бы система на вопрос о environment ошибке предлагала бы контакты суппортеров и workaround. Более того, она сама бы рассылала сообщения суппортерам. Ты звонишь по контакту, а он, какое чудо, занимается твоей проблемой уже почти три минуты.

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

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

Моя система сама рассылала бы QA Daily Report и табель.

Моя система сама бы расчитывала показатели: сколько багов найдено и пофикшено, сколько багов пофикшено в текущем релизе, сколько багов на душу населения команды мы прос...ли и получили outages от бизнеса.

Моя система была бы идеальна...

Именно поэтому бы ее никто и не смог использовать.

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

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

И все таки, если уж понеслась такая ярмарка...

Моя система управления процессом обеспечения качества была бы OpenSource.

Моя система была бы модульной и позволяла бы внедрять себя поэтапно. Строилась как конструктор.

Моя система могла бы расширяться пользователями и иметь свой собственный язык программирования, либо позволяла дописывать себя на любом языке, либо встраивать плангины. Либо позволяла делать и то и другое и третье.

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

У каждого проекта должна быть своя модель процесса разработки.

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

Agile, XP, CMM...

Фреймворки, методы, методологии...

Стандарты, манифесты, спецификации...

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

У меня не было опыта внедрять что-то целиком. Собственно и полномочий таких тоже не было. Я можно сказал внедрял "серебряные пули" в отдельно взятом процессе, подконтрольному мне. Сначала в системное администрирование и поддержку. Потом в разработку. Теперь в тестирование и обеспечение качества.

Собственно весь жизненный опыт в ИТ вопит во мне: дело не в методологиях. Дело - в командах, где все это внедряется. Дело в людях. В зрелости людей. В их понимании конечных целей.

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

У каждого проекта должна быть своя модель процесса разработки.

У каждой модели - свое время.

Нужно дозреть. Проекту. Процессу. Команде. Специалисту...

Внедрять новое - это конечно замечательно.  Новое бодрит кровь, делает нас вновь молодыми ;). Но всему свое время.

В садике - игрушкам.

В зрелом возрасте маразму.

Надеюсь, вашему проекту это не грозит.

Если вы учите человека чему либо, он этому никогда не научиться.

Бернард Шоу был сто раз прав. Обучение чему либо, без практики это то, что сейчас губит высшее образование и знания вообще.

Первый месяц на новой работе я потратил на обучение. Мне думалось, что все изучу сам (были еще индийцы, но отсутствие активной разговорной практики английского, да плюс еще витиеватый восточный акцент... ну вы понимаете). Прочитаю и все-все пойму. Ведь документации много. А я читаю много и даже на английском. Не может быть, чтобы я прочитал и ничего не понял!

Прошел месяц. Документации оставалось все еще много. Ко мне подошел team lead Юра.
-Читаешь?
-Ага, изучаю - ответил я.
Юра кивнул головой.
- И когда закончишь.
Вот тут до меня, спустя месяц чтения, наконец стал доходить сокровенный смысл того, что я делаю. Я тупо читаю документацию. Я изучаю поведение графического интерфейса по бумажке. Мне вспомнились лекции, которые нам читали в университете. MS Word рисуемый на доске. Программный код программы распечатываемый на бумажке (100-200 страниц 10 шрифтом)...

Мудрые восточные люди (Интернет предлагает вариант, что это были китайцы) придумали: Я слушаю – и забываю, я вижу – и запоминаю, я делаю – и понимаю. 

Бернард Шоу остановился только на обучении. Мне кажеться он даже прав - в обучении ты можешь и слышать, и видеть, и делать...и даже ломать ;). Но именно практика делает из студента специалиста, а из специалиста профессионала.

Выношу цитату Шоу как недельную. Ибо уже вторник, но до конца недели еще есть время.

Если вы учите человека чему либо, он этому никогда не научиться.

Бернард Шоу

If you want to get a high quality product out of test...

Доброго дня суток.

Целый месяц прожил без Интернет. Это было мучительно, больно, скучно и тоскливо. Но я выстоял. А куда деваться если в новой снимаемой квартире его нет.

В итоге цитата недели висит уже месяц. Застоялась однако. Запашок.

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

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

If you want to get a high quality product out of test, you have to put a high quality product into test

Во истину так, ибо каждый отвечает за качество своей работы.