Home

Перевод: Комендантов Илья, компания "Lohika" (г. Одесса)

Оригинал

В статье описаны типовые решения проблем, с которыми может столкнуться пользователь  Ajax TruClient – протокола для записи Web2.0 сайтов, появившегося в 11-й версии HP LoadRunner. А также приведены примеры и советы по использованию тех или иных возможностей нового протокола.

Приглашаем принять участие в неконференции AgileCamp, которая состоится 17-18 июня в Самаре. AgileCamp — это наш Учебный Лагерь, где каждый сможет научиться новым подходам работы. Формат – никаких скучных докладов! Первый день AgileCamp целиком и полностью состоит из игр и симуляций и упражнений, прокачивающих реальные навыки управления процессом разработки в стиле Agile, управления продуктом и требованиями, разработки качественного и эффективного кода. Мастер-классы включают минимум теории плюс реальное применение на практике под присмотром опытных Agile-гуру.

Во второй день мы вместе обсудим ваши реальные проблемы совместно с другими участниками и с Agile-гуру. Второй день – это неформальное общение в формате Open Spaces, панельных и fishbowl-дискуссий. Место проведения - прогулка на теплоходе "Мария" по Волге.

Вся структура AgileCamp нацелена на развитие навыков в состоянии полного погружения в Agile процесс.

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

Количество билетов ограничено, спешите Зарегистрироваться

Выступление Алексея Баранцева на AgileDays-2011

Идея написания спецификаций на «естественном языке» манит своей внешней красотой и простотой. Мысль о том, что не умеющий программировать product owner станет сам рисовать Fitnesse-таблички и писать Cucumber-спецификации, выглядит очень привлекательно, возникает надежда переложить на него часть работы. Более того, исполнимые спецификации можно использовать как направляющие для разработки, и наряду с test driven development возникают подходы с похожими названиями — Behavior driven development и даже acceptance test driven development.

Однако здесь есть два больших подводных камня.

Помните бородатый анекдот про морскую свинку, которая, вопреки своему названию, и не плавает, и не хрюкает? Когда я слышу про автоматизированное приёмочное тестирование в контексте agile, у меня всегда возникает ассоциация с этой морской свинкой. Автоматизированное? Да, с этим не поспоришь. Но при этом и не приёмочное, и не тестирование. Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты, а при ручном тестировании он и вовсе не нужен. Ну а идея автоматизировать приёмку вообще слабо вписывается в концепцию agile: если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?

Второй подводный камень связан с большими скрытыми (или по крайней мере замалчиваемыми) затратами. Да, спецификации на «естественном языке» выглядят красиво. Но, увы, работа по реализации фикстур и шагов сценариев — это уже чистое программирование, причём объём и сложность этой работы в разы превышает размеры табличек и спецификаций. И это немедленно разрушает ореол простоты.

Так стоит ли вообще вкладывать усилия в эту деятельность? Кому BDD и ATDD приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.

Видеозапись доклада можно посмотреть здесь.

Обсудить в форуме

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

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

Тогда вы просто не можете позволить себе пропустить это событие!

По количеству учебных часов это аналогично трёхдневному тренингу, но только гораздо лучше.
Почему?

Подробности

28-29 мая в Санкт-Петербурге Федоров Александр проведет очный двухдневный тренинг "Тест-дизайн и все-все-все".

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

Подробная программа и условия участия

Как проходила конференция SQA Days - 9 в Казани 22-23 апреля 2011, вы узнаете из следующего видео:

Оригинальная публикация
Автор: Bj Rollison
Перевод: Татьяна Зинченко

В комментариях к одной из заметок в моем блоге Шрини Калкарни (Shrini Kulkarni) предложил: “Наверное, тебе стоит написать о тех багах, которые юнит-тесты (или тестирование разработчиками на любом уровне) не могут поймать. Это будет достойный ответ всем, кто безгранично верит в автоматизацию тестирования на юнит и API уровнях”

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

• профилактики дефектов (особенно ошибок в логике вычислений);
• ранней идентификации проблем интеграции;
• создания нагрузки на критические ресурсы (питание, производительность, память);
• эффективного выполнения избыточных проверок (по необходимости или для надежности);
• более эффективных/точных “оракулов” по сравнению с людьми;
• снижения затрат в долгосрочной перспективе.

29 апреля в 10-00 Александр Орлов и Вячеслав Панкратов объявили старт продаж своего нового проекта "Манхеттен".

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

За сегодняшнюю ночь участники раннего списка, которые получили возможность купить проект на 12 часов раньше уже купили более 70 копий данного проекта и заказы не перестают поступать.

Электронный курс «Проект Манхеттен» посвящен практическим приемам построения карьеры.

Внутри этого продукта, вы найдете около 4-ех часов видео и аудио материалов, включая несколько интервью приглашенных ТОР-менеджеров, которые прошли путь от инженеров до руководящих постов в ИТ-компаниях.

Cжато, просто, без воды и рассказов «вставайте раньше и вкалывайте больше». Есть желание расти профессионально и строить карьеру — в ваших твоих руках набор приемов и техник, которые будут обеспечивать постоянное движение и рост.