ну о нем вообщето много написано по форуму - мое описание выше

Я вот тут немного поигрался со своей информацией и тем, что опубликовано в этой теме (спасибо SALar) и выложил свою версию/видение о видах тестирования. Если есть замечания дополнения - жду с нетерпением. "Язвительные" высказывания оставляйте при себе. B)
Практическое применение вижу в качестве списка в тест плане в расширенном виде в разрезе выполняемого проекта
так как эксель формат не поддерживается в форуме то таблицу приобразовал в блоки следующего вида:
1.Вид тестирования
2.Определение
3.Цель

1.Поэлементное тестирование (Юнит тестирование), (Unit testing)
2.Юнит тестирование связано с проверкой реализации дизайна одного программного элемента (модуля, единицы и т.д.) или группы элементов, разработанные, обычно, одним программистом. заключается в изолированной проверке каждого отдельного элемента путем запуска тестов в искусственной среде.
3.Является первейшей возможностью протестировать исходный код. Оценивая каждый элемент изолированно и подтверждая корректность его работы, точно установить проблему значительно проще, чем, если бы элемент был частью системы.

1.Интеграционное тестирование (Integration testing)
2.Проверка скомбинированных компонентов прикладной программы с целью определения корректности их совместного функционирования. Компоненты могут представлять собой модели кода, отдельные прикладные программы, клиентские и серверные приложения.
3.Выявление потенциальных проблем в совместном функционировании компонент.

1.Системное тестирование (System testing)
2.Тестирование интегрированных программных и аппаратных комплексов для верификации, что система выполняет необходимые требования. Поиск факторов окружения или входных данных, которые могут вызвать сбой системы.
3.Системное тестирование предполагает запуск системы в окружении, в котором она должна выполняться.

1.Дымное тестирование (проверка на дым), (Smoke testing)
2.Первый прогон программы (после написания или после внесения существенных изменений). Как правило используется для определения готова ли программа для проведения более обширного тестирования и продолжается 4-8 часов.
3.Выявление проблем «лежащих на поверхности» - тестируется чаще всего основная бизнес логика программы.

1.Функциональное тестирование (Functional testing)
2.Проверка соответствия продукта функциональным требованиям и спецификациям.
3.Проверка соответствия продукта функциональным требованиям и спецификациям.

1.Тестирование графического интерфейса пользователя (User Interface testing)
2.Тестирование интерфейса - экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс.
3.Обнаружение ошибок в интерфейсе и поиск ошибок в функциональности посредством интерфейса.

1.Тестирование производительности (Performance testing)
2.Проверка скорости работы системы (время отклика, частота транзакций и другие зависящие от времени величины) в имитационной и реальной средах.
3.Установить реальную производительность программного продукта при созданных условиях.

1.Конфигурационное тестирование (Configuration testing)
2.Конфигурационное тестирование - тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения (MDAC, .Net, браузеры, …).
3.Проверить работоспособность системы при различных конфигурациях.

1.Инсталляционное тестирование (Installation testing)
2.Данное тестирование преследует две цели. Первая состоит в том, чтобы убедиться, что продукт может быть установлен при различных условиях – таких как: новая инсталляция, усовершенствование системы (upgrade), установка по умолчанию, полная установка, установка по выбору – при нормальных и ненормальных условиях. Ненормальные условия включают в себя недостаточное количество дискового пространства, недостаток привилегий (например, на создание директорий) и т.д. Вторая цель состоит в том, чтобы убедиться, что после инсталляции программа работает корректно.
3.Убедиться в том, что программное обеспечение может быть установлено при различных условиях.

1.Регрессионное тестирование (Regression testing)
2.Повторное тестирование после внесение изменений в программное обеспечение или в его окружение (в новой версии приложения), чтобы убедиться, в том, что функции, которые работали в предыдущей версии системы, по-прежнему работают так, как ожидалось.
3.Выявление потенциальных проблем, которые могли возникнуть в результате изменений.

1.Тестирование корректности исправления ошибок (Bug fixes testing)
2.Предназначено для отслеживания корректности исправления найденных ранее ошибок
3.Тестируем ради проверки исправления старых ошибок

1.Тестирование данных и целостности базы данных (Data and Database Integrity testing)
2.Проверяется согласованность данных. Включает в себя проверку: Тестируются данные и базы данных независимо от пользовательского интерфейса – ввод данных и работа с ними непосредственно в базе данных
• ссылочной целостности (основной источник проблем)
• ограничений на значения параметров
• ограничений на не инициализацию значений
• ограничений на уникальность значений
3.Тестируются данные и базы данных независимо от пользовательского интерфейса – ввод данных и работа с ними непосредственно в базе данных

1.Нагрузочное тестирование (Load testing)
2.Это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).
3.Убедиться в том, что система работает соответственно ожидаемым рабочим нагрузочным параметрам (какой предел работоспособности)

1.Стресс тестирование (Stress testing)
2.Является одним из разновидностей тестирования на производительность. Проверяется поведение системы при недостатке ресурсов (дискового пространства, обрывов сети и т.д.).
3.Проверка того, что система адекватно реагирует на те или иные стрессовые ситуации

1.Объемное тестирование (Volume testing)
2.Относится к тестированию производительности. Приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.
3.Цель данного тестирования заключается в определении максимального объема данных при работе системы

1.Тестирование безопасности и прав доступа (Security and Access Control testing)
2.Тестирование безопасности и прав доступа - сосредоточено на двух ключевых областях безопасности: Убедиться, что только пользователь с определенными правами имеет возможность войти в систему и выполнять строго выделенные под его роль функции.
• Безопасность уровня приложения, в том числе доступ к данным или бизнес-функциям.
• Безопасность уровня системы, включая вход в систему или удаленный доступ к системе.
3.Убедиться, что только пользователь с определенными правами имеет возможность войти в систему и выполнять строго выделенные под его роль функции.

1.Тестирование преобразования (Conversion testing)
2.Проверяется корректность конвертации данных (данные, связанные с календарными значениями – к примеру, лог с указанием даты выполнения того или иного события) из одного формата в новый формат системы.
3.Проверить переход из старого формата системы в новый.

1.Приемочное тестирование (Acceptance testing)
2.Завершающее тестирование, основанное на технических требованиях конечных пользователей/заказчиков, либо основанное на применении продукта конечными пользователями/заказчиками на протяжении некоторого ограниченного периода времени. Как правило, это тестирование автоматизируют.
3.Определение соответствует ли ПО требованиям конечного пользователя или заказчика.

1.Бета тестирование (Beta testing)
2.Тестирование, которое выполняется на стороне заказчика (потенциальных заказчиков), с целью выявления недостатков и возможного усовершенствования системы
3.Целью является выявление ошибок и сбор мнений от потенциального заказчика

1.Анализ документации (User documentation verification)
2.Анализ спецификаций на полноту и правильность, проверка документации продукта, пользовательских инструкций и пр.
3.Проверка соответствия программы с документацией

Unit testing
Integration testing
Smoke testing - (Assures that there is no severe problem that prevents further testing. Smoke tests (or Sanity Tests) are used to verify that the software build is ready for System Test (or more extensive testing).)
Function Testing
User Interface Testing
Performance Profiling
Configuration Testing
Installation Testing
Regression testing
Bug fixes testing
Data and Database Integrity Testing
Load Testing
Stress Testing
Volume Testing
Security and Access Control Testing
Failover and Recovery Testing
Conversion testing
Job stream testing
Interface testing
Acceptance testing
Beta testing
User documentation verification

о как ;)

Ну а еще можно почитать статью "Как интервьюировать тестировщика? Понаблюдайте за ним в действии."от Джоанна Ротман (Johanna Rothman) с переводом от Баранцева Алексея ;)
http://software-test...r_interview.htm

Всем, прювет.
Проблема с которой я столкнулся следующая - написание тестов для тестировщиков при приеме на работу.
Задача такая - нужно отсечь молодых, еще на этапе общения с эйчар департаментом. А потом разговаривать уже более глубоко с людями знающими и понимающими.
Поискал на форуме но ничего похожего не нашел - можт у кого был опыт составления/ прохождения подобных заморочек - жду ответа ;)))

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

P.S.S уровень нанимаемого персонала такой:

• At least 2 years experience with functional testing
• Experience with interpreting and reviewing functional designs
• Experience with making test plans, making test cases and writing test scripts
• Knowledge of and experience with XML and related technologies and specs (XSL/XSLT, XSD)
• Knowledge of browser / web technologies
• Knowledge of TMAP or similar methodology

Текрайтер из Питера: я для этого его сюда и выложил - чтобы обсудить и улучшить это задание
на чем конкретно тормозится ваш глаз???
По поводу технического писателя - поступлю подругому: отдам на растерзание нашему отделу тестирования :)) пусть во первых тест пройдут а во вторых замечания напишут

Текрайтер из Питера: сенкс за указание на ашипки ;))
Вариант сырой и писался в ноутпаде.
Все ошибки уже отредактировал при переносе в ворд ;)
PavelB: огромный респект за идею с использованием времени на прохождение тест кейса

barancev: в одном из ответов мое краткое мнение по поводу тест плана ;)))
На самом деле я планирую за каждый ответ из данного опросника давать определенное кол-во баллов
и по сумме уже решать самому эйчар ресурсу, а потом по этому тестингу и можно с человеком общаца и узнавать почему и как он думает о том или ином ответе (например о том же самом тест плане).
У большинства контор в Киеве, о которых мне приходилось слышать (но не у всех), тест план всего лишь этап для перехода на сиэмэм энного уровня, а в реалии мертвый документ.... ;(

van: спасибо за лепту ;))
Doveangel : не нашел я чагойто.... ;(
Люди добрыя можт кто видел, подскажите где искать сертификацию то..

Огромный респект, Doveangel.
По поводу дверной ручки прикол надо взять на вооружение, но тут речь идет именно о том что тест должен проходить без моего участия и баллы которые заработает тестируемый сам эйчар сможет подсчитать по бамажке - если мало, то однозначно гудбай если в пределах допустимого - пускаем дальше.

Может есть у бывалых матерых тест манагеров подобный опыт в принятии сотрудников - очень буду рад глянуть одним глазком ;)
или можт есть ссылка а то потратил уже на поиски 4 часа - в результате тока общие рекомендации.

кратко про мой тест:
Я, короче, решил построить опросник именно в виде теста - чтоб было проще оценить и просто посчитать баллы, но дело в том что сижу щаз и думаю, что ответы в опроснике очень прозрачные - и сразу видно где верный, а где нет - в одном случае; или блин немного трудноватые, что и не каждый профи тонкость сможет вычислить - в другом...
Ну и в конце добавил задачку( или вот думаю щаз вторую вставить) на составление тест кейсов.
всего получилось 8-9 заданий может мало, а с другой стороны больше 10 наверно и не надо - все остальное в усном виде раскопаем....

Doveangel, еще раз сенкс.
;))) Из вашего сообщения понял, что тест составлен как раз то что надо ;)) - для опытного тестера выглядит как мелочь и очень простая задача, а вот как для новичка?
Если его сможет пройти человек который посетил данный форум тоже отлично - кандидат интересуется и развивается ;)
Ваши тестовые вопросы тоже приму на заметку - намек такой, что надо бы добавить и парочку сложных вопросов, чтоб оценить на каком уровне тестер, я вас правильно понял?

Господа!!!!
Вы не о том! Я отлично понимаю, что надо встретиться и пообщаться, но!
Задача заключается в том, что принять уже более опытного тестировщика - умеющего писать/править скрипт для автоматизированного тестинга и понимающего, что такое тест кейс, тест план и т.д. - понимающий для чего эти документы и как с ними работать.
Требуется тестер с опытом работы около 2х лет.
Я считаю, что если человек проработал 2 года в тестинге и не знает и не собирается знать простейших вещей (не развивается) - это все равно как мартышка.... Хотя не спорю - есть конторы на которых ресурс загрузили с ног до головы и он пашет на благо конторы, но при этом у него нет времени и возможности изучит узнать, что то новое (хотя по моему это все детский лепет и отмазки) - надо подумать о целесобразности работать в таких условиях ;))

Может разговор будет более предметным если я покажу свой тест для приема "опытного тестера" на работу. Вот он:


Задание подредактировал, а то люди приходят и говорят, что уже видели и знают - не интересно ;(
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I Тест

1.

2. Что такое варианты использования (use cases)?
....

3. С какой целью пишется тест план (test plan)
 Для описания всех вариантов конфигураций при проведении тестирования
 Для описания входных данных, действий тестера и ожидаемый результат для определения того, что программа работает правильно.
 Для определения состава группы разработчиков и сроков сдачи проекта
 Для описания всех типов тестирования, группы тестирования, условия и сроков тестирования, краткое описание всех вариантов использования.

4. Хороший тест кейс состоит из следующих частей :
a) Название теста (кратко отражающее его суть).
B) Описание варианта использования (use case)
c) Шаги воспроизведения (описание действий производимых тестером при проведении теста) с последующей нумерацией каждого шага.
d) Ожидаемые результаты (что Вы собственно ждете от программы при проведении Ваших действий).
e) Полученные результаты (что получилось на самом деле).
f) Дата создания тест кейса
g) Отметка о прохождении и дата проведения теста.
h) Фамилия программиста отвечающего за данный модуль
Варианты ответа:
 a, b, c, d, e
 Все указанные пункты в обязательном порядке должны присутствовать
 a, c, d, e, g
 b, c, d, e, g, h
 a, c, e, f, g

5. Представьте себе ситуацию:
На кануне отправки финальной версии продукта Вы обнаруживаете не критичный баг, Ваши действия:


6.

7. Rational Robot это:
....

II Практические задания
1.
2.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

квадратики для отметки ответа не отобразились, но там по моему все понятно.

Вопрос к уважаемым обитателям форума:
1. может ли тестер с 1,5 - 2 х летним стажем пройти такой тест?
2. достаточно ли грамотно составлено мной задание?
3. достаточно ли правдопадобно выглядят неправильные ответы?
4. можно ли судить по результатам данного теста об уровне тестера?

Жду от вас пожелания замечания и дополнения.
С уважением, Ваш Червь ;)

Doveangel, можно ли мне получить доступ к вопросам по сертификации, или хотябы узнать, что это за сертификация чтоб копать в нужном направлении? ;)

Ну а как развиваться???? я говорю что для старта тест тима подходит именно такой подход "..взять одного - квалифицированного (и высокооплачиваемого) и несколько способных студентов..", а потом уже не жадничать и повышать зп по мере роста специалиста и компании в целом...
а таких студентов-карьеристов, чтоб 2 месяца и дальше, не так уж и много ;)

Dmitry_NJ - полносью согласен по поводу умных и тем более опытных.
И согласен с Darkus, что лучше всего взять одного - квалифицированного (и высокооплачиваемого) и несколько способных студентов, но попадаются такие конторы, которые даже вырастают, но продолжают использовать подобную модель (1 крутой + n молодых) - в ИТ компаниях люди это тот же станок+рабочий+материал на заводе и чем меньше затраты на производство - тем выгодней бизнес. Им легче взять нового студента и воспитать его, чем платить зарплату больше. Тактика, по моему, пагубная, но тем не менее многие ей пользуются... ;(

Tester: ого, а это уже антирекламма пошла ;)))
ALL : надо поглядеть нет ли от Tester в этом разделе приглашения на работу ;)))
А вообще, да, слышал я про такие трюки (про 1000$ а потом до 200) - это называется теперь "грамотный маркетинговый ход" ;)))

Dmitry_NJ: согласен ;)))
Петя очень хитрожопый парень ;)))

Единственное, что могу сказать никогда не тестируйте банкометы, в моем случае это привело всего лишь к изъятию карточки железным уродом, а приятель сказал, что потом долго доказывал в банке, что произошел сбой и он не брал денег со своей карточки... ;)

Извините, но я повторюсь:
Есть задача смоделировать более слабую машину чем есть на тест лабе (случай гос заказа - в школе к примеру для учеников стоят очень слабые тройки), кто-нибудь сталкивался с подобной проблемой?
Как ее решить?
Есть ли софт для замедления/ухудшения характеристик машины (частотные характеристики, ОЗУ, винт)?
Метрам тестинга посвящается ;)

WishAway: огромный сенкс
программа так и называется CPUkill - огромное спасибище еще раз

Уважаемые Дамы и Господа!
А вот какая конфигурация у вашего тест лаба (машины выделенные исключительно для тестирования программного продукта)?
Используете ли вы Switch?
Какие тулзы вы используете для работы на тест лабе (VMWare, Ghost etc.)

Doveangel: ну не просто ведь так я создал эту тему ;)))
У меня просто есть опыт работы с тест лабом на моей старой работе, а сейчас на новом месте хочется создать что то подобное, вот и хотел узнать чем сейчас живет тест элита ;)))
Вопросик такой: имеет ли смысл ставить сразу стойку?
Я вот сейчас вообще хочу поставить в уголке 1 монитор и два системника со свичем - для начала хватит....
заюзать Acronis+ VMWare
Компания не оч большая - всего тестировщиков я да еще 4ро ;)

И сразу еще один вопрос в рамках данной темы:
Есть задача смоделировать более слабую машину чем есть на тест лабе (случай гос заказа - в школе к примеру для учеников стоят очень слабые тройки), кто-нибудь сталкивался с подобной проблемой?
Как ее решить?
Есть ли софт для замедления/ухудшения характеристик машины (частотные характеристики, ОЗУ, винт)?

Уважаемые дамы и господа,
в разрезе этой темы вот какой вопрос возник:
Представте себе ситуацию: есть заграничный/удаленный заказчик, который хотел бы видеть результаты вашего тестирования и при этом заносил свои баги (был бы полноценным тестером). Необходима возможность подключения с любого ip. Гибкая настройка. Быстрота работы. И конечно умеренная стоимость багтрекинг системы(желательно вообще фриварная).
Какую конфигурацию багтрекинг систему выбрать лучше всего в данной ситуации? Сервер для совместной работы (свой или аренда)? Возможно уже есть некие сервисы с абонплатой (я пользуюсь вашей программой на вашем сервере с абонплатой х баксов в месяц.)? Был ли у кого нибудь проекты подобного рода и как решалась данная проблема?
С нетерпением жду Ваших ответов

Case : можна сразу с урлами ;)