Lesson 15

А нам буквально через полчаса Наташа Руколь будет рассказать про то как делать Скриптовое тестирование.

Слово Канеру:

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


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

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

Lesson 14

Слово Канеру:

Опасайтесь превращения в группу улучшения процесса.


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

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

Lesson 13

Сегодня я узнал, что несмотря на то, что не все GC одинаково полезны, ничто не будет так хорошо держать ваш hibernate SessionFactory в пределах кучи, как вовремя включенный c3p0.

Слабо провести синтаксический и пунктуационный анализы предыдущего предложения, хех?

Слово Канеру:

Остерегайся "не-моя-работа" теории.


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

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

Lesson 12

Не все GC одинаково полезны. Нашлии в дебрях конфигов несколько SerialGC. Ну и ConcMarkSweepGC тоже убрал. Вымарал тут же. Заменил на ParallelOldGC, как наиболее модный в реалиях нашей тестируемой системы. Завтра днем буду выяснять, зря было все это или нет.

И да, бантики очень идут руководителю разработки.

Альбом: randompics4lj

Слово Канеру:

Никогда не будь вратарем.


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

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

Lesson 11

Сегодня чинил то, что сломано, проверял то, что еще не сломано, понимал то, что не успел понять.

Слово Канеру:

Ты не гарантируешь качество тестированием.


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

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

Lesson 10

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

Слово Канеру:

Опасайтесь "завершения" тестирования.



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

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

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

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

Lesson 9

Сегодня вечером написал пару хороших тестов.

Днем наша ведущая программистка прямо на лекции срывала для нас покровы с OSGi.

А утром посчитал статистику наколбашивания методов в модуль. Почти за два года. Выяснил, что я - это примерно два стажера. Или две трети опытного сотрудника.


Слово Канеру:

Ты никогда не найдешь все баги продукта.


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

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

Lesson 8

В этот раз получилось особенно ужасно, да...

Слово Канеру:

Фокусируйся на сбоях, как твои клиенты фокусируются на успехе.




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

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

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

Lesson 7

Еще день прошел. Написал один тест. Зато хороший.

А еще интернет подключили, сегодня буду делать из ноутбука раздавалку вайфая для телефона.

Слово Канеру:

Спрашивай постоянно, но не обязательно вслух.



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

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

Lesson 6

Слово Канеру:

Работай вместе с программистами.




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

Lesson 5

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

И, хотя у новых читателей не возникает вопросов о том, что за Канер перманентно появляется у меня последнее время, я все равно отвечу.

Потому что ответы без вопросов это все же лучше, чем вопросы без ответов.

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

Теперь книжка есть у меня на столе. В мае 2009 перевода не было, и сейчас нет. Если найдете - сообщите, я перестану переводить. Хм. Или не сообщайте.

На амазоне она стоит триста ре, а на озоне почему-то две тыщи...

Кстати, не я один озаботился попытками ее перевести. Вот тут тоже пытались, их хватило аж на 15 заметок! У меня уже 14 (вместе с прошлыми), их я обгоню точно. Но у них перевод получше, да.

А этих ребят хватило всего на 11 уроков. Качество перевода тоже повыше моего. С октября 2008 по январь 2009. Их там аж четверо, кстати, бложик жив все еще.



Картинка для привлечения внимания:

Альбом: cat

Ах да, сегодня починил семь тестов.

А теперь слово Канеру:

Находи критичные баги быстро.


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

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

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

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

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

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

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

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

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

Lesson 4

Слово Канеру:

То, что ты обнаружил, может быть "багом" по мнению других людей.



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

Lesson 3

Сегодня починил две баги. Или три.
На урале то солнце, то дожди.

Менеджеры провайдера Convex, которым я написал вчера, уже сегодня связались со мной и пообещали выслать монтажников прямо днем.
Монтажники тоже связались со мной, сообщили, что чердак закрыт и они будут только в пятницу. В принципе, нормально.
Внимательно следим за развитием событий и моими отзывами. Конвекс, у меня в уютененьком тысяча уников ;)


Кстати, на тему следующего lesson я как то делал 20-минутный доклад для тестировщиков на нашем демо. У меня было смешнее, у Сэма полнее.

Слово Канеру:

Ты служишь многим клиентам.


Тестирование - это сервис. Прочувствуйте это. Сервис, который ты предоставляешь жизненно важен. Сервис подразумевает наличие клиентов - людей, которым ты служишь. Твой успех измеряется в первую очередь тем, насколько удовлетворены желания и интересы клиентов. Это может не быть трудным, зависит от количества клиентов. Каждый из них имеет свои потребности, но суммарно они сводятся к необходимым:

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

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

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

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

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

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

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

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

Lesson 2

А я сегодня написал 5 тестов.

Дальше Канер:

Твои цели управляют тем, что ты делаешь.


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

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

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

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

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

Что вы должны делать, когда вы не знаете, что делать? Один вопрос укажет вашу цель. Он идентифицирует суть проблемы, которую вы имеете. Если у вас нет цели тестирования, вы могли бы определить конкретно, что вы будете делать дальше. Также можно объяснить вашу роль окружающим простыми словами. Если вы не можете понять свою цель по каким-то причинам, обсудите этот вопрос с менеджментом сразу.


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

Lesson 1

Контора доставляет в офис книги же!

Альбом: office

Ты "свет фар" проекта.

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

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