Первый вебинар серии "Работа с требованиями: анализ, тестирование" пройдет 10 декабря в 13-00.
Существует мнение, что основная задача тестирования – проверка соответствия разработанного приложения требованиям и поиск ошибок. Но как же часто встречается ситуация, когда сами требования содержат ошибки! Ошибки не функциональные, а логические, противоречия, недомолвки, двусмысленности.
На этом семинаре мы будем говорить о том, зачем нужно анализировать и тестировать требования, кто это должен делать, как и по каким критериям, и что должно быть результатом этих действий.
Основные темы вебинара:
* Когда и зачем привлекать тестировщиков к анализу и тестированию требований. * Критерии качественного требования. * Свойства требований. * Функциональные и нефункциональные требования. * Явные и неявные требования * Методики тестирования требований. * Полномочия и компетенции тестировщиков при работе с требованиями.
Контролирующий акционер «Рамблера» готовится к «обратному аукциону» — выкупу бумаг с рынка. Публичный статус интернет-компании сейчас экономически не оправдан, подтверждают аналитики. В самом «Рамблере» считают, что делистинг мало повлияет и на отношения с собственником, и на деятельность компании.
Группа «ПрофМедиа», мажоритарный акционер «Рамблера», сегодня (11 ноября) объявила о начале ускоренного формирования книги заявок по выкупу акций («обратный аукцион») российской интернет-компании. «ПрофМедиа» действует через компанию PM Invest Company, а брокером по покупке акций «Рамблер Медиа» выступает банк ING. (more…)
Доклад рассматривает подход к процессу тестирования исходя из реалий жизни небольшой софтверной аутсорсной компании. От каких документов можно отказаться в процессе тестирования? Что стоит делать в первую очередь и на что обращать внимание. Какой принцип ложится во главу угла, когда тестировщики определяются с объемом работы на проекте.
Особенность доклада – присутствие практической составляющей. Можно много говорить о том, что нужно делать, но лучше один раз показать, как это делают другие.
Доклад не лишен спорных вопросов, автор намеренно призывает задуматься над тем, что обычно воспринимается как «нужное» априори.
В очередной раз столкнулся с проблемой с закладкой Resources в свойствах теста - на некоторых машинах пропадает и все, больше не появляется! При этом изменить список подключенных библиотек нельзя.
Скриншот с иллюстрацией во вложении.
Встречал описание подобной проблемы в нете, но решения не было. Кроме того говорили, что после переустановки QTP проблема фиксится, но в моем случае проблема остается и после полной переустановки QTP (c очисткой реестра от хвостов).
Не очень-то надеюсь на готовое решение, но может все-таки кто-то сталкивался с такой проблемой и может что-то посоветовать...
Есть html-cтраница, использующая нестандартные теги, определяемые стандартом VML (возможность рисовать графические фигуры). Необходимо проверить наличие элементов, определяемых тегом <rect> (для начала хотя бы). Столкнулся с тем, что QTP не видит таких элементов, пробовал: 1) записывать методом Record&Play (усиленно тыкал мышкой в элемент, но никаких действий не писалось, стандартные элементы пишутся без проблем) 2) через объект Description элементы с тегом <rect> также не находятся ##### Код { ##### Set descr = Description.Create descr("html tag").Value = "rect" Set lst = pg.ChildObjects(descr) MsgBox lst.count ##### Код } ##### 3) из DOM вытянуть объект можно (но не очень то хотелось бы работать с ним через DOM) ##### Код { ##### Set lst = pg.getElementsByTagName("rect") MsgBox lst.length ##### Код } #####
Вопрос - можно ли как-то "уговорить" QTP работать с нестандартными тэгами? (относительно нестандартными, поскольку тот же VML - это детище microsoft)
В реальной жизни тестировщики часто сталкиваются с ситуацией, когда требования к системе меняются постоянно, сроки разработки сжаты, а 100% покрытие недостижимо – не потому, что заказчик не знает, чего хочет, а потому что постоянно меняется среда, в которой работает система, и потому что опоздать – хуже, чем ошибиться. Здесь приходится говорить о достаточном уровне надежности, приоритетах и принятии определенной доли риска.
Классическая литература такие ситуации часто обходит: считается, что четко определенный процесс тестирования в подобных условиях не существует. На самом деле процесс есть, он просто другой. Целью становится не полное покрытие и документальное подтверждение следования технологии, а постоянная оценка и пересмотр критических мест системы, поддержание целостной информации о ее состоянии, ее функциональности и дефектах. В докладе пойдет речь о возможной организации такого процесса при помощи GTD, управления конфигурациями и быстрой визуальной оценки состояния системы.