Quality Assurance, STUdying, GAmification, MAnagement and other: сентября 2013

понедельник, 23 сентября 2013 г.

Рост команд тестирования - мифы и реальность. Часть 2. Инструмент для оценки риска роста.

Продолжаю публикацию моего выступления на SQA Days 13. Напомню, что это не построчный перевод моего доклада, а его переработанная версия. Одни моменты я просто не успел рассмотреть за 20 минут блиц-доклада, другие - прозвучали в вопросах слушателей, за что вам большое спасибо!

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

Инструмент для оценки риска роста.

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

Любой рост - это хорошо.
Больше - значит, лучше.
Или расти, или умри.

Теперь, когда мы знаем "грабли", на которые не следует наступать, рассмотрим набор вопросов (взяты с первой части курса Grow to Greatness). Некоторые потребуют ответа "здесь и сейчас", другие потребуют большего внимания на более поздних этапах роста. Обращаю внимание, на все эти вопросы вам необходимо отвечать каждый раз, когда у вас возникает возможность роста команды.

Зачем мы должны расти?
Как мы должны расти?
Как сильно мы должны расти?
Как много роста мы можем себе позволить?
Достаточно ли у нас людей?
Есть ли у нас правильные люди?
Есть ли у нас процессы найма и обучения?
Есть ли у нас адекватные способы оценки и мотивации сотрудников?
Есть ли у нас поставленные процессы контроля качества?

Рассмотрим каждый пункт подробнее.

1. Зачем мы должны расти?

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

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

2. Как мы должны расти?

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

Очень многое зависит не только от первого, но и второго тестировщика на проекте:

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

3. Как сильно мы должны расти?

4. Как много роста мы можем себе позволить?

Жил-был замечательный тестировщик Коля. Тестировал он хорошо, даже отлично: заказчик был доволен, разработчики тоже. И вот однажды менеджер проекта Миша предложил: "Коля, ты отлично работаешь, но функционал приложения у нас расширяется, тестировать вручную надо еще больше, а ты у нас один. Давай мы тебе возьмем помощника, а еще лучше, не одного, а сразу трех (что-то подозрительно напоминает). Благо, мы работаем в ста метрах от университета. Наймем трех джуниоров-студентов, замотивируем их стартовой зарплатой, которую им даже после окончания университета по специальности никто не сможет предложить, они будут тестировать, а ты будешь ~~за ними следить~~ ими управлять, да и уму-разуму их обучать."

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

Мораль, выводы? Их несколько. Первое: хоть и мог Коля расти, но сразу трех джуниоров он не потянул. Взял бы одного, обучил, поработал бы с ним несколько итераций в проекте - можно было бы еще одного взять, а потом, как научил второго, можно и третьего. При этом, постепенно, а не сразу, передавая тестируемый функционал джуниорам, по мере изучения ими продукта.

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

5. Достаточно ли у нас людей?

Рост - это не обязательно привлечение новых людей. Есть "разовые задачи" по тестированию (см. вопрос 1 - делегируем), есть и "внутренние задачи", над которыми нужно работать всем вместе: повышение качества - это задача не только тестировщика, но и всей команды. Например, проведение инспекций кода, ретроспективных митингов, тест-сессии в паре с программистом (см. статью Джеймса Баха). Эти и другие способы позволят вам привлечь на сторону улучшения качества вашего продукта и ваших коллег. Еще возможные варианты - работа с отделом поддержки (если он есть на вашем проекте) и привлечение бета-тестировщиков (например, при тестировании игр).

6. Есть ли у нас правильные люди?

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

7. Есть ли у нас процессы найма или обучения?

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

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

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

Но и тут, с технической частью, не все бывает просто. Возможно, вам придется набирать сотрудников на ту область тестирования, в которой требования выше, чем ваши знания в данной области. Как вы можете проверить, что перед вами действительно классный специалист, а не красиво говорящий болтун, прочитавший одну хорошую статью с хабра, или утверждающий, что он в ТОП-100 рейтинга stackoverflow? Обратимся ко второй части курса Grow to Greatness, а именно к Part 4: Hiring Senior Management Team, см. карту памяти.

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

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

8. Есть ли у нас адекватные способы оценки и мотивации сотрудников?

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

9. Есть ли у нас поставленные процессы контроля качества?

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

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

пятница, 13 сентября 2013 г.

Рост команд тестирования - мифы и реальность. Часть 1. Мифы.

Вспоминая прошедшие минскую SQA Days 12 и петербургскую SQA Days 13, по-хорошему завидую тем, кто в ноябре посетит очередную четырнадцатую, на этот раз в славном городе Львове, с новыми докладами и премьерным английским днем. Если вы еще не присоединились к тем, кому небезралично качество ПО и кто желает сделать мир лучше, у вас еще есть время.

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

Как появилась эта тема.

Довольно часто, очень хорошая идея приходит не прямо "из книжки" в готовом виде, но и из, на первый взгляд, неожиданного источника. Есть такой образовательный ресурс - http://www.coursera.org. Это онлайн-курсы по различным дисциплинам от ведущих университетов США, Англии и других стран. Число дисциплин более 30, а общее число онлайн-курсов - более 200 на текущий момент, и оно продолжает увеличиваться. Как работника ИТ-сферы, меня интересуют курсы по Computer Science и по менеджменту.

Один из представленных курсов - Grow to Greatness: Smart Growth for Private Businesses - рассказывает о росте команд в бизнесе. Принципы и факты о росте команд, озвученные харизматичным лектором Эдвардом Хессом, заинтересовали меня, я проанализировал свой опыт работы в командах тестирования, и решил рассказать об этом для вас.

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

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

Давайте сначала поговорим о том, что делать НЕ нужно, каким мифам нельзя верить.

3 мифа о росте команд.

Миф 1. Любой рост - это хорошо.

Вы работали и набрали достаточно опыта, умеете отличать тест-кейс от тест-сета, знаете разницу между тестированием и проверкой, возможно, сдали на какой-нибудь красивый сертификат или успели поучаствовать в конференции. И хотя вы не Майкл Болтон, но кое-что в тестирование вы тоже знаете и умеете. И вы считаете, что будет легко управлять командой супергероев-Мстителей. Главное - найти их. Или вырастить. Но супергерои решают какую-то глобальную задачу, и им может оказаться "тесно" и не интересно на вашем проекте.

Еще одна обратная сторона медали - "эффект цунами". Слишком большой рост может поглотить людей, процессы и качество. Рассмотрим такую ситуацию, назовем ее "интерны". Вы один на проекте, и к вам добавляют трех способных рвущихся в бой джуниоров. Теперь ваша задача - не только самому протестировать, но и чему-то обучить джуниоров, дать задачи, проверить, скорректировать, мотивировать... Вполне может оказаться, что все ваше рабочее время будет уходить на управление джуниорами. Команда супергероев? Нет, это реклама МММ, или Moody Monkey Management - унылое управление обезьянками-тестировщиками.

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

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

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

Миф 2. Больше - значит, лучше.

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

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

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

Миф 3. Или расти, или умри.

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

Напоминает ситуацию, когда маленького ребенка спрашивают: "Ты кого больше любишь, папу или маму?" Ребенок теряется, он видит лишь намеренно оставленные два варианта: выберешь папу - маму обидишь, и наоборот.

Решение в этом случае простое - возможно, вы попали в рамки своей игры, в которой есть якобы два варианта. Но "есть и другой выбор" (с) Трасса 60. Посмотрите на другие возможные варианты решения вашей проблемы, они наверняка имеются.

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

P.S. ссылка на вторую часть "Рост команд тестирования - мифы и реальность. Часть 2. Инструмент для оценки риска роста." - http://qastugama.blogspot.com/2013/09/2.html

пятница, 6 сентября 2013 г.

Тестирование и проверка - перевод статьи Майкла Болтона.

У меня для вас очередной сюрприз - я представляю вашему вниманию свой перевод очень известной статьи Майкла Болтона "Тестирование и проверка" (Michael Bolton "Testing VS checking"). Работа оказалась довольно продолжительной, но очень интересной и насыщенной, богатой новыми впечатлениями и получением нового ценного опыта.

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

Ссылка на оригинал - http://www.developsense.com/blog/2009/08/testing-vs-checking/
Формат текста (выделение терминов, курсив, цитирование) и ссылки на другие статьи из текста взяты с оригинала "как есть".

Эта статья раскрывает тему моего блиц-доклада на конференции Agile 2009. Я выражаю огромную благодарность Арлу Бельши (Arlo Belshee) и Джеймсу Шору(James Shore) за помощь в воплощении идеи в реальность. Также я хочу сказать «большое спасибо» программистам и тестировщикам за огромную поддержку моего доклада и моей идеи. Особую благодарность я выражаю Джо Рейнсбергеру (Joe (J.B.) Rainsberger). Распространите этот мем!

P.S. На протяжении многих лет люди неверно истолковывали эту статью как отказ или от проверки, или от регрессионного тестирования, или от автоматизированного тестирования. Вдобавок к этой статье, для лучшего понимания вам также необходимо прочитать (http://www.developsense.com/blog/2009/11/merely-checking-or-merely-testing/ ).

P.P.S. С момента публикации прошло довольно много времени, этот пост достаточно старый. В течение последующих нескольких лет после того, как он был опубликован, я дополнил мои исследования данной темы, в основном благодаря сотрудничеству с Джеймсом Бахом. Наши размышления на эту тему появились в блоге Джеймса, а я разместил свой ответ здесь. В усовершенствовании процессов нам помогли вопросы и комментарии коллег. Мы просим вас прочитать их комментарии и оставить свои (Апрель 2013).

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

Проверка – это подтверждение.

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

Тестирование - это исследование и изучение.

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

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

Проверка даёт бинарный результат – «истинно» или «ложно», «да» или «нет». Проверка задаёт и в то же время отвечает на вопрос «Это утверждение истинно или ложно?». Для этих простых утверждений достаточно использование компьютера, и такие утверждения нейтрально оценочные.

Тестирование содержит открытый результат. Тестирование задаёт и в то же время отвечает на вопрос «Есть ли здесь проблема?». Ответ на такой вопрос требует большого количества наблюдений человека в сочетании с большим количеством оценочных суждений.

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

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

Будем ли мы автоматизировать процесс или нет, если бы мы могли сформулировать вопрос так, чтобы машина смогла задать и ответить на него через утверждение, это почти точно будет проверка. Если же для проведения этой работы необходим человек, если эта работа интеллектуального характера, это, скорее всего, тестирование. В самом начале своей статьи «Разумные процессы», Джеймс Бах сказал «Я занимаюсь тестированием программного обеспечения. Я слышал от многих людей, что они занимаются тем же делом, что и я. Иногда, после того, как эти люди говорят об автоматизации тестов, мне начинает казаться, что они занимаются не тем же делом, которым занимаюсь я. И это так, потому что, на мой взгляд, то, что делаю я, невозможно автоматизировать в самом полном значении этой фразы. И я спрашиваю сам себя: «Какого черта они что-то автоматизируют?!». И тут же отвечаю «Они автоматизируют проверки».

Когда мы говорим о «тестах» на каком бы то ни было уровне, в которых мы делегируем решение "Да или Нет" машине, мы говорим об автоматизированных проверках. Я предлагаю называть «модульные тесты» "модульными проверками". По этой же причине, я предполагаю, что автоматизированное приемочное тестирование (Рон Джеффрис ссылается в своём блоге в статье Автоматизация историй «тестами») должно быть известно как "автоматизированные приемочные проверки". Это предложение появилось, чтобы оживить группу опытных программистов и тестировщиков на воркшопе конференции Agile 2009, о чем я расскажу вам поподробнее в следующем посте блога.

Тестирование - это не контроль качество, проверка - может быть.

Вы можете подтвердить качество чего-либо, над чем у вас есть контроль; это означает, что вы можете предоставить некоторый уровень качества - соответствие некоторым требованиям, и вы можете взять ответственность на себя, если продукт не удовлетворяет этим требованиям. Если у вас нет прав, чтобы изменить что-либо, вы не можете гарантировать качество, хотя вы можете оценить уровень качества и сообщить о найденной проблеме (см. страницы 6-7 этой статьи, в которой Сэм Канер объясняет различие между тестированием и контролем качества и ссылается на отличный набор вопросов от Джоанны Ротман, который поможет вам обнаружить различие между ними). Тестирование - это не контроль качества, но действует в его интересах; мы предоставляем информацию программистам и менеджерам, которые наделены полномочиями принимать решения.

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

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

Проверщикам нужна спецификация, тестировщикам - нет.

Тестировщик, по словам Джерри Вайнберга, это "кто-то, кто знает, что вещи могут отличаться" (things can be different (c)). Как тестировщики, наша работа - поиск инорфмации, которая зачастую представляет разницу между тем, как думают люди и тем, что верно на самом деле. (определение тестирования Сэма Канера включает в себя вышесказанное: "Тестирование - это эмирическое, техническое исследование продукта, выполняемое заинтересованными сторонами с целью выявления информации про качество такого типа, который они ищут".)

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

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

Тестирование VS Проверка - это дырявая абстракция.

Джоэл Спольски назвал закон о ценных движениях системы Законом Дырявых Абстракций ("Все нетривиальные абстракции, в некоторой степени, дырявые.") В процессе разработки продукта мы можем быстро переключаться между тестированием и проверкой. Различие между ними находится непосредственно в нашей мотивации. Давайте рассмотрим несколько примеров.

Программист, который пишет новый код и исследует новое проблемное поле. В его понимании, есть ситуация, которую нужно обработать. Он пишет утверждение - проверку. Затем он пишет код, чтобы утверждение прошло успешно. Утверждение не проходит успешно, тогда разработчик переписывает код. Проверка все равно не проходит. Программист обнаруживает, что его первоначальное предположение о проблеме было неполным, поэтому он меняет утверждение, и дописывает код. В этот раз проверка проходит успешно, что означает, что утверждение и код приложения согласованы. У него появляется идея - дописать еще код, и он снова повторяет свой алгоритм - сначала пишет проверку, затем - код, для того, чтобы проверка прошла успешно. Он также удостоверяется в том, что предыдущая проверка также работает. Затем, он видит, как код может "упасть", если ввести другое значение. Он уверен, что код пройдет успешно, но он пишет новую проверку, чтобы удостовериться в этом. Проверка проходит успешно. Он пробует другие входные значения - тест падает, и программист вынужден исследовать проблему. Он сознает свою ошибку, и использует полученное знание для новой проверки; затем он пишет функциональный код, чтобы исправить проблему и чтобы проверка прошла успешно. Таким образом, данный процесс - в значительной мере, исследование. Несмотря на то, что она продолжает использовать проверки для продолжения процесса, его фокус направлен на изучение, исследование проблемного поля, обнаружение проблем в коде и разбор этих проблем. В этом смысле, он тестирует и программирует. В конце этого всплеска разработки, он получил работающий код, который пойдет в версию продукта. В качестве положительного побочного эффекта, у программиста появился кусок кода, который поможет ему выполнить автоматические проверки, если функциональный код будет изменен. Марк Симпсон, программист, с которым я беседовал на конференции Agile 2008, сравнил этот циклический процесс с расчисткой тропы в зарослях, прорубанием нового пути через проблемное поле. Есть множество путей, по которым ты можешь пойти, и ты расчищаешь заросли неопределенности вокруг себя в попытке добраться туда, куда направляешься. Исторически, этот процесс называется "разработка через тесты" (Test Driven Development, TDD), с маленькой поправкой - в разработке через тесты, "тесты" - на самом деле, проверки. Хотя это может быть трудно, и даже несправедливо, доказывать, что в общем-то, весь этот процесс, в большей мере, не исследование. У программистов, работающих по TDD, есть цель, но путь к этой цели не всегда очевиден. Если вы знаете точно, куда идти и как вы намереваетесь идти, вам придется исследовать. Название "разработка через поведение" (Behaviour Driven Development, BDD) отчасти наводит порядок в этой неразберихе, но оно еще не получило широкое распространение. Разработка через поведение использует проверки в форме "(Программа) должна...", но процессу разработки необходимо тестирование идей по мере их формирования.
Затем наш программист просматривает код и обнаруживает, что имя одной из переменных не "говорящее", что одна строка кода должна быть более читабельна и сопровождаема, если ее переписать в две строки, что группа из трех строк можно переписать более красиво и понятно, используя цикл. Он решает отрефакторить код и обращается к решению этой проблемы - запустить проверки после каждого изменения. Его цель при запуске этих проверок - не исследование, а подтверждение, что ничего не было сломано. Он не пишет новые проверки, он вполне уверен, что старые справятся с этой задачей. В этом случае, она не тестирует продукт, она проверяет свою работу.
Большинство книг по традиционному "тестированию" утверждает, что "тестирование" это процесс валидации и верификации, как будто мы уже заранее знаем, как должен работать код. Хотя тестирование включает в себя проверку, программа, на которой были выполнены только проверки, скорее всего, недостаточно протестирована. Большинство литературы по тестированию фокусирует внимание на корректности - которая может быть проверена - и игнорирует тот факт, что необходимо задавать более глубокие вопросы о значениях, которые должны быть протестированы. Например, то, что называется "тестирование граничных значений" - обычная "проверка граничных значений". Классический пример программы, которая проверяет сложение двух двузначных целых чисел, в котором значения находятся в допустимом интервале от -99 до 99, а все значения вне пределов интервала отбрасываются. Классический совет, как "протестировать" такую программу, направлен на граничные условия, звучит как "Попробуйте -99 и 99 чтобы убедиться, что допустимые значения обрабатываются, и попробуйте -100 и 100, чтобы проверить, что недопустимые значения не обрабатываются. " Я бы хотел поспорить, что эти "тесты" настолько слабы, поэтому должны называться "проверками"; они крайне очевидны, они направлены на подтверждение, они направлены на исход, а не на результат, и могут быть легко автоматизированы. Если вы хотите протестировать подобную программу, сам следует настроить, поработать, рассмотреть продукт внимательно, с учетом и других рисков, включая не совсем очевидные, которые могут оставаться незамеченными, пока не проявят себя. Вы должны быть готовы рассмотреть все, что может повлиять на ценность продукт - проблемы, связанные с производительностью, инсталляцией, удобством использования, тестируемостью и другими критериями качества. Вам следует изменять свои тесты, а не повторять их. Вам следует быть любознательными, и выполнять некоторые тесты, не связанные с вашей текущей моделью рисков и угроз, с целью обнаружить непредвиденные риски. Вы можете использовать автоматизацию как помощник в исследовании; например, для генерации данных, для отслеживания покрытия, для разбора лог-файлов, просматривать реестр файловой системы для поиска непредвиденных последствий. Даже если вы используете автоматизацию с целью нажимать клавиши за вас, вам следует использовать автоматизацию для исследования, вы должны быть готовы изменять направление исследований и тактику, когда тест вам выдает неожиданный результат.
Исследовательское мышление использует вопросы наподобие "Что, если...?", "Мне интересно, ...?", "Как эта вещь...?", "Что произойдет, если я...?" Даже если мы тестируем программу, используя строгий подход к исследованию, мы дополнительно задействуем новые идеи, как это должно работать. "Если я нажму кнопку Отмена, диалоговое окно закроется", "Это поле запрашивает ЗИП-код в США, следовательно, это поле должно позволять вводить как минимум 5 символов", "При двойном клике по "foo.doc", файл должен открыться в программе Microsoft Word". Тестировщики-профессионалы использует эти и другие утверждения как сами собой разумеющиеся. Мы даже можем их сознательно не называть проверками, но мы подсознательно проверяем во время своего исследования и изучения программы. Если одна из проверок выполнится с ошибкой, мы наверняка получим подсказку в поиске новой информации, или если поведение программы кажется правильным, мы изменим наше представление о том, как программа должна работать. Это эвристический процесс (подверженный ошибкам означает, что при решении проблем или принятии решений, мы обучаемся, и эвристика обычно работает, но может и не работать).
Также на конференции Agile 2009, Крис МакМахон показал презентацию "История большого проекта автоматизации с помощью Selenium". Он описал подход с использованием тысяч автоматизированных проверок (он называл их "тестами") с целью обнаружить проблемы в приложении с помощью тестирования. Как описать разницу? Опять-таки, различие - это одна из мотиваций. Если вы запускаете тысячи автоматизированных проверок с целью показать, что у вас сегодня все работает, как и вчера, вы проверяете. Хотя, вы можете использовать тысячи автоматизированных проверок другими способами. Если вы пытаетесь ответить на новые вопросы, например "что случится, если мы запустим наши проверки на 30 машинах одновременно, чтобы нагрузить сервер?" (мы выполним стресс-тест), или "что может случиться, если мы запустим все проверки на другой платформе?" (мы выполним тестирование совместимости), или "что будет, если мы запустим автоматизированные проверки 300 раз подряд?" (тестирование последовательности), проверки помогут нам в тестировании (что будет замечательно в этих ситуациях).

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

Майкл Болтон, 29 августа 2009 года.

воскресенье, 1 сентября 2013 г.

Рубрика "ПочитайQA". Полезные ссылки за август-2013

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

Мой август получился рабоче-учебным. Состоялся очередной релиз, довольно плотный по времени и насыщенный новыми интересными багами - отличный материал для будущей рубрики с пилотным названием "Обмен опытом". На данный момент, я закончил группу по веб-тестированию для начинающих, и до декабря беру паузу в преподавании. Мой доклад (правильнее сказать, пока идею доклада и тезисы) по организации времени в тестировании утвержден на Chief Confet&QA - http://confetqa.ru/program-chief/ - так что с удовольствием пообщаюсь с вами на докладе, и после. А сейчас, если у вас есть вопросы по этой теме или пожелания о том, что бы вы хотели услышать, пишите. Не так быстро, как хотелось бы, продвигается мое обучение по программе Mini-MBA, но я поставил себе цель закончить к декабрю.