Читаем Как тестируют в Google полностью

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

— Как разработчики оценивают твою работу? Если они недооценивают тестирование, как ты себя ведешь?

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

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

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

— Расскажи немного о своем тестировании Google Sites. Как ты подошла к проекту? Какие документы ты создавала и в каком формате? Как подала свои выводы и результаты разработчикам?

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

Я начала работу как пользователь, осваивала продукт самостоятельно, создавая свои сайты. Заодно я связалась с людьми, которые много им пользовались. Например, ассоциация домовладения дома, где я живу, несколько месяцев назад перевела сайт сообщества на Google Sites, и я поинтересовалась, как произошел этот переезд. Документация по этому проекту вовремя не обновлялась, поэтому мне пришлось разбить продукт на блоки и задокументировать все компоненты и подкомпоненты.

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

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

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

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

— А можешь рассказать о самом интересном баге, который ты находила, и как это произошло?

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

— Как ты оцениваешь результат своей работы?

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT