Сообщений в теме: 71

[Amina88]

Всем привет) Мне понравилось видео, как раз в точку))) Я просто сидела и смеялась, т.к. так оно и есть в тестировании

[Amina88]

Я приведу классификацию видов тестирования, думаю, что все поймут наконец какие виды тестирования бывают вообще. Расшифровки видов тестирования приводили еще до меня. Если что - можно добавить это, соединить воедино. Использовала материал из книги Романа Савина. Надесюь, кому-то поможет мой пост)

КЛАССИФИКАЦИЯ ВИДОВ ТЕСТИРОВАНИЯ

ПО ЗНАНИЮ ВНУТРЕННОСТЕЙ СИСТЕМЫ

Черный ящик (black box testing)
Белый ящик (white box testing)
Серый ящик (grey box testing)

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Функциональное тестирование (functional testing)
Тестирование интерфейса пользователя (UI testing)
Тестирование локализации (localization testing)
Тестирование скорости и надежности (load/stress/performance testing)
Тестирование безопасности (security testing)
Тестирование опыта пользователя (usability testing)
Тестирование совместимости (compatibility testing)

ПО СУБЪЕКТУ ТЕСТИРОВАНИЯ

Бета-тестировщик (beta tester)

ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ

До передачи пользователю — альфа-тестирование (alpha testing)
Тест приемки (smoke test, sanity test или confidence test)
Тестирование новых фунщиональностей (new feature testing)
Регрессивное тестирование (regression testing)
Тест сдачи (acceptance of certification test)
После передачи пользователю — бета-тестирование (beta testing)

ПО КРИТЕРИЮ "ПОЗИТИВНОСТИ" СЦЕНАРИЕВ
Позитивное тестирование (positive testing)
Негативное тестирование (negative testing)

ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ ТЕСТИРУЕМЫХ КОМПОНЕНТОВ

Компонентное тестирование (component testing)
Интеграционное тестирование (integration testing)
Системное (или энд-ту-энд) тестирование (system orend-to-end testing)

ПО СТЕПЕНИ АВТОМАТИЗИРОВАННОСТИ ТЕСТИРОВАНИЯ

Ручное тестирование (manual testing)
Автоматизированное тестирование (automated testing)
Смешанное/полуавтоматизированное тестирование (semi automated testing)

ПО СТЕПЕНИ ПОДГОТОВКИ К ТЕСТИРОВАНИЮ

Тестирование по документации (formal/documented testing)
Эд Хок тестирование (Ad hoc testing)

[Amina88]

Могу довести в принципе эту тему до ума, чтоб можно было оформить как статью, как предлагает Вячеслав Панкратов.

[OVA]

Тестирование скорости и надежности (load/stress/performance testing)
Тестирование опыта пользователя (usability testing)

Таки не скорости и надежности и не опыта пользователя (который вообще UX).

Но вообще:
1. Гугль все еще не переплюнут.
2. "Общество без цветовой дифференциации штанов не имеет цели. А если нет цели - нет будущего" (с). Вопрос цели все еще не понятен.

[Amina88]

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

[OVA]

Я не уверен что пытаться собрать и упорядочить over 9000 терминов это хороший способ что-то понять.

[Amina88]

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

[OVA]

Я говорю что не уверен что это хороший метод. Все.

Ну то есть это примерно как начинать учить математику с изучения всей имеющейся там терминологии. Терминологию освоить может и поможет. Понять как оно работает - нет. А скорее всего только бардак в голове усилит.

[Amina88]

Все мнения субъективны, глупо спорить о чем-то. Для одного человека - один метод эффективен, для другого - второй метод и так далее.
Лично я сравнить изучение математики не могу с изучением тестирования, так как математику мы очень долго и давно учили. И тестирование - это новое для меня, вообще новое. Если я не буду понимать, что такое тест-кейс или нагрузочное тестирование при чтении статьи или форума - смысл. А бардак в голове - это когда знания есть, но они не систематизированы. Мне данная классификация, а также терминология наоборот помогает упорядочить все что я знаю на данный момент в голове. У меня есть прекрасный пример, когда математику преподавали не систематизировано, т.е. я приходила к учительнице, мы решали разные примеры и задачи, домашнее задание. Но особо умнее я себя не чувствовала от этого. Я не чувствовала подготовки (готовилась я к поступлению в ВУЗ). Затем я прекратила занятия у нее, так как не видела смысла и заинтересованности учительницы, чтоб я стала успешнее. Мы нашли через знакомую преподавателя математики из ВУЗа. Это был мужчина. Он начал занятия со мной с проверки уровня моих знаний. Осмыслив, чего мне не хватает и каковы мои знания, он начал подготовку. Все было четко и систематично, рассчитано на период, который был. За полтора месяца он меня отлично подготовил. Я чувствовала себя гораздо спокойнее, особенно зная, что он в меня верит. В общем, я ему безгранично благодарна. Как все работает нужно понимать, когда уже хоть что-то элементарное знаешь. Вот сегодня я читала и поняла, что выбор системы автоматизации тестирования - это не так просто. Меня интересовал вопрос как выбрать среди всех систем нужную. Я прочитала, что оценивать нужно не по 1 критерию. Поняла, что это целая экономическая задача. Важно время окупаемости системы, какие виды тестов будут автоматизироваться, какие технологии должен поддерживать инструмент... В общем, в мозге у меня уже что-то прояснилось по этому вопросу. Хотя это всего лишь теория. Но это же важно. Конечно, вариант, когда ты сразу попадаешь в компанию и там на месте пытаешься на практике разобраться - хорош. Но это будет тогда сложнее. Будет кипиш в голове.

[stranger]

По моему нескромному мнению, тестирование - сугубо практическое занятие.
"Теоретики" тут просто вредны.
И логика не всегда лучший помошник. Разработчики - не дураки, и думают логически.
А вот ошибка - она не совсем логичная! Хитрая такая, никогда не знаешь где поподется!
Статья, написанная новичком у которого нет практического опыта - Хи-хи-хи!!! :)
Напишите - пришлите ссылку, обязательно почитаю! :D
Кипеш в голове - о Да! Это нормальное состояние! Особенность профессии - внимание ко всем мелочам и деталям. Привыкайте!
Разкладывать все по полочкам в голове - хорошая привычка. Но, мне кажется, жизнь окажется гораздо веселее и разнообразнее!

[SALar]

1. Гугль все еще не переплюнут.

По ссылке - нет разбивки по классификационным признакам. Получилась каша.

[astenix]

По моему нескромному мнению, тестирование - сугубо практическое занятие.
"Теоретики" тут просто вредны.
И логика не всегда лучший помошник. Разработчики - не дураки, и думают логически.
А вот ошибка - она не совсем логичная! Хитрая такая, никогда не знаешь где поподется!

Вы лучше Розенталя почитайте, что ли :) А то "поподется" вам какая-нибудь совсем уж хитрая бага, или разработчики не будут думать логически...

[stranger]

Вы лучше Розенталя почитайте, что ли :) А то "поподется" вам какая-нибудь совсем уж хитрая бага, или разработчики не будут думать логически...

:D
Не, хитрых багов не не надо! Мне, пожалуйста, попроще!

[OVA]

1. Гугль все еще не переплюнут.

По ссылке - нет разбивки по классификационным признакам. Получилась каша.

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

[barancev]

Чё вы накинулись, нормально сделано.
Предложено несколько классификационных признаков (да, могут быть и другие, ну и что) и по ним выполнена классификация.
Да, может быть не всегда полная классификация (особенно по субъекту тестирования улыбнуло :) ), но не безнадёжно.

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

Иногда даже простые перечисления полезны, в качестве чек-листа -- "а про это я не забыл? а про это? а про это?"

[Drag]

:) Правильно наш админ говорит, правильно :) У меня самой 2 начинающих тестировщика подрастают - им такое полезно, точно говорю. А про статью список - до выходных сделаю, уговорили) С разбивками по классификациям и описанием и сюда выложу.

[OVA]

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

Если бы все было так просто... Бета-тестирование белого ящика это конечно хорошо. Ровно как и приемочные тесты которые никогда и низачто не могут быть регрессионными (ручное нагрузочное тестирование обоземойнекраудсорсинг). От таких выводов приходится потом санитарию голов делать.

Хотя может оно лучше так чем вообще никак. Я подумаю над этим. Это концентрация на терминах хороша только в меру.

[SALar]

ручное нагрузочное тестирование

Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.

[Фрося]

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

Книга целиком базируется на личном опыте освоения — с нуля — профессии тестировщика и многолетней работы автора в этом качестве в интернет-компаниях США."
Ну вот про книгу Романа Савина "тестирование dot com" написано тут
http://ebook-lib.ru/...ovanie-dot-com/ .

Я могу предположить, что и классификация, базирующаяся на книге, будет ориентирована на интернет-продукты.

У меня вопрос к уважаемым коллегам.
А никто не пробовал - сначала как-то классифицировать программные продукты, а потом привязать классификацию разновидностей тестирования к типам/видам продуктов?
хм.. (мечтательно...) а если еще и статистику собрать.
Ну типа -- программные продукты класса "Игры". ХХ% игр тестируются такими-то разновидностями, УУ% - такими-то.

[Фрося]

Еще мысль. Недодуманная))).
Есть такой документ "Методика составления спецификаций требований к программному обеспечению (IEEE-830-1998)".
Там приведены разные способы организации спецификации.
И у меня появилась мысль -- а будет ли эти различные способы оказывает влияние на процесс тестирования?
Т.е. будет ли как-то оказывать влияние на процесс тестирования то, что
спецификация организована по режимам (шаблон А1) или по по объектам (шаблон А4)?