October 10, 2012

Сказка о двух ящиках и одной тестировщице

Жила-была маленькая тестировщица, и по неопытности своей считала, что белый ящик - для программистов, а черный - Мекка для тестировщиков.
Но однажды наступил момент, когда ей в Jira подключили FishEye, и она смогла видеть то, каким образом был пофикшен тот или иной баг, или каким образом был заимплеменчен тот или иной функционал. По началу все изменения выглядели как наскальная живопись - было понятно о чем речь лишь по мутным и примитивным очертаниям. Тогда она стянула себе из системы контроля версий репозиторий, и очертания стали больше напоминать то,что они значили, ибо в IDE можно было перемещаться по классам и методам, чтобы понимать, что происходит. И тогда коммиты стали понятней, и несмотря на практику код ревью, принятую в команде, маленькая тестировщица все равно заглядывала в новый код посредством FishEye.
Это привело к тому, что отныне делать impact анализ можно было основываясь не только на словах разработчика и собственных предположениях, но и на том, что она сама видела. И оказалось, что, как правило, изменения затрагивали гораздо больше того, что было сказано разработчиком, и тестов нужно было сделать гораздо больше, чтобы убедиться в правильности имплементации. Чек листы стали более полными, что позволяло отловить больше багов.
А маленькая тестировщица теперь при получении тикета в Jira первым делом открывает вкладку Source и смотрит изменения в файлах, а уж потом приступает к тестированию. А в случае, если на нее ассайнят тикет, где такая вкладка для нее отсутствует, она брезгливо морщится и тяжело вздыхает.

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

но это не имеет никакого смысла до тех пор, пока нет доступа к коду.

October 4, 2012

Lessons learned in SCRUM. Lesson 2 - Add new person to help или "Ой ли?"

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

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

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

August 13, 2012

Lessons learned in SCRUM. Lesson 1 - Commitment или "Не откусывайте больше, чем можете проглотить"

Scrum является довольно новым направлением в моей практике, если говорить о более-менее толковом Scrum, а не его тени.
О некоторых уроках, полученных мной во время работы по этой методологии, я буду писать в блоге.

Итак,
Урок 1 - Commitment или "Не откусывайте больше, чем можете проглотить"

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

Вот статистика работы реальной команды, вернее, только часть статистики. Для удобства столбцы обозначены цифрами 1-7, но это не обозначает номер спринта. Из графика видно, что команда все время "почти" выполняла коммитмент. Ну вот еще чуть - полдня или день - и все бы было красиво и хорошо. Но этих полдня всегда не хватает (кроме 3 столбца, когда сделали все).
 
 После многих спринтов, когда запланированная работа превышала реально сделанную (столбики 1-5), решили-таки коммититься на меньший объем. Результат поразил - в первый такой спринт команда выполнила почти на 5% больше,чем в предыдущий, а на второй - на 10% больше! (столбики 6 и 7) При этом реально потраченное на выполнение задач время практически не изменилось.

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

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

April 19, 2012

Стратоконф: «Использование public clouds для нагрузочного тестирования web-сайтов»

Вот и закончилась первая встреча конференции Стратоконф.
Доклад был посвящен нагрузочному тестированию и назывался он «Использование public clouds для нагрузочного тестирования web-сайтов» (докладчик - Александр Балабанов).
Я редко сталкивалась с нагрузочным тестированием, поэтому тема была мне интересной и довольно новой. Очень порадовала именно практическая направленность - рассказали об инструментах и показали их работу практически в live-режиме (Chief, Tsung, Amazon Cloud). Из демонстрации стало ясно,что нагрузочное тестирование не так страшно, как мне о нем думалось ранее (во всяком случае, когда речь идет о вебе).
И все же чего-то не хватило. Возможно, краткого обзора "поставщиков" клаудов, существующих на сегодняшний день, или объяснения, почему же выбран именно амазон.

April 16, 2012

Не пропустить: Software Testing Virtual Conference от EuroSTAR

16 мая состоится Software Testing Virtual Conference от EuroSTAR. Конференция бесплатная, но требует предварительной регистрации. "Встреча" обещает быть интересной - хорошие темы, мега опытные докладчики... В общем, регистрируемся и ждем 16 мая!
На повестке дня:

Model Driven Development and its Impact on Testing. A Nanotech Case Study with Bryan Bakker, Sioux Embedded Systems B.V.
Bryan discusses how Sioux has developed several projects with a Model Driven Development approach. He talks through the problems they found, and details information they have used for follow-up projects.

Many Ways to Manage Exploratory Testing with James Lyndsay, Workroom Productions Ltd.

This talk will be a swift spin through the pros and cons of typical ways that teams manage exploratory testing. James will dip into some possible alternatives, taking inspiration from machine learning, lean approaches, and from other industries who find value in exploration.


Where (Testing) Ideas Come From with Alan Page, Microsoft
Alan discusses where new test ideas come from, and how anyone can use learning, creativity, pattern recognition and pragmatism to discover and apply new ideas anywhere - especially in software testing.

Thinking Visually in Software Testing with Alan Richardson, Compendium Developments
Alan shares his experience of using models and diagrams to help his test planning and communication of testing. He will cover "Not Thinking Visually" - what this looks like, why it is the norm, and traps your readers will fall into.
А здесь регистрация и более детальная информация о докладчиках.

April 10, 2012

Боевое крещение (Pairwise testing)

Впервые предоставилась возможность использовать pairwise testing в реальных условиях! До этого много читала и безусловно соглашалась с эфективностью этого подхода, однако,шанса все не выпадало. И вот свершилось!
Напомню,что

All-pairs testing"" or pairwise testing is a combinatorial software testing method that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameter pairs. The number of tests is typically O(nm), where n and m are the number of possibilities for each of the two parameters with the most choices.
(c) Wiki

О самом алгоритме подробнее можно прочитать здесь

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

Результаты реально впечатляющие - из 150+ возможных комбинаций (потом надоело считать) было оставлено 14!

January 17, 2012

Re: Testing-by-contract VS defensive testing

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

Testing-by-contract и Defensive testing - это два разных подхода к тестированию. Как и любую методологию, каждый из этих подходов будет эффективен при соблюдении каких-то условий. Соответственно, и какой подход применять, решается для каждого КОНКРЕТНОГО проекта.

1. Что мы знаем о пользователях?

Пример 1.
Многопользовательская система
Ориентировочное количество пользователей - 1000
Характеристика пользователя:
возраст - от 10 и до 55-60 лет
навык владения компьютером - от базового до продвинутого
Личности целевой аудитории: неизвестны

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

Пример 2.
Многопользовательская система
Ориентировочное количество пользователей - 35
Характеристика пользователя:
возраст - от 25 до 45 лет
навык владения компьютером - продвинутый
Личности целевой аудитории: известны - это работники предприятия, которое заказало разработку продукта

Какой подход использовать?
Обговорите с заказчиком,узнайте,чего он хочет. Я бы предлагала ему testing-by-contract, возможно,с некоторыми исключениями. Список исключений можно выяснить при разговоре с представителем будущих пользователей, назовем его бизнес-специалистом. Это человек, который знает о том, для чего предназначена разрабатываемая система и который будет сталкиваться с ней в ежедневной работе.

2. Особенности заказной разработки "для себя"
а) Направленность пользователей на результат
Как правило, когда разработка заказывается "для себя",а не для продажи, то и требования к ней уникальны. Люди бизнеса отлично понимают язык цифр и если им предоставить примерный расчет затрат на тестирование негативных сценариев и их исправление, многие решат сократить их количество. Почему? Потому что некоторые из сценариев не придут в голову тому, кто использует систему не для того,чтобы сломать,а чтобы РАБОТАТЬ с ней и получить от системы то,ЧТО ОНА ДОЛЖНА ВЫПОЛНЯТЬ. Зачем тратить время и умышленно делать разработку продукта дороже, если проверяемые нами сценарии ни разу не будут задействованы при эксплуатации системы? Зачем тратить время на их исправление?
Пример - установка десктопного приложения в папку с максимальным уровнем вложенности для ОС.

Не ставится,выдает непонятное сообщение об ошибке. И что?! Пусть и дальше не ставится, "сам дурак"...

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

в) Прибыль - уже сейчас

Обратите внимание на системы учета чего угодно в государственных учреждениях или маленьких коммерческих структурах. Эти системы тормозят, зависают, могут выдавать некорректные данные или не выдавать вообще, да и выглядят отвратительно,в конце концов. Одним словом - сырые, недоработанные и совсем не user-friendly.
Так почему же их используют? Потому что уже СЕЙЧАС эта система, такая сырая и некрасивая, может приносить прибыль - и ее берут в эксплуатацию, по ходу получаю апдейты и патчи. Заказная разработка стоит дорого, чем раньше она начнет окупаться- тем лучше.

г) Исключения

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


Итог:

Testing-by-contract имеет право на жизнь для заказных систем с известным кругом пользователей. Принятие решения по использованию именно этого подхода должно быть обговорено с заказчиком. Бенефит для заказчика - удешевляет разработку. Бенефит для компании-разработчика - клиент не уходит к другому заказчику, который обещает сделать все тоже самое, но в 3 раза быстрее и дешевле (мы-то знаем,что он просто будет делать только defense testing,иначе эта цель недостижима). В "умелых руках" и при соблюдении должных условий этот подход к тестированию может принести большую пользу. Однако,использовать нужно осторожно, возможно, придется добавить гибкости и все же описать и обработать какие-то негативные сценарии - зависит от контекста (сложность системы, критичность дефектов, пользователи).

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

Гремучая смесь - толковый технический специалист и слабый командный игрок

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

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

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

А в Вашей практике встречались еще какие-то виды такой гремучей смеси?

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

January 10, 2012

Интересный факт - Эффект Даннинга-Крюгера

Некоторые вещи ставит на свои места, о других заставляет задуматься:

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

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


Описание взято с вики.