Архив рубрики 'Методы и приемы'

Байка для оруженосца- 13. Стратегия тестирования “Синдром стажера”.

Понедельник, Август 1st, 2016

- Чего звали? - ввалился в кухню Армигер.
- Естественно, чайку попить. У вас же небось чай из пакетиков. - Заяц был само гостеприимство. - Садись, вот, лимончика отрежь. Или черничного варенья положи.
- Ага, черничное варенье самое то. У, как вкусно!
- Как у тебя с проектом? - перешел к делу Шляпник.
- Все отлично. Запускаем в промышленную эксплуатацию. Вот сегодня справочники залили.
- Справочники? Серьезно? В этом малюсеньком проекте? - Сарказм Зайца явно превышал температуру за окном.
- Ну да. ОКАТО, ОКПО…
- А тебя не смутило, что вторая буква “К”, а не “С”? Почему не ОСАТО? Не ОСПО? - Шляпник, как всегда, был доброжелателен.
- Так, стоп. - И Армигер открыл крышку своего нута. - Сейчас я посмотрю.
Пока Оруженосец яндексил, все наслаждались изысканным букетом чая с Шри-Ланки.

(more…)

Пример плана тестирования

Пятница, Июнь 8th, 2012

Предисловие.

Я несколько лет применяю документы, подобные этому. Иногда пишу их в другой форме. Иногда пишу исключительно для собственного пользования (не показываю остальным участникам проекта).

Документ показал свою высокую полезность. Но. На то чтобы научиться пользоваться этим типом документом нужно время. Чтобы научиться его писать нужно еще больше времени.

Пробуйте. Возможно вам этот тип документа окажется полезен. А может и нет.

Да еще. Размер и форма должны выбираться в зависимости от размера и типа проекта. Расширенная форма приведенная ниже неплохо подходит для проектов размером “десятки человеколет” - “несколько человековеков”. Для проекта поменьше я использовал форму “две страницы А4 цветными ручками в тетради”. Тоже хорошо работало. Не факт, что приведенный ниже документ использовался в реальном проекте. Но факт, что использовались похожие документы.
Термин “план” используется в значении близком к “стратегия”. Это не календарный график и не перечень тестовых примеров.

(more…)

TrainingLabs с разных точек зрения.

Четверг, Июль 10th, 2008

Взгляд посетителей
Проблема с информацией. Невинный вопрос на секции тестирования: «Кто был на SQADays?» выявил грустную картину. Там был один человек. Но еще хуже то, что сказала одна из участниц: «Я узнала об этом событии на следующий день после того, как конференция прошла». И что делать? Как донести до потребителей информацию, которую они жаждут получить? Кстати, тем, кто ищет идею для проекта: «В Росси нет нормального, не забитого рекламой канала информации о событиях».

Столько всего вкусного! Выбор первого тренинга многих поставил перед неразрешимой проблемой. Хотелось и туда и туда и туда.

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

Через некоторое время появятся интервью с конференции и можно будет ознакомиться с мнениям участников подробнее.

Взгляд тренера
Я выбрал в качестве темы «базовые методы создания тестовых сценариев». Никаких высоких теорий о преимуществах и недостатках классических или гибких подходов или о регламентах работы. Вот такой вот примитив. Тема, которая мало обсуждается и, насколько мне известно, слабо освещена в литературе на русском языке. С другой стороны это базовые знания тест-аналитика. Очень приятно, что поднятые на тренинге вопросы вызвали живой интерес. По просьбе участников я выкладываю одно из заданий с тренинга [1].

Взгляд организатора
Как это ни грустно, но приходится признать, что сейчас в Москве проблема найти полноценный центр подготовки персонала по программной инженерии. Несмотря на внешне внушительный список в 50 учебных центров, при ближайшем рассмотрении выяснилось, что в массе своей они дают курсы по инструментам вендоров. Есть несколько УЦ, состоящих из объединившихся тренеров, которые дают интересные тренинги, но, как правило, они ограничены одной - двумя областями программной инженерии. Это могут быть модные сейчас методологии, тренинги по управлению проектами,… Но полного спектра нет. Текама предлагает достаточно много тренингов по различной тематике, но не так много готовит внутри. УЦ Люксофт разрабатывает тренинги и закрывает все или почти все области программной инженерии. Сейчас УЦ Люксофт – уникальное явление, и, думаю, в ближайшее время он станет лидером рынка не только по полноте охвата, но и по количеству отчитанных часов (если еще не стал). Никто не хочет составить конкуренцию?

[1] Напомню, о чем идет речь. Есть задание на расчетный модуль. По этому заданию написано несколько (6) алгоритмов. Один правильный, остальные с теми или иными ошибками. Требуется составить тестовый набор, проверяющий эти алгоритмы.

Порядок работы. Тестовые набор поместить в голубую область. Фреймворк покажет достаточен ли этот тестовый набор.
Файл: calc_days.zip

Автоматизированное тестирование с нуля. Часть 1.

Среда, Апрель 25th, 2007

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

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

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

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

  • Ежедневная сборка
  • Тесты компонент
  • Юнит тесты
  • Тесты приложения через GUI (с помощью специализированного инструмента тестирования, такого как QTP, TestComplete,Rational Robot,\ и т.д.)

(more…)

Сэм Канер, Джек Фолк, Енг Кек Нгуен

Среда, Май 31st, 2006

Сэм Канер, Джек Фолк, Енг Кек Нгуен

Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений.

(more…)

61 тест, который потряс программу

Среда, Февраль 1st, 2006

В свое время я написал набор тестов для приемочного тестирования критически важного функционала, состоящий из шестидесяти одного теста. Основное желание, которое владело мной при написании данного документа – создать максимальные сложности для логики программы. Именно этот подход обеспечил высочайшую эффективность набора.
(more…)

Делаем скриншот.

Среда, Январь 25th, 2006

Статья написана в связи с обилием людей неумеющих бороться с чрезмерными размерами аттачей.

(more…)

Тонкости тестирования textbox

Вторник, Август 16th, 2005

Делаем проверку на максимально возможное число символов.

На форме редактирования есть многострочное текстовое поле. В базе данных размер поля – 4096. Пробуем ввести 4097, приложение не пропускает, выдавая сообщение о превышении длины поля (или не давая делать ввод далее). Оставляем 4096 символов. Сохраняем, перезагружаем форму - все на месте.

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

Как здесь поступать при кодировании - это вопрос выходящий за рамки тестирования, нам важно помнить, что один символ в поле ввода, это не всегда один символ в БД.

PS. Подобный случай был при тестировании на платформе .Net + MSSQL.

Тестирование полей ввода

Понедельник, Июнь 13th, 2005

Для полей ввода проверяются:

  1. Обработка корректных данных
  2. Обработка граничных условий
  3. Обработка некорректных данных внутри граничных условий
  4. Обработка некорректных данных вне граничных условий
  5. Обработка сложных данных

(more…)