Уиттакер . - Как тестируют в Google

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

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

Со временем проект RPF вырос из экспериментального проекта команды тестирования в формальную часть всей команды Chrome, где его теперь используют для регрессионного тестирования. Команда работает над тем, чтобы дать возможность тестировщикам, которые не умеют программировать, возможность генерировать регрессионные сценарии с помощью BITE/RPF.

Присоединяйтесь к нашей работе по сопровождению BITE/RPF ( http://code.google.com/p/bite-project / ). Не забудьте поблагодарить По Ху и Джоэла Хиноски, которые двигают проект вперед.

Google Test Analytics — теперь с открытым кодом

Среда , 10 октября 2011 г ., 13:03

http :// googletesting . blogspot . com /2011/10/ google - test - analytics - now - in - open . html

Джим Рирдон

Тест-план мертв!

Ну, мы на это надеемся. Неделю назад на семинаре STAR West Джеймс Уиттакер выяснил мнение профессиональных тестировщиков о тест-планах. Его первый вопрос был такой: «Кто из присутствующих пишет тест-планы?». Поднялось около 80 рук — подавляющее большинство. «Кто из вас получает от тест-планов практическую пользу или возвращается к ним через неделю?» Руки подняли ровно три человека.

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

Мы в Google решили создать методологию на замену тест-планам. Она должна быть полной, быстрой, действенной и приносить постоянную пользу проекту. Не так давно Джеймс уже писал в нашем блоге об этой методологии, которую мы назвали ACC. У нас получился инструмент, который разбивает продукт на составные части, и метод, который помогает составлять «10-минутные тест-планы» (вообще-то это занимает около 30 минут!).

Полнота

Методология ACC создает матрицу, полностью описывающую ваш проект. С ее помощью в нескольких внутренних проектах Google нашли области покрытия, упущенные в ходе обычного планирования тестирования.

Скорость

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

Действенность

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

Польза

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

Сегодня я с радостью объявляю, что мы открываем исходный код Test Analytics ( http://code.google.com/p/test-analytics / ) — инструмент, созданный в Google для упрощения ACC-анализа.

Test Analytics состоит из двух основных частей: первая часть — это пошаговый инструмент для создания матрицы ACC (рис. В.5). Он работает быстрее и проще электронных таблиц, которые мы использовали до этого (убедитесь, взглянув на рис. В.6). Наш инструмент визуализирует матрицу и риски, связанные с возможностями ACC, чем тоже не могли похвастаться обычные электронные таблицы (рис. В.7).

Рис. В.5. Определение атрибутов проекта в Test Analytics

Рис. В.6. Отображение возможностей проекта в Test Analytics

Рис. В.7. Отображение рисков в матрице атрибутов и компонентов в Test Analytics

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

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

Рис. В.8. Test Analytics, привязанный к данным багов и тестовых примеров

Вы можете поэкспериментировать с живой версией продукта ( http://goo.gl/Cv2QB ), посмотреть код ( http://code.google.com/p/test-analytics / ) вместе с документацией ( http://code.google.com/p/test-analytics/wiki/AccExplained ), и, конечно, мы будем рады вашим отзывам.