Несколько дней назад завершилась онлайн-конференция Auto ConfeT&QA 2012, чуть меньше месяца остается до следующей конференции -- Chief ConfeT&QA 2012.
А тем временем мы предлагаем посмотреть рассказ Алексея Баранцева о кроссбраузерном тестировании с прошлогодней "конфетки" -- конференции ConfeT&QA 2011. Вы узнаете, где именно в работе браузеров существуют различия, почему недостаточно проверять соответствие стандартам, где взять различные версии браузеров, что следует варьировать при выполнении тестов помимо версии браузера, какими онлайн-сервисами можно пользоваться для тестирования в разных браузерах. Если вы специализируетесь на тестировании веб-приложений -- уделите полчаса своего внимания для повышения квалификации, это стоит потраченного времени.
 25 апреля 2010 года в Клубе Computer Science при Петербургском отделении Математического института РАН выступил Виктор Кулямин (ИСП РАН) с мини-курсом "Тестирование на основе моделей" (3 лекции по примерно 90 минут). В этих лекциях речь шла о том, что такое вообще тестирование на основе моделей, почему оно достаточно перспективно как подход к контролю качества современного сложного ПО, какие основные виды моделей используются в тестировании и какими методами можно эффективно строить тесты на их основе.
"Мне лично очень понравилась активность аудитории," - сказал Виктор, - "большое количество вопросов и замечаний, как во время лекций, так и после, еще почти час я отвечал на вопросы слушателей. Это при том, что люди пришли на лекции в воскресный день, потратив его практически полностью".
Слайды, сопровождавшие этот мини-курс, доступны на сайте Клуба Computer Science, кроме того опубликованы видеозаписи выступления Виктора:
Видео 1-й лекции
Видео 2-й лекции
Видео 3-й лекции
За ссылки на видеозаписи мы благодарим Михаила Елычева, который присутствовал на этих лекциях и поделился своими впечатлениями на сайте сообщества тестировщиков Санкт-Петербурга.
17.10.2009
Баранцев Алексей
 В комментариях к заметке "Можно ли делить на 0,01 ?" я обещал написать отдельный пост, посвященный валидации данных, которые приложения получают извне -- от пользователя, от других программ, из файлов и т.д. Кроме того, не так давно эта тема вновь ненадолго возникла в обсуждении заметки "Проверка экранных форм". Так что, видимо, пришло время обсудить этот вопрос в деталях.
Мы рассмотрим три вопроса -- 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок.
 Авторы: Алексей Булат, Василий Касимов, Владимир Антонов, Алексей Лянгузов
Особая благодарность за помощь в работе над материалом Сергею Вороновичу и Андрею Осипенко
Информация получена: Из блога Про Тестинг (статья Тестирование Инсталляций (Installation Software Testing) и сайта ProTesting.ru (раздел Тестирование Установки (Installation Testing))
Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.
В настоящий момент наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые сами по себе так же требуют надлежащего тестирования, описание которого рассмотрено ниже в разделе "Особенности тестирования инсталляторов.").
В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки.
В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя - это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.
Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.
04.07.2009
Баранцев Алексей
Поскольку видеозапись докладов на конференции SQA Days 2008 Minsk получилась не очень удачной (на ней не видно слайдов), я в конце концов решил переделать свой доклад в формат слайдкаста (то есть презентации с наложенным звуком).
 Автор: Meir Bar-Tal
Перевод: Сергей Талалаев (SQAdotBY)
Оригинальная статья: Implementing a GUI Layer with Classes
В продолжении темы сотрудничества с уважаемым ресурсом AdvancedQTP.com и с любезного разрешения автора, хотел бы представить перевод очень интересной статьи с данного сайта. Описанный подход заслуживает права на детальное изучение и применим не только в рамках QTP, но и в любом другом средстве автоматического тестирования. Автором проведена серьезная работа с целью поиска оптимального варианта реализации тестового фреймворка с точки зрения минимизации издержек на его поддержку.
 Автор: Сергей Талалаев
Оригинальная публикация: QTP: Универсальный класс для работы с данными
Влияние мирового кризиса к сожалению сказалось и на моей персоне и мне потребовалось срочно и по возможности глубоко изучить новый для себя фреймворк - Quick Test Professional. И душа рвется поведать о результатах, которые надеюсь буду полезны не только мне одному.
Двойное название статьи как-бы говорит о том, что материала накопилось достаточно для небольшой серии статей и если силы и желание не иссякнут еще на первой статье, то есть шанс увидеть продолжение ...
 Автор: Статья написана членами коллектива ООО «Системы программной верификации» или в соавторстве с ними.
Оригинальная публикация
Тестирование приложений с параллельной обработкой - задача непростая. Ошибки распараллеливания сложно выявить из-за недетерминированности поведения параллельных приложений. Даже если ошибка обнаружена, ее часто сложно воспроизвести повторно. Кроме того, после модификации кода, не так просто убедиться, что ошибка действительно устранена, а не замаскирована. Все это можно назвать и по другому, а именно, что ошибки в параллельной программе являются классическими "гейзенбагами".
Гейзенбаг (англ. Heisenbug) - термин, используемый в программировании для описания программной ошибки, которая исчезает или меняет свои свойства при попытке её обнаружения [2]. Данное название является игрой слов и происходит от физического термина «Принцип неопределённости Гейзенберга», который на бытовом уровне понимается как изменение наблюдаемого объекта в результате самого факта наблюдения, происходящее в квантовой механике. В русской терминологии более часто используется термин «плавающая ошибка». Примером могут являться ошибки, которые проявляются в окончательном варианте программы (“релизе”), однако не видны в режиме отладки, или ошибки синхронизации в многопоточном приложении.
Таким образом, задача параллельного тестирования во многом сводится к проблеме создания инструментов диагностики, минимально влияющих на поведение программы или создающих необходимые условия для ее проявления. Поэтому посмотрим на классические методологии тестирования под новым углом.
 Автор: Джон Смарт (John Smart)
Оригинальная публикация: Background Unit Testing: New evolutions in unit testing and IDE integration
Об авторе: Джон Смарт -- ведущий консультант компании Wakaleo Consulting, специализирующейся в области Enterprise Java, Web Development и Open Source technologies. В настоящее время он проживает в Веллингтоне, Новая Зеландия. Джон широко известен в Java-сообществе благодаря многочисленным публикациям, кроме того, он является автором Java Power Tools.
Одна из самых последних инноваций в модульном тестировании – идея непрерывного тестирования, то есть выполнение модульных тестов сразу же после того, как вы изменили что-то в исходном коде – то есть, как только вы сохраняете сделанные изменения на диск, нужные модульные тесты выполняются в фоновом режиме. Это позволяет избежать ситуаций, когда разработчик либо забыл, либо по какой-то другой причине не выполнил нужные тесты, в результате чего в репозиторий попадает код, на котором эти тесты завершаются неуспешно. Разумеется, главная сложность заключается в том, чтобы определить, какие же тесты следует выполнить, когда изменился тот или иной фрагмент исходного кода, поскольку выполнять полный комплект тестов может быть слишком долго, чтобы делать это после каждого изменения кода. Нужно выделить ровно те тесты, на результат выполнения которых в наибольшей степени могут оказать влияние сделанные изменения. Я уверен, что через пару лет это станет стандартной встроенной функциональностью во всех средах разработки.
А пока этого не случилось, вы можете воспользоваться вспомогательными инструментами.
|
Автор: Статья написана членами коллектива