Home

Автор: Алексей Ракицкий – ведущий специалист по автоматизации функционального и нагрузочного тестирования ПО Qulix QA.
Оригинал: http://www.qa.qulix.ru/knowledge/articles-automation.php

Учитывая растущий интерес к инструментам автоматизации тестирования и внедрению процесса автоматизации на проектах, появляется все больший спрос к обучению и консалтингу в этой области обеспечения контроля качества проектов.

Статья посвящена рекомендациям по наиболее безболезненному варианту внедрения автоматизации тестирования на уровне проекта в случае, если это направление в целом не развито в компании – производителе ПО.

Автор: Андрей Гридин

Качество программного продукта не в последнюю очередь зависит от актуальной документации и тщательного тестирования. Хотелось бы осветить вопрос разработки и тестирования ПО вообще и с использованием среды FitNesse в частности.

Intro

Когда говорят о тестировании ПО, чаще всего подразумевают тестирование, выполненное после того, как изрядное количество кода написано и возникает необходимость проверить «а то ли написали, что хотели».
Понятно, что покрытие кода тестами, виды и продолжительность тестирования зависят от многих факторов, но в данном случае следует упомянуть именно о модульных тестах и о приёмочных тестах.
Если модульное тестирование выполняет обычно тот, кто пишет тот или иной кусок кода, то приёмочное тестирование, как правило, выполняет заказчик. И тут уже всё зависит от того, насколько высоки требования заказчика (и, что немаловажно, то насколько он способен качественно тестировать принимаемый им готовый продукт).
Так вот, модульные тесты обычно автоматизированы по выполнению (они один раз пишутся и много раз прогоняются в автоматическом режиме).
А приёмочные тесты обычно медленно прогоняются в ручном режиме и постоянно изменяются и обычно достаточно редко фиксируются на бумаге.
К чему все эти разговоры про тестирование? Правильно организованный процесс тестирования создаваемого программного продукта в конечном счёте позволит сэкономить деньги и время на устранении ошибок, и более того увеличить прибыль от хорошей репутации компании.

Автор: Сычев Игорь

Оригинальная публикация

В продолжение своего изучения инструментов тестирования для .Net приложений, хочу рассказать о Lightweight Test Automation Framework (LTAF). LTAF — это фреймворк для регрессионного тестирования web приложений Asp.Net, с открытым исходным кодом, созданный QA Team. На русском языке я не нашел никаких материалов о нем, поэтому решил написать эту обзорную статью.

На прошедшей недавно в Киеве конференции Test Labs 2009 прозвучал замечательный доклад в исполнении Максима Дорофеева "Обезьянки против роботов". С одной стороны, поднимаемый в этом докладе вопрос о преимуществах и недостатках ручного и автоматизированного тестирования обсуждался уже множество раз. Тем не менее, Максиму удалось показать проблему под несколько иным углом. Вместо абстрактной перепалки "ручников" с "автоматизаторами", в которой каждая сторона конечно же хвастается своими достоинствами и преувеличивает чужие недостатки, Максим представил, как "обезьянки" и "рооботы" решают одни и те же задачи, каждый по максиму используя свои преимущества. Разумеется, никто не выиграл. Посмотрите слайдкаст доклада, и вы узнаете, почему, по мнению Максима, никто и не мог выиграть.

Автор: Евгений Россинский

Оригинальная публикация: http://blog.netstream.ru/2009/03/squis/

При разработке мы стараемся покрывать наш код не только матом, но и unit тестами. Однако все покрыть тестами не всегда получается. К тому же, остается GUI, для которого написание тестов довольно трудоемкая работа. При всех этих проблемах неизменным остается требование, что каждый следующий камит в репозиторий не должен портить уже существующий функционал.

В этой статье я хочу рассказать какой инструментарий мы используем для тестирования наших desktop приложений, написанных на Qt.

Пол года назад в ходе исследования инструментов для тестирования GUI в поле моего зрения попал продукт Squish компании froglogic. Из плюсов данного решения можно отметить следующие:

• тесная дружба Squish c классами Qt (в том числе и itemы в QGraphiscScene);
• кроссплатформенность;
• поддержка скриптовых языков (Javascript, Python);
• автоматизированная генерация текста теста;
• удобная система запуска тестов из консоли.

На другую чашу весов легла стоимость лицензии 93 000 руб. (это по августовскому курсу 2650 евро).

Поскольку из конкурентов подобных вкусностей за такие деньги никто не предлагал, а аналогичных бесплатных решений я не нашел, скрепя сердце я купил лицензию.

Автор: Панкратов Вячеслав

Оригинальная публикация

Для внедрения автоматизации тестирования ПО необходимы всего три вещи:

• Мотивация руководства
• Зафиксированный и работающий процесс тестирования
• Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела

Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».

Почему?

Автор: Мартыненко Сергей

Оригинальная публикация: Часть 1, Часть 2.

Часть первая, рациональная

Эта часть статьи написана по мотивам доклада на первой конференции русскоязычного комьюнити тестировщиков 21 апреля 2007.

Под автоматизированным тестированием в этой статье понимается только и исключительно функциональное тестирование через GUI при помощи одного из инструментов: Rational Robot, QTP, TestComplete (священная корова, примерно соответствующая Oracle у DBA). Сделано это для того, чтобы не писать во всей статье оговорки.

Выбор  регрессионных автоматических тестов

Для предотвращения «расползания» кода и раннего обнаружения ошибок широко применяется практика ежедневного тестирования в автоматическом режиме.

В мировой практике наиболее распространены следующие виды тестов:

Полная "режиссерская" версия доклада, сделанного SQA Days 2008

Автор: Сергей Талалаев

Оригинальная публикация

Доклад затрагивает проблему выбора унифицированного хранилища тестовых данных для проведения автоматизированных функциональных и нагрузочных тестов.
Приводимый в докладе подход никоим образом не претендует на истину в последней инстанции и отражает лишь удачный опыт автора в практическом применения данных механизмов в ходе реализации проектов функциональной автоматизации.

Автор: Семенкин Максим

Оригинальная публикация

В последнее время пришлось довольно активно изучать вопрос функционального тестирования, поэтому довелось разобраться с инструментарием, который может быть пригоден для тестирования веб-приложений. Поскольку разработку ведем на Java, то и инструментарий подбирался соответствующий. Надеюсь, мой опыт будет полезен другим.

Автор: Михаил Давыдов

Статья изначально написана для западного заказчика по результатам предварительного evaluation IBM Rational Functional Tester (к моменту написания статьи автор уже имел продолжительный опыт работы с Mercury QuickTest Pro 6.5). Целью evaluation был (предварительный) выбор инструмента автоматизированного функционального тестирования Web-приложения, разрабатываемого для заказчика нашей компанией. Статья не претендует на исчерпывающий анализ обоих инструментов — такой цели и не ставилось. Цель статьи — проанализировать сферу применимости обоих инструментов, обозначить их наиболее сильные и наиболее слабые стороны. Приношу читателям извинения за свой, не всегда адекватный английски язык (а так же то, что я не удосужился перевести статью на русский).