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

Предлагаю рассмотреть второй вариант. Что нам для этого нужно? Я составила свод из 12 базовых правил, позволяющих в разы повысить успешность проводимых собеседований. Вам остаётся только проверить, правда ли это действует Отзывы о результатах можете высылать на natalya@quality-lab.ru – обсудим, что было сделано правильно и что ещё можно улучшить!

Правило 1. Не ищите несуществующее. Да, да, да! Все тест-менеджеры хотят найти опытного, целеустремлённого и технически грамотного специалиста, да ещё и в бюджет до 30 тысяч рублей. И Вы хотите? Проснитесь! Это невозможно. Хорошие специалисты зарабатывают хорошо. У Вас есть ограничения по финансам? Заранее продумайте, чем Вы жертвовать готовы, а чем – нет.
Почему это важно? Потому что иначе Вы будете принимать решение в последний момент, понимая, что желаемого специалиста найти не удалось. И вероятность ошибиться, спутав желаемое с показавшимся, будет значительно выше 50%. Через пару месяцев неуспешной работы Вы будете корить своего биг-босса за то, что он не выделил достаточно ресурсов. Хотя на самом деле Вы просто неэффективно их использовали.
Решение: Заранее выпишите все важные требования к кандидату. Сверьтесь с рынком – возможно ли найти такого специалиста? Если невозможно – заранее сузьте требования, не оставляйте это «на потом».

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

Правило 3. Не забывайте, что знания и опыт – это далеко не всё! В ИТ-мире это распространённая ошибка. Вы ищете сотрудника, имеющего опыт в создании тест-кейзов, и хорошо знающего Linux? Вы его нашли? Замечательно! Но если Вы оценивали только знания – не удивляйтесь, если он будет каждый день опаздывать, не сможет общаться с коллегами или попросту уволится через три месяца. Люди – не машины! Человеческий фактор никто не отменял.
Почему это важно? Потому что Вы ищете не софт, который может решать определённый функционал. Вы ищете сотрудника, который должен хорошо вписаться в коллектив и которому у Вас будет комфортно работать.
Решение: определите, какими личностными компетенциями должен обладать сотрудник, чтобы эффективно работать в Вашем коллективе. Придётся ли ему коммуницировать с другими участниками процесса, или он будет работать в одиночестве? Ему будут ставиться строго очерченные задачи, или уровень ответственности будет размыт? Насколько важна дисциплина в Вашем коллективе? Он будет работать в стрессовых условиях? В конце концов, решите для себя честно – диктатор Вы или демократ по стилю управления. Все вышеперечисленные вопросы влияют на то, какой сотрудник Вам нужен!

Правило 4. Не зацикливайтесь на том, что нужно Вам. Думайте и о требованиях сотрудника!
Почему это важно? Допустим, Вы нашли сотрудника, у которого идеально соответствуют Вашим требованиям и знания, и опыт, и личностные компетенции. Он готов протестить всё на свете! Приходит к Вам на работу, усердно изучает продукт, и… в лучшем случае – результата ноль. В худшем – он увольняется. Почему? Потому что он Вам подходит, а вот Вы ему – нет. Перед приёмом сотрудника на работу Вам надо знать, что его мотивирует. У Вас вялотекущий проект на шесть лет, а к Вам приходит карьерист, желающий стать за год мега-боссом? Или он хочет всё время развиваться и получать новую информацию, а у Вас нет задач кроме запуска рутинных тест-кейзов? Или, наоборот, он ищет оазис спокойствия от гроз и бурь, а Вы бросаете его на стрессовую позицию?
Решение: определите, какие типы мотивации Вам доступны. От премий до карьерного роста, от новых задач до шоколадок, от ответственности до публичной похвалы. Ваш арсенал шире, чем кажется Составили список? Определите, интересует ли это Вашего соискателя. Он не всегда знает, что Вы готовы ему предложить. Оцените, сможете ли Вы дать ему то, что нужно. И не надейтесь на чудо: если Вам нечего ему предложить – то есть смысл отказаться от самого потрясающего сотрудника. Вы же не хотите делать кого-то несчастным?

Правило 5. Забудьте о себе. Хотя бы на час Тот час, который Вы проводите собеседование. Мозг человека устроен таким образом, что мы судим всех по себе. И видим в других людях то, что есть в нас. Побудьте бесстрастным, иначе все усилия будут насмарку.
Почему это важно? К примеру, Вы не просто нашли подходящего сотрудника, Вы ещё и уверены в том, что Вы ему тоже подходите и ему у Вас будет хорошо. Он выходит на работу. А результата всё равно нет. Где ошибка? В нас. То есть в Вас. То есть в менеджере, проводящем собеседование! Зачастую, особенно новички, не готовы признать чего-то такого, чего нет в них самих. И если Вы карьерист и стремитесь занять высокую позицию, то слова соискателя «я не хочу быть руководителем» Вы воспримете не иначе как ложь… А зря Он – не Вы. Мне очень долго не верилось, что есть сотрудники, обожающие рутину. Но моё неверие не смогло изменить этот мир. Они есть! И слава Богу за это!
Решение: будьте внимательнее, и оценивайте каждый свой вывод про сотрудника. Просто тестируйте себя вопросом «Не потому ли я так решил, что это про меня?». Сразу успехов не ждите Но со временем – я в Вас верю!

Правило 6. Подготовьте вопросы к собеседованию. Чуть ниже я расскажу, какие вопросы бывают и когда они нужны. А пока что просто советую – подготовьте их заранее. Запишите на бумажку, как шпаргалку для экзамена. Тогда у Вас будет значительно меньше шансов провалить собеседование
Почему это важно? Проведение собеседования – искусство. Никто не начинал рисовать картины «с нуля» – всем нам нужна для начала практика. Если у Вас будут готовые вопросы, Вы сможете провести собеседование результативнее. На этом совете 90% читателей должны зевнуть и решить перейти к следующему совету. Ну и зря! Проверьте, может быть, совет не так уж и плох?

Правило 7. Задавайте открытые вопросы. Недавно я была на собеседовании в крупной ИТ-компании. Собеседование проводила руководитель отдела по подбору персонала. И задавала мне вопросы, не оставляющие даже шанса ответить «неверно»: «Вы любите изучать новое?», «Вы не боитесь стрессовой работы?», «Вы готовы много коммуницировать на английском?», «Вы любите ответственность?», «Вы готовы принимать срочные, важные решения?». Как Вы думаете, я могла ответить что-то, кроме «Да, конечно!»? Нет! Мне не было оставлено и шанса. Не мудрено, что по результатам собеседования мне сказали, что я идеальный кандидат. Более того – не удивлюсь, если у этого менеджера все кандидаты на собеседовании оказываются идеальными!
Почему это важно? Банально, но факт: все соискатели ходят на собеседование для того, чтобы получить работу. Никто не ходит на них ради интереса Следовательно, все хотят понравиться. Или почти все? Такими вопросами Вы сразу даёте понять, какой ответ понравится. А зря Надо быть хитрее!
Решение: задавайте открытые вопросы. Открытыми называются вопросы, на которые нет определённого формата ответа. Пусть соискатель ответит так, как ему удобнее. Вы получите массу полезной информации! Спросите, что человеку больше всего нравится в работе, а что – не нравится. Так Вы получите более реалистичный ответ.

Правило 8. Уделяйте меньше внимания теории, больше – практике. Вам правда важно, знает ли Ваш сотрудник, что такое «эффект пестицида», если он не понимает, как эту информацию использовать в работе? Возможно, термин «чёрный ящик» важнее способности структурировать информацию и находить ошибки? Хм. Не верю
Почему это важно? Потому, что теоретиков много, а хороших специалистов мало. Я подумываю создать «словарь тестера для собеседования». 30 терминов – и хорошая зарплата обеспечена Но не у таких мудрых менеджеров, как мы с Вами.
Решение: задавайте вопросы об использовании информации, а не о теории. Спросите у человека, как обойти эффект пестицида. Спросите, в чём недостатки использования чёрного ящика и как их компенсировать. Попросите написать вариант тест-кейза. Баг-репорта? Узнайте его мнение, как правильно тестировать при недостатке документации. Узнайте, как он работает – а не что он знает! Вы же его берёте не для создания словаря, а для тестирования?

Правило 9. Следите не только за тем, что говорит человек – но и за тем, как он это говорит! Сейчас пойдёт немного теории, приготовьтесь записывать. Любые слова несут в себе так называемые номинативную и коннотативную части. Номинативная – это факт. Коннотативная – это отношение автора к собственному высказыванию. К примеру, фраза «Мне приходилось прогонять тест-кейзы» состоит из номинативной части (сотрудник выполнял тест-кейзы) и коннотативной (он это дело явно не любил, судя по слову «приходилось»).
Почему это важно? Представьте, что Вы ищете сотрудника на ручное выполнение рутинных кейзов. И соискатель это знает. Поэтому на вопрос «что Вы больше всего любили делать на последнем месте работы?» он может ответить про прогон тестов… которые на самом деле он не любил. И ответит он «Мне приходилось…». Если Вы не заметите коннотацию, то можете решить, что сотрудник Вам подходит. Но потом не удивляйтесь!
Решение: следите за такими словами, как «приходилось»(-), «было необходимо»(-), «к сожалению»(-), «из-за»(-), «была возможность»(+), «получалось»(+), «результат»(+), «к счастью»(+) и т.д. Очень быстро Вы составите свой собственный словарь. Плюсов тут аж целых два: Вы не только сможете лучше понимать людей, Вам ещё будет и интереснее проводить собеседования! Почувствуете себя как минимум частным детективом

Правило 10. Тестируйте чашки! Или ложки! Или калькуляторы, лифты, джинсы и даже сигареты. Дайте соискателю задание – и посмотрите, как он будет отвечать. Не мешайте ему с подсказками, он и так знает что Вы начальник. Главное – внимательно следите за ходом его мысли!
Почему это важно? Потому что тестировщики нужны для того, чтобы тестировать. Именно эту способность Вам важнее всего оценить.
Решение: дайте кандидату любое тестовое задание, но не акцентируйтесь на количестве ответов. Посмотрите за ходом мысли. Умеет ли специалист использовать все те виды тестирования, о которых рассказывал в теоретической части – или не догадается проверить лифт на перформанс? Умеет ли он приоритезировать тесты, или начнёт тестирование калькулятора с деления на ноль? Выделит ли он классы эквивалентности, или будет кататься на лифте с каждого этажа на каждый этаж, мешая соседям спать?

Правило 11. Записывайте результаты собеседования. Да-да, опять бумажки, опять хочется зевнуть Но в противном случае у Вас есть шанс забыть всё на свете, особенно если соискатель вызвал у Вас личностную реакцию – негативную или позитивную. Я могла бы не говорить про бумажки и просто посоветовать быть объективнее – но без бумажек это сложновато…
Почему это важно? Потому что когда Вы прочитали про объективность, то явно решили «это не про меня». Поэтому и важно

Правило 12. Если Вы соискатель – то лучше не пытайтесь использовать эти советы чтобы лучше пройти собеседование.
Почему это важно? Потому что Вам не нужна работа, на которой Вы не нужны или которая Вам не понравится. Звучит банально, но на собеседовании эффективнее быть искренним

Итак, вот он, максимально короткий свод правил о том, как успешно проводить собеседования тестировщиков. Прошу заметить, что приведённая здесь информация – не «сферические кони в вакууме». Это Практика. Возможно, что-то из написанного Вам не понравится, вызовет скепсис, покажется излишним. Попробуйте! Только тогда Вы сможете решить, что Вам нравится, а что – нет. Если будут вопросы – обращайтесь, обязательно постараюсь помочь. И, пожалуйста, ленитесь! Но делайте это эффективно!

Использование подобных средств, как правило, не окупается на небольших ИТ системах для которых не критично отсутствие некоторого функционала ввиду его неработоспособности вследствие ошибок допущенных при доработке системы. Однако на больших ИТ системах с интенсивными темпами разработки и большим количеством связей между объектами использование подобного механизма автоматического тестирования просто необходимо. Использование Rational Robot позволяет не только уменьшить людские ресурсы на тестирование, но и качественно выйти на другой уровень конечному продукту разработки с точки зрения его работоспособности и надежности.

Рассмотрим использование Rational Robot на простом примере.

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

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

Если Константа.Ошибка = 1 Тогда
Д=СоздатьОбъект(«вв»);
КонецЕсли;

С начала запишем текст скрипта в Rational Robot. Для этого необходимо инициализировать запись скрипта и после чего выполнить все действия с документами. В моем случае, я вводил новый документ вводил в нем необходимые реквизиты, записывал его и после чего считал тест выполненным и прерывал запись скрипта. Результат теста Rational Robot записывает в виде скрипта на SQABasic:

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

Соответственно, после того как мы записали скрипт теста, мы можем его использовать в системе автоматического тестирования. Rational Robot будет последовательно исполнять записанные ранее нами команды, и в зависимости от успешности их исполнения заносить результаты в отчет. Логика успешности определяется тестировщиком. Например, если при нажатии на кнопку «Новый» форма документа открывается – значит эта часть теста прошла удачно а если нет то в отчет записывается информация что тест не пройден. Логика обработки результатов может быть существенно более сложная, чем в приведенном выше примере.

Итак, после того как я записал тест запускаю его на воспроизведение при установленной константе Ошибка = 0. В этом случае Rational Robot выполняет последовательность действий и выдает отчет об успешном выполнении теста (забавно смотреть как кнопки сами нажимаются и вводится информация в соответствующие контролы).

В случае если мы установим константу Ошибка в значение 1 и запустим тест – то отчет будет другим:

В данном отчете мы можем просмотреть все ошибки в удобном интерфейсе. Так же при возникновении ошибки снимается скриншот экрана (настривается) с ошибкой которую прямо из отчета можно просмотреть.

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

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

Тестировать можно не только на предмет ошибок, но и на предмет производительности системы. И действительно, когда пользователь говорит что «у меня документ скролинг экранной формы тормозит» или «поиск отрабатывает долго» – проверить анализируя трэйсы SQL(к тому же верия 1С может быть вообще DBF) довольно сложно. С помощью Rational Robot можно настроить автоматические тесты которые будут писать в файл показания счетчиков. Анализируя потом этот файл можно проводить подробный анализ системы с точки зрения реакции системы на то или иное действие пользователя.

Кроме этого через Rational Robot можно настроить запись трассы по ODBC или по другим протоколам.

Куки — кто они?

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

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

Пожалуй, стоит пояснить, что подразумевается под борьбой с недостатками HTTP-протокола. Дело в том, что этот протокол не умеет сохранять своего состояния, т.е. пользуясь средствами одного лишь HTTP у вас никогда не получится отследить взаимосвязь между парами «запрос-ответ». На практике это означает следующее — например, на вашем сайте существуют три страницы page1.htm, page2.htm и page3.htm, на сайт приходят два пользователя, один из которых сначала просматривает страницу page1.htm, а второй page3.htm, затем оба переходят на страницу page2.htm, так вот, в этом случае никакой разницы между запросами первого и второго пользователя на получение этой страницы не будет, т.е. веб сервер не сможет узнать, какие страницы посещали пользователи до того, как собрались перейти на страницу page2.htm.

Вторая проблема при использовании HTTP заключается в том, что для каждого запроса протокол устанавливает новую TCP-сессию, а завершив цикл «запрос-ответ» сразу же ее закрывает. Это значительно усложняет идентификацию пользователя, поскольку лишает возможности реализовать аутентификацию средствами самого протокола (HTTP-аутентификацию в расчет не берем, т.к. она требует пересылки учетных данных при каждом обращении к серверу). Справедливости ради, отмечу, что в HTTP1.1 была реализована возможность осуществлять несколько запросов в рамках одной TCP-сессии, но… это совершенно другая история…

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

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

Короче говоря, в реальной жизни это выглядит приблизительно так:

Где и как хранить куки (и хранить ли их вообще) определяет, непосредственно, клиентское ПО (чаще всего браузер). Время, на протяжении которого куки будут хранится в клиентском ПО, может варьироваться, и задается для каждой куки отдельно. Исходя из времени хранения, куки делятся на сессионные (те которые будут удалены сразу после закрытия сессии между браузером и сервером) и постоянные (те которые будут удалены после даты определенной в поле Expires).

Передача куки от серверного ПО к клиентскому осуществляется в HTTP-запросе, путем добавления в него поля Set-Cookie, в обратном направлении куки пересылаются в поле Cookie.

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

Куки — зачем они?

Что же можно делать при помощи куки? На самом деле, множество вещей без которых трудно представить современный веб, а именно:

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

2. Персонализация
Часто веб сайты позволяют пользователям изменять некоторые параметры отображения страниц, например, цветовое оформление либо язык интерфейса. Опять же, вполне привычная вещь, если бы не одно но, некоторые веб сайты позволяют делать это даже неаутентифицированным пользователям. Где же хранятся эти настройки? Правильно — в куки. В качестве примера, взгляните на всеми любимый/нелюбимый Вконтакте. Попробуйте сменить язык на странице регистрации, а после закрыть окно браузера и снова открыть эту же страницу. Как ни странно, язык останется тем же, что вы выбрали перед тем как закрыть браузер, а все это благодаря куки под названием remixlang, содержащей код выбранного вами языка.

3. Сбор статистики
Вполне естественно, что каждый владелец веб сайта желает знать кто, когда, зачем и почему посещал его ресурс. И еще более естественно, что это желание веб мастеров нашло свою реализацию в десятках и сотнях сервисов интернет-статистики. И, конечно же, работа этих сервисов была бы невозможна без куки. Почему? Да потому, что без использования куки они были бы, мягко говоря, бесполезны, ведь в этом случае предоставляемая ими информация ограничивалась бы списком IP адресов со временем посещения, полем referer и данными о пользовательском окружении (ОС, браузер и т.п.). Практическая польза от такого рода статистики стремится к нулю, тем более, что количество уникальных посещений веб мастера в состоянии посчитать и сами, не прибегая к посторонней помощи. Об этом знают и создатели подобных сервисов, и потому бессовестно захламляют ваш браузер множеством различных куки, которые впоследствии позволят ответить на вопросы, так интересующие владельцев сайтов: «Кто приходил?», «Зачем приходил?», «Через сколько вернулся?», «Сколько времени провел?», «Что еще посещал?». Не верите, что за вами наблюдают всего лишь с помощью куки? Тогда обновите страницу

Ты был на этой странице уже 3 раза

4. Интернет-маркетинг
Помимо того, что куки используются для сбора статистики, они еще и успешно применяются для извлечения прибыли из этой же статистики. Взгляните, на Яндекс-Директ, Google AdSense или любой другой рекламный сервис. Наверняка, вы без труда найдете взаимосвязь показываемых вам объявлений не только с тематикой сайта на котором вы сейчас находитесь, но и с тематиками сайтов которые вы посещали ранее и даже с поисковыми запросами введенными ранее в Yandex или Google. Такой таргетинг, опять же, обязан своим существованием куки, ведь именно куки записанные в ваш браузер позволяют рекламной сети выбирать тематику объявлений, которая потенциально может быть интересна именно вам.

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

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

Куки — что тестировать?

1.Убедитесь, что в куки не хранится конфиденциальная информация
В идеальном случае конфиденциальных данных в куки быть не должно. Почему? Да потому, что никакого встроенного механизма защиты в куки нет, и, при необходимости, к ним сможет получить доступ кто угодно. Если же у вас нет выбора и в куки приходится хранить подобные данные, то убедитесь, что они не хранятся в открытом виде и, что применяемое шифрование, на самом деле, не является чем-то вроде энкода в Base64.

2. Проверьте количество используемых куки
Четкого ответа на вопрос о том, сколько должно быть куки — нет. Нельзя сказать, что 10 куки — хорошо, а 12 — плохо. Здесь, скорее, нужно руководствоваться принципом — чем меньше тем лучше. Малое количество куки сможет уберечь от нервного срыва многих корпоративных пользователей либо обычных параноиков, у которых в браузере включена опция «Ask me before accepting cookies». Также не стоит забывать, что количество принимаемых браузером куки тоже не бесконечно. Для большинства современных браузеров данная цифра колеблется в районе 50 штук для одного домена. Кстати, если в вашем проекте, количество куки начало приближаться к этой отметке, то… вы явно что-то делаете не так.

3. Убедитесь, что приложение сохраняет свою работоспособность при отключенном либо выборочном приеме куки
Если приложение активно использует куки, то, скорее всего, оно не будет функционировать должным образом, в случае если их прием будет отключен в браузере. Но, в то же время, его поведение должно оставаться адекватным, т.е. приложение не должно сыпать эксепшенами и извергать различного рода Server Error’ы, вместо этого оно должно ненавязчиво предлагать пользователю включить прием куки. То же самое касается и выборочного приема куки. Для того, чтобы принимать куки выборочно, просто включите в своем браузере опцию «Спрашивать меня перед тем как принимать куки» и попробуйте принять, например, только половину из всех куки отправляемых сайтом.

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

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

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

7. Проверьте, что куки корректно работают во всех браузерах с которыми будет использоваться приложение
Все уже давно привыкли к кроссбраузерному тестированию, поскольку знают, что у каждого браузера свой норов, и потому поведение приложение может разниться от браузера к браузеру. Но, казалось бы, при чем здесь куки? Вроде бы, все современные браузеры декларируют поддержку DOM1 и предоставляют практически одинаковый механизм доступа к куки. Но, тем не менее, проблемы возможны и здесь, например, в случае если куки устанавливаются/читаются при помощи JavaScript (о кроссбраузерности JS-скриптов, надеюсь, рассказывать не нужно ), либо сам браузер имеет свои собственные бзики по этому поводу, к примеру, такие либо эдакие.

8. Проверьте, что доступ к различным частям приложения не может быть осуществлен в обход куки, используемых для аутентификации либо авторизации
Некоторые веб сайты передают идентификаторы пользователей в открытом виде, например, в URL. Естественно, что при подмене этих идентификаторов, не должно быть возможности получения доступа к аккаунтам других пользователей. Чтобы было понятнее о чем идет речь, попробуйте залогиниться и перейти на страницу редактирования своего профиля на этом сайте, после чего попробуйте заменить ваш UserID, указанный в URL на любой другой (например, попробуйте отредактировать вот этот профиль http://iqa.com.ua/user/16/edit).

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

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

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

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

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

К сожалению, это не наш мир. Нас постоянно мучают вопросы «сколько осталось до завершения?», «какие задачи не выполнены?». Это проблема, которую будут решать тестировщики 21-го века.

Архитекторы и разработчики уже занимаются ей. Visual Studio содержит большое количество схем и визуализаций – от диаграмм последовательностей до графов зависимостей. Тестировщики тоже уже решают эту проблему. Внутри стен «империи» уже существуют системы визуализации для просмотра изменений кода в Xbox (объекты, код которых изменился, при рендеринге подсвечиваются зеленым, а после тестирования подсветка исчезает), для определения недостаточно тщательно протестированных сложных участков кода Windows (тепловые карты, показывающие соотношение покрытия кода и сложности кода, выполненные в трехмерном пространстве, позволяют обнаружить проблемные области). Эти визуализации выглядят впечатляюще, они красивы и позволяют тестировщикам с одного взгляда определить, что именно нуждается в тестировании.

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

Эта задача может быть решена в ближайшем будущем, и над ней работает много умных людей.

Это тестирование программ в ярких красках.

6. Культура тестирования

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

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

— Джеймс, – ( надо же, он моё имя знал!) – я вижу, что у Вас есть какие-то сомнения относительно моего проекта или продукта, про который я рассказывал. Я хотел бы услышать Ваше мнение.

— Нет, никаких проблем ни с Вашим продуктом, ни с проектом. Мои сомнения касаются Вас.

— Простите?

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

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

Но это совершенно не то, что нужно.

Привлечь тестировщика к проектированию продукта лучше, чем не делать этого вообще. Но не сильно лучше. Тестировщики будут обращать основное внимание на вопросы тестопригодности. Разработчики на возможность реализации. А кто учитывать оба аспекта? Кто будет решать, кто прав, и когда нужно идти на компромисс? Никто. Привлечение тестировщика к проектированию дает лишь незначительное улучшение; привлечение проектировщиков (и всех остальных участников) к тестированию – вот будущее.

Серьёзно, ну почему люди, которые создают программы, так мало смыслят в тестировании? И почему мы не делали попыток это изменить? Может быть мы, тестировщики, слишком укоренились в своей роли и теперь ревностно охраняем ключи от нашего интеллектуального царства? Неужели тестирование настолько полно тайн и загадок, что разработчики не могут его постигнуть? А может быть разработчики привыкли сваливать эту «не очень-то интересную» часть работы на нас и воспринимают теперь это как должное?

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

Нынешняя культура тестирования и разделение ролей порочны, и правильный путь – в объединении ролей. Качество должно быть работой каждого. Думайте об этом в терминах Толкиена: одна роль, чтоб править всеми!

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

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

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

7. Тестировщики в роли дизайнеров

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

Но всё меняется, и это тоже скоро изменится, потому что это должно измениться. Мой друг Роджер Шерман (первый корпоративный директор по тестированию в Microsoft) описывает это изменение, сравнивая тестирование с гусеницей, которая становится бабочкой. По словам Роджера, бабочка, которая должна получиться из тестирования – это дизайн.

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

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

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

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

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

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

8. Тестирование после релиза

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

Я был в группе Windows, когда выпускалась Vista, и вспоминаю, как показывал ее как-то вечером дома своему тогда восьмилетнему сыну. Он много играет (и работает, если вы можете в это поверить) на компьютере, и ему очень понравился интерфейс Aero, симпатичные гаджеты на боковой панели, а скорость, с которой работали его любимые игры (в то время это были Line Rider и Zoo Tycoon), по-настоящему его впечатлила. Я еще подумал: «Как жаль, что он не ведет отраслевой блог», но я отвлекся от темы.

Так вот, в конце он задал мне вопрос, внушающий страх каждому тестировщику: «Папа, а что здесь сделал ты?»

Я замолчал, что довольно необычно для меня, и пробормотал что-то невразумительное. Как вы объясните восьмилетнему ребенку, что вы работали над чем-то несколько месяцев (я только начал работу в Microsoft и присоединился к работе над Vista в самом конце), но фактически ничего не сделали? Я попытался обойтись стандартными ответами на этот страшный вопрос (восклицательные знаки обязательны, они помогают мне убедить себя, что в моих словах есть доля правды):

«Я работал над тем, чтобы сделать ее лучше!»

«То, что она работает так, как она работает… это благодаря мне!»

«Если бы не мы, тестировщики, она была бы угрозой для общества!»

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

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

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

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

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

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

Чтобы достигнуть таких возможностей, приложение должно сохранять данные предварительного тестирования и всегда иметь их при себе. А это означает, что возможность самотестирования станет одной из основных особенностей программного обеспечения будущего. Наша работа будет заключаться в том, чтобы найти способ включения нашей «магии» тестирования внутрь самого продукта. А нашей наградой будет радость от того, как сияют глаза наших детей, когда они увидят, что самая первоклассная особенность продукта — та, которую мы спроектировали!

Ах да, насчет хакеров и поборников конфиденциальности: не бойтесь! Хью Томпсон и я уже давно предупреждали о включении тестового кода в поставку (см. главу Атака №10 в книге «Как взломать программную защиту»). Поскольку мы знаем, как осуществить взлом, мы имеем шансы сделать всё правильно.
Заключение

Коллеги, даже если вы не согласитесь с идеями, высказанными Джеймсом – задумайтесь о том, что будет с тестированием не через год, не через два, а через полвека. Начинать строить это будущее нужно уже сейчас. И строить его будем мы с вами, поэтому оно будет таким, каким мы его сделаем.

1. «Тестсорсинг»

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

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

Роль поставщиков во времена внутреннего тестирования ограничивалась предоставлением инструментов, которые помогали компаниям выполнять тестирование собственными силами. Однако вскоре роль поставщиков изменилась, поскольку возник спрос не только на инструменты. Вместо того, чтобы предоставлять инструменты для внутреннего тестирования, появились поставщики, готовые выполнять само тестирование. Мы называем это «аутсорсингом», и это до сих пор является основной схемой, используемой производителями программного обеспечения для организации тестирования: передать работы по тестированию подрядчику.

Таким образом, первые два поколения тестирования выглядят следующим образом: Поколение Роль поставщика
№1 Внутреннее тестирование Предоставляют инструменты
№2 Аутсорсинг Предоставляют услуги по тестированию (это включает использование инструментов)

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

Это даёт нам третье поколение:№3 Краудсорсинг Предоставляют тестировщиков (это включает тестирование и использование инструментов)

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

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

2. Виртуализация

Для того, чтобы тестсорсинг смог появиться, должны быть преодолены два ключевых технологических барьера: повторное использование тестовых артефактов и доступность пользовательских окружений. Позвольте мне объяснить, что это такое:

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

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

Ответом на обе этих потребности может стать виртуализация, которая быстро становится всё дешевле, быстрее и мощнее и постепенно расширяет спектр областей применения от использования в тестовой лаборатории до развёртывания IT-инфраструктуры.

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

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

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

Рынок также на стороне краудсорсинговой модели, снабжённой средствами виртуализации. Пользовательские окружения приобретут рыночную ценность, когда тестировщики из «толпы» будут стремиться заполучить их, чтобы обеспечить себе конкурентное преимущество. Это будет стимулировать пользователей нажимать заветную кнопку, которая виртуализирует их окружение и предоставит к нему доступ (конечно, у этой модели есть правовые аспекты, но они разрешимы). И поскольку окружения с потенциально возможными проблемами будут цениться выше, чем стабильно работающие, это будет приятным моментом для пользователей, у которых возникают проблемы в работе драйверов или приложений – созданные ими виртуальные машины будут цениться выше, это послужит им компенсацией. С другой стороны, это будет стимулировать тестировщиков предоставлять доступ к своим тестовым наборам и делать их как можно более пригодными для повторного использования. Всё это будет способствовать насыщению рынка тестовыми артефактами, и ключом к этому является виртуализация.

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

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

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

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

3. Информация

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

Какую информацию мы используем, когда тестируем программы? Спецификации? Руководство пользователя? Предыдущие (или конкурирующие) версии? Исходный код? Анализ сетевых протоколов? Мониторинг процессов? Помогает ли эта информация и насколько легко ее использовать?

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

Отличную идею, как представить информацию для тестирования, я нашел в видео играх. В играх мы очень близко подошли к совершенству в способах предоставления и использования информации. Чем больше информации об игре, игроках, препятствиях, окружении – тем лучше вы играете и можете достигнуть более высоких результатов. В видео играх эта информация выводится на специальную информационную панель, называемую HUD, или head up display. Вся информация об оружии, здоровье и возможностях игрока видна и доступна для мгновенного использования. Точно так же доступна информация о текущем местоположении игрока в виде мини-карты и информация об оппонентах (мой сын играл в Pokémon, в котором имелся доступа к Pokédex, где можно было получить информацию о всех видах покемонов, существующих в игре… Я бы хотел иметь такой Bug-é-dex, содержащий информацию обо всех багах, которые могут мне встретиться). Идея очень проста: чем больше информации ты можешь получить и использовать, тем выше шансы на успех в игре.

Я бы очень хотел добиться того же для тестировщиков: дать им больше информации, чтобы увеличить успешность их работы. Но большая часть тестирования в мире завязла в чёрном ящике без хорошей информационной инфраструктуры. Где же наша мини-карта, которая показывает, что мы тестируем сейчас и как это связано со всей системой. Было бы здорово, если бы я мог навести курсор на элемент пользовательского интерфейса и увидеть исходный код или список свойств, реализованных в этом элементе (и которые я могу протестировать)? Если я тестирую API, то почему я не могу увидеть список комбинаций параметров, которые я и мои товарищи уже проверили? Мне нужно получать эту информацию оперативно, в лаконичной и удобной для восприятия форме, помогающей мне тестировать, вместо того, чтобы бродить в поисках нужной информации по сайту, сделанному в SharePoint, или по базе данных, полной несвязанных друг с другом проектных документов. Это меня только отвлекает. Я хочу видеть это прямо перед собой!

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

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

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

4. Перемещение тестирования к началу

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

В будущем мы должны устранить этот разрыв полностью.

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

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

Давайте рассмотрим их по порядку, начиная с «тестирования ранних артефактов разработки». На последней линии обороны мы применяем к исполнимому коду программы различные стратегии поиска дефектов, используя внешние (публичные) интерфейсы программы. Мы берем скомпилированную программу или комплект библиотек, цепляем их к нашему тестовому окружению, и издеваемся над ними, используя различные входные параметры и данные, до тех пор, пока не разыщем определенное количество багов, чтобы иметь хоть какую-то уверенность, что качество достаточно высокое. Но зачем ждать, пока будут готовы бинарники? Почему мы не можем применить эти методы тестирования к архитектурным артефактам? К требованиям и user stories? К спецификации и дизайну? Как такое случилось, что все технологии, техники, знания, собранные за последние полвека, применяются только к исполняемому артефакту? Почему архитектуру нельзя тестировать таким же способом? Почему мы не можем применить то, что знаем, к дизайну и user stories? Ответ таков: нет никаких веских причин, из-за которых мы не можем этого сделать. Я уже сейчас вижу, что многие прогрессивные группы в Microsoft применяют методы раннего тестирования, а в будущем, надеюсь, мы придумаем, как делать это коллективно. Тестирование будет начинаться не тогда, когда появится что-то тестируемое, как это происходит сейчас, а тогда, когда существует что-то, нуждающееся в тестировании. Это тонкое, но важное различие.

«Ранняя компиляция» — это вторая часть, но ее реализация представляет собой технологический барьер, для преодоления которого необходим скачок. Сейчас мы пишем программу компонент за компонентом, и не можем собрать систему целиком до тех пор, пока не будет готова каждая её часть. Это означает, что тестирование вынуждено дожидаться, пока все компоненты достигнут определенного уровня завершённости. Баги могут находиться в программе на протяжении дней и недель до того момента, как тестирование отправится на их поиски. Можем ли мы заменить недописанные компоненты виртуальными? Или заглушками, которые имитируют поведение компонента с точки зрения внешнего наблюдателя? Можем ли мы создать компоненты-хамелеоны общего назначения, которые будут изменять свое поведение, чтобы соответствовать системе, в которую они (временно) встроены? Я предполагаю, что можем, потому что… мы должны это сделать. Виртуальные компоненты и компоненты-хамелеоны позволят тестировщикам применить своё искусство обнаружения багов сразу же после того, как баг создан. У ошибок будет мало шансов прожить дольше первого вздоха.

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