На минувших выходных в Кремниевой долине состоялся очередной Code Camp — масштабное мероприятие для разработчиков. Некоторые сессии были посвящены тестированию ПО, об одной из них и хотелось бы вкратце рассказать.
Сессия была заявлена как «Next Generation of Testing for HTML5». В реальности Кевин вкратце описал нововведения в html5, используя эту презентацию, а затем изложил свое видение, какие инструменты тестирования веб-приложений сегодня наиболее интересны. В качестве иллюстрации к тому, о чем пойдет речь, он приложил скриншот подписи из Google testing blog: «Life is too short for manual testing».
Будучи разработчиком, Кевин не мог обойти в докладе юнит-тестирование. Цитата: «Многие говорят, что необходимо покрывать юнит-тестами 80%, а то и 90% кода. Я же считаю, что достаточно и 10% для тестирования основной функциональности. Далее тестирование подхватит QA-специалист. Однако если он возвращается к вам с багом – самое время изучить область, в которой вы ошиблись, глубже, и начать писать регрессионные тесты».
Рекомендованный им инструмент для юнит-тестирования – QUnit, который уже был неплохо освещен на Хабре. Однако для интеграционного тестирования он не подходит, поскольку не может проверить функциональность сайта, зависящую от обновления страницы (log in, например). И потому следующая рекомендация Кевина — г-н Хадсон.
Hudson представляет собой то, что в больших компаниях называют «testing lab» (и пишут для внутренних нужд самостоятельно): следит за выполняемыми задачами, собирает билды и шлет сообщения об ошибках. В разных компаниях этот инструмент используется разными специалистами, но если именно тестировщику поручено собирать билды, то как минимум стоит с Hudson-ом ознакомиться.
Далее мы немного поговорили о Селениуме (как выяснилось, большинство присутствующих в зале используют для работы именно этот инструмент), основной недостаток которого – необходимость знать «внутренний» язык программы, если не хочешь править код под разные браузеры. Кроме того, Селениум не поддерживает javascript – «Что за ерунда, у меня вся команда знает javascript, мог бы каждого заставить скрипты писать, — ан нет!» — ворчал докладчик.
Легкая и простая альтернатива — Canoo Webtest. Последний билд от 29 сентября 2010, так что проект живой и совершенствующийся, несмотря на простенький сайт.
Продукт посерьезнее, и, пожалуй, даже революционнее — Test Swarm. Инновационность идеи заключается в краудсорсинге: необязательно выбивать себе десяток тестовых машин, если надо всего лишь проверять работу сайта в браузерах разных версий. Можно одолжить машины коллег для этой цели) Веб-сервер анализирует, какие браузеры доступны на какой из подключенных машин, и задействует их все в тестировании. Наглядная презентация на Vimeo о том как это работает. Альфа-версия проекта вышла в августе прошлого года, последние коммиты я видела от марта нынешнего года. Кевин рассказал, что как-то коллеги ему представили билд, который безошибочно прошел все тесты в одной из версий ФФ, установленной на его компьютере. «Хм, а давайте-ка прогоним его через Test Swarm», — сказал он, и во всех остальных версиях браузеров обнаружился тот или иной сбой.
P.S. Возможно, упомянутые инструменты известны большинству подписчиков сообщества. В таком случае, поздравляю, вы находитесь на передовой фронта в борьбе за качество веб-приложений)
Сессия была заявлена как «Next Generation of Testing for HTML5». В реальности Кевин вкратце описал нововведения в html5, используя эту презентацию, а затем изложил свое видение, какие инструменты тестирования веб-приложений сегодня наиболее интересны. В качестве иллюстрации к тому, о чем пойдет речь, он приложил скриншот подписи из Google testing blog: «Life is too short for manual testing».
Будучи разработчиком, Кевин не мог обойти в докладе юнит-тестирование. Цитата: «Многие говорят, что необходимо покрывать юнит-тестами 80%, а то и 90% кода. Я же считаю, что достаточно и 10% для тестирования основной функциональности. Далее тестирование подхватит QA-специалист. Однако если он возвращается к вам с багом – самое время изучить область, в которой вы ошиблись, глубже, и начать писать регрессионные тесты».
Рекомендованный им инструмент для юнит-тестирования – QUnit, который уже был неплохо освещен на Хабре. Однако для интеграционного тестирования он не подходит, поскольку не может проверить функциональность сайта, зависящую от обновления страницы (log in, например). И потому следующая рекомендация Кевина — г-н Хадсон.
Hudson представляет собой то, что в больших компаниях называют «testing lab» (и пишут для внутренних нужд самостоятельно): следит за выполняемыми задачами, собирает билды и шлет сообщения об ошибках. В разных компаниях этот инструмент используется разными специалистами, но если именно тестировщику поручено собирать билды, то как минимум стоит с Hudson-ом ознакомиться.
Далее мы немного поговорили о Селениуме (как выяснилось, большинство присутствующих в зале используют для работы именно этот инструмент), основной недостаток которого – необходимость знать «внутренний» язык программы, если не хочешь править код под разные браузеры. Кроме того, Селениум не поддерживает javascript – «Что за ерунда, у меня вся команда знает javascript, мог бы каждого заставить скрипты писать, — ан нет!» — ворчал докладчик.
Легкая и простая альтернатива — Canoo Webtest. Последний билд от 29 сентября 2010, так что проект живой и совершенствующийся, несмотря на простенький сайт.
Продукт посерьезнее, и, пожалуй, даже революционнее — Test Swarm. Инновационность идеи заключается в краудсорсинге: необязательно выбивать себе десяток тестовых машин, если надо всего лишь проверять работу сайта в браузерах разных версий. Можно одолжить машины коллег для этой цели) Веб-сервер анализирует, какие браузеры доступны на какой из подключенных машин, и задействует их все в тестировании. Наглядная презентация на Vimeo о том как это работает. Альфа-версия проекта вышла в августе прошлого года, последние коммиты я видела от марта нынешнего года. Кевин рассказал, что как-то коллеги ему представили билд, который безошибочно прошел все тесты в одной из версий ФФ, установленной на его компьютере. «Хм, а давайте-ка прогоним его через Test Swarm», — сказал он, и во всех остальных версиях браузеров обнаружился тот или иной сбой.
P.S. Возможно, упомянутые инструменты известны большинству подписчиков сообщества. В таком случае, поздравляю, вы находитесь на передовой фронта в борьбе за качество веб-приложений)
