Бесплатный семинар <<Функциональное тестирование на основе вариантов ис
Новые темы форума тестировщиков
Ссылка на описание на сайте организаторов
Спикер: Алексей Баранцев
Тема семинара: «Функциональное тестирование на основе вариантов использования»
Дата: 13 ноября 2014
Время: С 18:00 до 20:00
Место: Гостиница «Амакс» (бывшая «Центральная»), зал Триумф.
Заходим через центральный вход – далее следуем за указателями.
Варианты использования в той форме, как описано в книге Алистера Коберна "Современные методы описания функциональных требований к системам", очень удобны для разработки тестов. И с точки зрения их создания, и с точки зрения управления тестами и прослеживания покрытия требований тестами. На семинаре мы подробно рассмотрим этот подход к разработке тестов, а вам останется только убедить ваших аналитиков писать требования в таком виде.
Семинар будет интересен как начинающим, так и опытным тестировщикам. Начинающие смогут ознакомиться с одной из ключевых техник проектирования тестов. Более опытные тестировщики, уже владеющие этой техникой, узнают о том, какие подводные камни могут встречаться при её использовании и какие рекомендуются способы борьбы с ними. Кроме того, семинар будет полезен аналитикам, так как разработка сценариев использования находится либо полностью в их зоне ответственности, либо эта работа выполняется совместно с тестировщиками.
Определение повторных проверок 2014-11-09 00:03 Доброго всем времени суток. Возникла очень интересная организационная проблема, связанная с тестированием, точнее с документацией. Есть сложная система в состав которой входят вычислители с ПО. ПО разрабатывается по ГОСТ Р 51904. Разработку и тестирование ПО проводят разные отделы одной организации (назовем организация А). Далее система подвергается своему тестированию на соответствие заданных требований. Это тестирование проводит уже другая организация (организация Б), в которой специалистов по ПО практически нет (проверка проводится по решаемым задачам, а как конкретно реализовано решение задачи всегда было без разницы). При этом ввиду высокой сложности и большим объемом решаемых задач головным заказчиком было определено т.н. постепенное наращивание решаемых задач (в основном выполняется доработкой ПО). В результате получается, что после выполнения ряда проверок всей системы, разработчиком представляется новая версия ПО, с увеличенным числом решаемых задач и исправлением выявленных при тестировании системы ошибок. По большому счету правильнее было бы провести все уже выполненные проверки системы заново, но это практически невозможно (сроки/стоимость). Соответственно стоит вопрос в определении некоего объема повторных проверок, на основании которого можно подтвердить, что изменения и доработки, внесенные в ПО не изменили предыдущих полученных результатов тестирования системы. Так вот, какие, по Вашему мнению, документы должны/могут быть представлены из А в Б для определения данного объема? Я понимаю, что это совсем не простой вопрос, но руководители Б, потрясая сборником алгоритмов 1987 года :) утверждают, что здесь они в свое время все прекрасно видели, знали и понимали любое изменение и требуют нечто подобное - к примеру некую блок-схему по которой можно сказать, что если изменили что-то в одном блоке, то можно повторно посмотреть только решение задачи, за которую отвечает этот блок, а все остальное считаем неизменным и незатронутым. Любых возражений не воспринимают. Сейчас организация А с каждой версией ПО представляет Акт по результатам тестирования, однако толку в данном вопросе от него никакого. Организация автоматизированного тестирования, новый тренинг, начало 1 2014-11-09 21:13 Авторы и ведущие тренинга: Алексей Баранцев и Наталья Руколь У многих тестировщиков, а также и у многих менеджеров, при звуке слов "автоматизация тестирования" в мозгу возникает идиллическая картинка в стиле научно-фантастических романов: роботы выполняют рутинную и тяжёлую работу, а человек занимается интеллектуальным или творческим трудом. Но это никакая не фантастика, это вполне реально и достижимо! Да, можно освободить тестировщиков от выполнения некоторых типовых задач, переложив эту работу на плечи роботов. Таких рутинных действий тестировщик совершает больше, чем кажется на первый взгляд. Автоматизировать можно не только собственно выполнение тестов, но и подготовку тестового стенда, генерацию тестовых данных большого объёма или высокой сложности, помощь в проверке результатов, полученных при ручном тестировании (сравнение текстов, картинок), создание отчётов или иных документов. Однако нельзя просто пойти и купить робота, который начнёт немедленно приносить вам пользу. Можно либо взять "универсального" робота и обучить его, либо взять конструктор и собрать узкоспециализированный автомат для решения ваших конкретных задач. Процесс внедрения автоматизации – это как раз и есть процесс создания или обучения роботов. Внедрение автоматизации затрагивает многие стороны процесса разработки. Это отнюдь не чисто инженерная задача, требующая только владения инструментами автоматизации и навыками программирования. Прежде чем перейти к технической части, необходимо выбрать оптимальную стратегию внедрения и дальнейшего развития автоматизированных тестов. Нужно скоординировать работы по автоматизациями с деятельностью специалистов по ручному тестированию, потому что предстоит провести отбор тестов для автоматизации, а может быть и переработку этих тестов. Предстоит также согласовать свои действия с разработчиками, а может быть даже договориться о специальных доработках тестируемого приложения для более удобной автоматизации. Ну и конечно без инженеров в этом деле не обойтись. Правильно выбрать средства автоматизации, интегрировать с инструментами групповой работы (баг-трекер, сервер непрерывной интеграции, системы отчётности) – при решении этих технических задач талант инженера-автоматизатора может раскрыться в полной мере. Но главная опасность подстерегает впереди – рано или поздно станет ясно, насколько оправданным и экономически целесообразным оказалось внедрение автоматизации в тестирование. Нужно будет оценить достигнутые результаты и принять новые решения относительно дальнейшего развития систем автоматизации. Чтобы научить вас правильно планировать процесс внедрения автоматизации, успешно решать технические задачи и адекватно оценивать текущее состояние процесса мы разработали новый тренинг, особенность которого заключается в том, что его ведут два тренера – "менеджер" и "инженер". Это позволит вам увидеть проблемы, которые возникают при внедрении автоматизации тестирования, с двух разных (можно даже сказать противоположных) точек зрения. Тренинг будет полезен всем, кто внедряет с нуля или улучшает текущие подходы к организации автоматизированного тестирования: тест-менеджерам, специалистам по автоматизации и тест-дизайнерам, взаимодействующим с группой автоматизации. Программа тренинга и условия участия Читать дальше © 2010 | Software-Testing.Ru |
| В избранное | ||
