Тестирование функциональности является основным видом тестирования, потому что программа в первую очередь должна работать правильно, и только после этого можно говорить о том, насколько она быстрая или удобная
Использование техник тестирования, основанных на спецификации, для покрытия путей через программу или функцию – это очень заманчивая для функционального тестирования идея. Не менее заманчиво предположить, что раз эти пути или комбинации покрыты – функциональное тестирование более или менее завершено. Моя цель – показать при помощи описанных ниже эвристик, что функциональное тестирование может – и, возможно, должно – смотреть на вещи шире, учитывая не только то, что явно прописано в требованиях или дизайн-макете. Я уверен, что при помощи этих эвристик и точек зрения можно выявить приличное количество функциональных аспектов системы.
Список основан на моем личном опыте тестирования программных продуктов. Я также благодарен Джеймсу Баху за эвристику SFDPOT, и Элизабет Хендриксон, Джеймсу Линдси и Дейлу Эмери, как создателям чит-листа эвристик тестирования.
После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Представляем доклад Глеба Рыбалко.
Популярность техник тестирования основанных на опыте набирает популярность с каждым годом. Скорее всего, Вы уже не найдете ни одного профессионала по тестированию и обеспечению качества, которому были бы не знакомы термины exploratory & ad hoc. Об этих видах тестирования пишутся книжки. Популярность этого направления уже дошла до того, что такое тестирование было включено в некоторые американские стандарты и предписания. Естественным образом такая ситуация отражается и на клиентах. Все чаще и чаще клиент сам приходит к Вам с инициативой внедрения исследовательского или ad hoc тестирования. И первое, что в таком случае хочется ответить это: «Да, да, конечно. Это нам поможет. Это же последние веяния. Давайте попробуем… «Но всегда ли исследовательское тестирование помогает?
Я дам несколько практических советов, которые помогут использовать данный вид тестирования на практике. Мы поговорим о следующих вещах:
Как определить цели данного вида тестирования на проекте
Как идентифицировать нужных людей, для команды «исследователей»
Какие тестовые артефакты действительно помогают в исследовательском тестировании
По традиции, мы публикуем лучшие, по мнению участников, выступления с наших онлайн-конференций. Сегодня мы предлагаем ознакомиться с докладом "диверсанта", пришедшего на нашу конференцию Auto ConfeT&QA 2012 "с той стороны баррикад" -- более разработчика, чем тестировщика, Николая Алименкова. Не секрет, что разработчики тоже пишут тесты, для себя, и даже придумали специальный подход к разработке, направляемый тестами - TDD (Test-Driven Development). Николай предложил перенести эту идею с уровня модульного тестирования на уровень разработки пользовательского интерфейса. Насколько удачно это получилось -- судите сами.
Несколько дней назад завершилась онлайн-конференция Auto ConfeT&QA 2012, чуть меньше месяца остается до следующей конференции -- Chief ConfeT&QA 2012.
А тем временем мы предлагаем посмотреть рассказ Алексея Баранцева о кроссбраузерном тестировании с прошлогодней "конфетки" -- конференции ConfeT&QA 2011. Вы узнаете, где именно в работе браузеров существуют различия, почему недостаточно проверять соответствие стандартам, где взять различные версии браузеров, что следует варьировать при выполнении тестов помимо версии браузера, какими онлайн-сервисами можно пользоваться для тестирования в разных браузерах. Если вы специализируетесь на тестировании веб-приложений -- уделите полчаса своего внимания для повышения квалификации, это стоит потраченного времени.
Продолжаем публикацию слайдкастов выступлений с прошедшей конференции SQA Days 8, на очереди рассказ Игоря Любина "Тестирование компонентов без пользовательского интерфейса".
Кстати, в начале своего выступления Игорь немного рассказал о своём родном городе Казани, где пройдёт следующая конференция SQA Days 9.
25 апреля 2010 года в Клубе Computer Science при Петербургском отделении Математического института РАН выступил Виктор Кулямин (ИСП РАН) с мини-курсом "Тестирование на основе моделей" (3 лекции по примерно 90 минут). В этих лекциях речь шла о том, что такое вообще тестирование на основе моделей, почему оно достаточно перспективно как подход к контролю качества современного сложного ПО, какие основные виды моделей используются в тестировании и какими методами можно эффективно строить тесты на их основе.
"Мне лично очень понравилась активность аудитории," - сказал Виктор, - "большое количество вопросов и замечаний, как во время лекций, так и после, еще почти час я отвечал на вопросы слушателей. Это при том, что люди пришли на лекции в воскресный день, потратив его практически полностью".
Слайды, сопровождавшие этот мини-курс, доступны на сайте Клуба Computer Science, кроме того опубликованы видеозаписи выступления Виктора:
В комментариях к заметке "Можно ли делить на 0,01 ?" я обещал написать отдельный пост, посвященный валидации данных, которые приложения получают извне -- от пользователя, от других программ, из файлов и т.д. Кроме того, не так давно эта тема вновь ненадолго возникла в обсуждении заметки "Проверка экранных форм". Так что, видимо, пришло время обсудить этот вопрос в деталях.
Мы рассмотрим три вопроса -- 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок.
Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.
В настоящий момент наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые сами по себе так же требуют надлежащего тестирования, описание которого рассмотрено ниже в разделе "Особенности тестирования инсталляторов.").
В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или readme файлов, шаг за шагом описывающих все необходимые действия и проверки.
В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя - это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.
Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.
Поскольку видеозапись докладов на конференции SQA Days 2008 Minsk получилась не очень удачной (на ней не видно слайдов), я в конце концов решил переделать свой доклад в формат слайдкаста (то есть презентации с наложенным звуком).
В продолжении темы сотрудничества с уважаемым ресурсом AdvancedQTP.com и с любезного разрешения автора, хотел бы представить перевод очень интересной статьи с данного сайта.
Описанный подход заслуживает права на детальное изучение и применим не только в рамках QTP, но и в любом другом средстве автоматического тестирования. Автором проведена серьезная работа с целью поиска оптимального варианта реализации тестового фреймворка с точки зрения минимизации издержек на его поддержку.
25 апреля 2010 года в 
В комментариях к заметке 
Автор: Meir Bar-Tal