Как я ездил на Test Labs 2009...


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

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

Ладно, перейдем к делу. В самом начале у меня была проблема: в одно время выступали два человека(Максим и Алексей), попасть на которых мне очень хотелось. Оказалось, что одного доклада не будет и все разрулилось. Первым я пошел на доклад Алексея Баранцева "Во что верят тестировщики?". Заметил, что многие признанные учителя в области плавно переходят из рассказов о конкретных вопросах к общей философии: в качестве примера приведу твиттер у James Marcus Bach - он уже давно философствует о тестировании (и просит спрашивать, если вас волнует что-то конкретно). Так и Алексей решил убедить всех относится более философски к работе тестировщика... Из-за нехватки времени (спасибо задержке на 15 минут открытия конфы) доклад местами получился скомканный, но, надеюсь, у него получилось сказать то, что он хотел. Над этим докладом нужно много думать...


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

Затем подошла очередь выступить мне... Говорил об артефактах тестирования, когда их стоит писать, когда нет. Вопросы по ходу презентации и после порадовали увлеченностью слушателей. Честно говоря, думал, что все заснут на первых порах. Т.к. храпа не было слышно, считаю свою задачу выполненной... :)
Если присланный фидбек будет иметь не низкий результат, обязательно напишу об этом...

Как я писал ранее - обед удался!


Выступление Александра Якимы (надеюсь правильно просклонял его фамилию) в некотором роде подтвердило истинность фразы: в Agile нужно верить. А кубики, об которые я чуть не сломал глаза, отчетливо показали иллюзорность некоторых особенностей гибки методологий. Понравилось, что у него получилось сделать доклад интерактивным - сами участники делали "заранее" запланированные выводы. Здоровский доклад с точки зрения приобретения новой информации.


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

Хотелось послушать Юлию Нечаеву и Александра Александрова, но... надеюсь следующий раз получится.

Ещё отзывы о конференции написали:

Организаторы обещали выложить материалы на сайте конференции.

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

Текст сообщения и комментарии...


5 способов ответить на нечестные вопросы начальства

Автор: Matt Heusser
Перевод: Максим Гриневич

Читая черновик этой статьи, я понял, что хочу перевести её на русский язык и разместить у себя в блоге.
Оригинал статьи от Matt Heusser размещен здесь.
Если вы проработаете в тестировании достаточно времени, то не раз встретите ситуации, когда вам зададут вопросы. Часть из них будет вполне разумными и честными, другая часть – наоборот. В этой статье я помогу вам обнаружить и обезоружить такие вопросы, начиная с самого известного «Почему тестировщики пропустили эту ошибку?»
Около 20 лет назад Tom DeMarco говорил о нечестных вопросах IT в своей статье Why does software cost so much?. Конечно, DeMarco не задает вопросы, он утверждает или предлагает тактику ведения переговоров. Такие вопросы часто так же возникают и в тестировании ПО. Вот мои любимые:
  • «Почему тестировщики не нашли эту ошибку?»
  • «Почему именно тестирование является «узким местом» проекта?»
  • «Почему у нас столько ошибок?»
  • «Что мы можем сделать, чтобы улучшить производительность отдела тестирования?»
  • «Мы уже закончили тестирование?»

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

  • «Тестировщики должны были найти эту ошибку»
  • «Тестирование – слабое место проекта»
  • «У нас слишком много ошибок»
  • «Тестирование занимает слишком много времени»
  • «Тестирование должно быть завершено сейчас.»

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


Доверие и безопасность.

Такие вопросы – это своеобразный трюк или техника. Руководство предполагает, что в ПО слишком много ошибок, и тестировщики несут за это прямую ответственность.
Лучшим ответом на эти вопросы будет занятие позиции, при которой они просто не будут заданы, - предотвратить это можно через обучение и общение. Стоит начать с внесения ясности руководству о том, что будет протестировано, в самом начале проекта. Затем, когда вы найдете ошибку, вы можете сказать: «4 недели назад мы договорились о том, что будет протестировано – за рамки этого я не вышел.» Другой способ – образование: я знаю одного менеджера , который подарил своему начальству в качестве новогоднего подарка копию Perfect Software: And Other Illusions about Testing.
Предупреждение проблем – это хорошая цель, но боюсь, что это не поможет тестировщикам, которым приходится отвечать на такие вопросы прямо сейчас. Итак, моя цель сейчас – обезоружить вопрос, показать что такое осуждение не эффективно и направить команду на путь движения к честности, безопасности и командной работе. Делая это последовательно в итоге можете получить следующую ситуацию. Ваш новый вице президент задает похожий вопрос и тогда кто-нибудь из программистов или Product Managers объясняет ему на сколько данный вопрос нечестен. По крайней мере на это можно надеяться.
Думаю, что теории достаточно. Давайте представим, что вы только что услышали в свой адрес «Почему тестировщики пропустили эту ошибку?». Вот возможные пути ответа:



1. Выбор исходных данных.

Утверждают, что тестировщики должны были найти эту ошибку. Мы можем ответить, что действительно существует заслуживающая внимание причина, почему эта ошибка не была найдена. Далее несколько разъяснений, как я это использовал:
  • Ошибка воображения: Ошибка прошла потому, что никто даже и предположить не мог о её существовании в этом месте . Программист не подумал о такой возможности, ведь именно он создал её. Команда , работающая над созданием требований, не представила возможности появления ошибки в этом месте, ведь иначе они бы написали более явные требования относительно этого места.Мне кажется, что вся команда допустила ошибку в этом месте. Возможно, в будущем,если группа тестирования будет иметь больше времени для обдумывания путей тестирования (кроме обычных действий), они придут к написанию таких сценариев, которые найдут эту ошибку.

Давайте теперь немного поговорим о давлении расписания и как это влияет на фантазию тестировщиков…
  • Успешное управление рисками: хорошо. Одна ошибка смогла пройти незамеченной. Достаточно честно. Теперь давайте поговорим о том, что команда тестировщиков работала на протяжении последних двух недель и при этом они смогли найти 15 блокирующих ошибок, 19 критичных и 54 ошибки с приоритетом Normal. Если мы хотим, чтобы эта область была протестирована, мы должны уделить меньше времени другим областям. Итак, какой из 15 блокирующих тасков вы бы хотели, чтобы мы пропустили, потратив время на эту функциональность?
  • Проблема коммуникации (общения): Мы не можем проверить все возможные комбинации входных данных, поэтому мы вынуждены их сортировать, выбирая более представительные. В данной ситуации мы ошиблись с выбором правильной выборки. Теперь, когда мы знаем о возможны проблемах, мы постараемся уделить больше внимания данной функциональности при тестировании. В будущем, если аналитики, программисты или другие участники проекта будут знать о возможных проблемах, они должны сообщать это команде тестирования.

2. Проблемы исходных данных.

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



3. Ответ вопросом.

Вместо ответа «вот почему мы не нашли эту ошибку», вам стоит ответить своим вопросом. Это меняет вашу роль, вы перестаете быть жертвой, и становитесь... кем-то, кто действительно пытается повысить качество.

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

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

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



4. Направление дискуссии.

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

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



5. Измени тему.

В своей книге Quality Software Management, Volume III Jerry Weinberg говорит, что не подходящее поведение может спасти команду от критики. Он приводит такой пример: «Посмотрите, какой пятнистый кот на крыше. Как он туда попал?» Тяжело критиковать кого-то, когда смотришь на котенка. Но вам стоит знать людей, с которыми разговариваете, ведь часть людей будут задавать эти вопросы раз за разом.

Консультант по командной работе Pollyanna Pixton предлагает другой вариант: Просто откажитесь отвечать на неудобный или нечестный вопрос.

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


«Тряпка» или политик?

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

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

Да, начальник может быть зол. У вас может даже разгореться конфликт. Через пять лет, вы, возможно, будете работать на новой работе. Я предполагаю, что она будет лучше той, где вы работаете сейчас.

Прочитать эту статью на языке оригинала (English) можно на этом сайте.
Узнать больше об авторе заметки можно на professional web page of Matthew Heusser.


Текст сообщения и комментарии...


Лишние знания мешают?

В своем посте "What Makes A Good Software Tester?" Dr. James McCaffrey описывает восемь характеристик настоящего тестировщика. Одной из таких характеристик является: существенные технические данные. Причем, здесь он имеет ввиду, кроме всего прочего, умения/знания программирования:
A great software tester must have significant coding skills in order to understand the system under test, communicate with developers, and write test automation. ...  I believe that a great tester must have at least 7.5-on-a-scale-of-1–10 (applications) development skills.
То, что автоматизатору было бы не плохо быть раньше программистом или иметь хоть какойто опыт написания программ это точно.

Текст сообщения и комментарии...


Мысли по организации тестовых сценариев (test cases)

Прежде, чем забить применить новую концепцию отношения к тестовым сценариям (test cases), описанную в посте А так ли нужны test cases ?, я хотел изменить способ хранения этих самых сценариев описанным ниже образом.
Предлагаю оценить возможность использования данного подхода. Конечно, пока это только теория, но как только у меня будет возможность/ресурсы попытаюсь её воплотить в жизнь.

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

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

Минусы отсутствия твердой структуры с лихвой покрываются возможностью не думать над тем в какую папку засунуть сей документ, когда он с легкостью может быть как в одной папке, так и в другой.
Думаю, что чтото подобное мы можем сделать и с нашими кейсами. Возможно, что полного отказа от типизации и строгости не будет (в базах же присутствуют как типы данных, так и строго заданные таблицы, но непосредственно в файлах все хранится без строгого разграничения)
ЧТО я предлагаю:
------ Требования и организация ---------------
1. Точно определить, что должно быть в полях типа: Module(s), SubModule(s) . Если с остальными всё более менее ясно, то в этих полях каждый тестер пишет то, что ему вздумается. Следующим шагом будет переименование этих полей соответственно тому, что в них будет находится.
2. Добавить поле Feature. Куда для ВСЕХ записей будет записываться фича, которую проверяет данный конкретный кейс. Если кейс точно нельзя определить, как проверяющий конкретную фичу, то там будем писать чтото типа Global или Main. Это поле должно разрешать вписывать несколько значений через запятую(так сейчас у нас хранится инфа о конфигурациях для конкретного кейса).
3. Список  стоит вынести на отдельную страницу и при добавлении новых кейсов для новой фичи, название фичи добавлять в этот список. И там же связывать ещё раз, в каких конфигурациях эта фича МОЖЕТ быть активизирована.
4. Нужно создать дефолтовый документ, куда будут вноситься все дополнения и изменения. А так же пустой документ, но с готовой структурой, сюда должно быть удобно скопировать кейсы из дефолтового дока. 
5. Правильно настроить фильтрацию, возможно понадобится написать пару VBScript'овых макросов.
------- Как этим пользоваться ----------
1. Если нужно проверить конкретную конфигурацию.
1.1. Выделяем с помощью автофильтров необходимые кейсы. Копируем их в пустой приготовленный и производим тестинг. Сохраняем результаты в отдельный файлик.
Или
1.2. После фильтрации создаем новую версию Results for build_version и производим тестинг. На все остальные кейсы, которые не нужно проверять в рамках этого тестирования ставим статус Not required 
2. Если нужно сделать из наших кейсов Acceptance cases. Опять таки фильтруем данные. Можем уже ничего никуда не копировать.
------------------------------------
В чем наша выгода:
1. Нам не нужно напрягаться о порядке дабавления кейсов даже для одной фичи. Фильтрация по имени фичи точно покажет все кейсы, которые её касаются.
2. Страничка с перечислением фич сразу покажет, какие фичи добавлены,  а какие — нет. При этом здесь мы можем попробовать сделать структуру, которая покажет к чему относится конкретная фича.

В этом, ещё не оттестированном подходе много минусов — это я понимаю. Главный вопрос, который меня интересует: будет ли это жить или есть причины, которые видны «не вооруженным» глазом, из-за которых всё сойдет на нет?

Текст сообщения и комментарии...


Теперь домен второго уровня YaTester.ru

С мои блогом произошло несколько изменений:
— блог переехал на новую площадку YaTester.ru  — так что советую изменить ссылки на фиды (конечно старые будут поддерживаться столько времени, сколько нужно)
— появилась почта ваше_имя@yatester.ru, основанная на сервисе google.com . У меня есть ещё порядка 40 - 45 аккаунтов, которые я могу подарить всем желающим. (Можно настроить пересылку сообщений на ваши основные ящики)
Планирую добавить англоязычную версию блога по адресу YaTester.com, но пока это только планы...

Текст сообщения и комментарии...

Из-под пера Maksim Grinevich

Тэги: , , , | 0 ответов, оставьте свой...