Перейти к содержимому

Организация автоматизированного тестирования
онлайн, начало 28 июня
Школа Тест-Аналитика
онлайн, начало 26 июня
SQL для тестировщиков
онлайн, начало 8 июля
Selenium WebDriver: полное руководство
онлайн, начало 28 июня

SALar

Регистрация: 25 сен 2003
Offline Активность: Сегодня, 12:18
*****

#97037 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству

Написано SALar 14 Ноябрь 2011 - 13:29


От водопада к Agile

"Водопад" никак и ничем не противоречит "Agile". По определению :rtfm:

Сергей, Agile и водопад были антагонистами с самого начала, то есть с зарождения agile.

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

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


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

ГОСТ 34.х никак не ограничивает кросфункциональность. Более того, как раз ГОСТ 34.602 и ГОСТ 34.603 молчаливо предполагает совмещение ролей аналитика и тестировщика.
И в то же время Agile ничего не говорит о необходимости кроссфункциональности. Другое дело такие частные случаи как SCRUM или XP. Но там ни аналитика, ни тестировщика быть не должно.

К ГОСТ-34 я лично отношусь очень несерьезно. Я его читал, и, в общем, не могу относиться иначе к стандарту, в котором разработка системы суть побочный процесс разработки документации на систему (это ГОСТ 34.601-90). Вообще они устарели на 20 лет, то есть навсегда. И если говорить о ролях, то когда они разрабатывались тестировщиков как таковых - не было. Agile сейчас в представлен в виде XP-SCRUM-Canban, о кросс-функциональности говорят они. А дальше, в реальных условиях. это кросс-функциональность получается ограниченной тем или иным образом. Например, таким как в докладе.

Вовсе нет. В ГОСТ-ах 34 серии неплохо дано целеполагание. Включая декомпозицию целей и проверку достижимости. Я бы сказал обратное. Общая культура разработки ПО на текущей момент очень сильно не дотягивает до ГОСТ-ов. Нам (и мне тоже) достаточно тяжело их использовать ввиду общей деградации культуры в последние 10-15 лет. Впрочем, это еще одна тема для настоящего полноценного холивара, слабосвязанная с исходной темой доклада.

Предлагаю не трогать Canban. Это система управления работами, созданная для V-цепочек (не имеет никакого отношения к v-модели в вашем докладе) и цепоцек смешанного типа. Созданного для производства, в котором очень много ролей, но часть производственных участков могут выполнять более одной технологической операции (аналог совмещения ролей). Система создавалась на смену системе управления Форда, которая идеально подходила для производственных цепочек A-типов и, естественно, дала сбой при расширении модельного ряда.
Тот же псевдоканбан, о котором рассказывают консультанты имеет такое же отношение к системе Таичи Оно, какое имеет морская свинка к свиньям и морю. Псевдо "канбан-доски" могут применяться для производственных цепочек только I-типа и то с некоторыми ограничениями. Впрочем, это еще одна тема для настоящего полноценного холивара, слабосвязанная с исходной темой доклада.

PS. Высказанные мной тезисы готов обсуждать на круглых столах. Мне не интересно доказать свою правоту, мне интересно разобраться в применимости и ограничениях того или иного подхода. И с вами, Максим, я с удовольствием поспорю.
  • 1


#94736 Протестировать простейший предмет

Написано SALar 26 Сентябрь 2011 - 06:02

Да, что обсуждалось я понимаю, но я не нашел. Если так, то можете натолкнуть на правильный ход мыслей для начала, хотя бы в двух словах. Что, вы, например, расчитываете услышать по поводу космической станции?

Посмотрите проект "Панбагон". Он создавался как раз для этого.

PS. Вопрос про тестирование лифта или чашки - не самый удачный вопрос на собеседовании.
Дайте на собеседовании потестировать сайт РЖД. Это может быть очень увлекательно. Если будете делать - сделайте видео, потом выложите на ютуб. Может после этого они почешутся.
  • 1


#94479 Что такое ментальная модель пользователя и как ее строить

Написано SALar 20 Сентябрь 2011 - 13:00

Вообще просто очень хочется посмотреть на любую ММП.
Собственно, покупатели к примеру интернет-магазинов, должны быть изучены вдоль и поперек.
И их ММП триста раз уж составлены.
Может быть даже существует некая классификация этих ММП для магазинов?
Типа:
- мамочка с ребенком до года
- бизнес-леди
- неработающая супруга с деньгами.

Никто не видел?

Архетипы персонажей.
* Разрабатывались для одного из веб проектов. Проект вполне реальный, но заброшенный. Проект не коммерческий. Just for fun.
* Документ писался скорее чтобы набить руку, но польза от документа достаточно ощутимая. Документ не причесывался, выкладываю as is.
* Использовался для разработки функционала и пользовательского интерфейса.
* Разрабатывался в соответствии с рекомендациями Алана Купера.

Геймеры.

Домохозяйка Нина
33 года, двое детей (один ходит в школу, другой в детский сад). Муж основную часть времени проводит на работе или отсыпается дома.
Все время, не занятое домашним хозяйством проводит около домашнего компьютера (одноклассники, "правильный шоппинг", игры). Записывая развесистые ответы в социальных сетях, наработала неплохую скорость печати.
Следит за собой, регулярно наводит "марафет".
Может включить выключить, запустить браузер, игру, пожаловаться на то что "не работает".
С компьютером познакомилась еще до замужества. Но слова Вольфенштейн или Мастер оф Мейджик душу не трогают.
Игровые предпочтения: простенькие стратегии, квесты, год-симы (максимум - the sims XXX)
Терпение: сумочку нужной расцветки, фасона и размера будет искать пока не найдет (пользуется только яндексом, ибо о других не знает и знать не хочет)
Не против писать отзывы и сообщения об ошибках, но при этом имеет невысокий технический уровень.

Офисная планктонина Георгий
25 лет, не женат, детей естественно нет.
С компьютером на вы, но не показывает этого. И вообще сидению за компом предпочел бы рыбалку и боулинг.
Умеренно следит за собой, чтобы окружающие девушки не шарахались по сторонам.
Играет преимущественно на работе, пока начальство не видит (периодически отвлекаясь на чтение новостей и прочих социальных сетей)
Игровые предпочтения: таймкиллеры, короткие action-стрелялки, которые не затрагивают мыслительные центры.
Терпение: особым терпением не отличается, быстро перескакивает с одного на другое.
Может оставить комментарий, но сопровождать его не будет.

Геймер MadSerg
Считает себя кулхацкером, но вряд ли дотягивает до скрипткиддера. Системник всегда со снятой крышкой.


Игроделы

Алексей
28 лет, профи-программист flash. Вырос из кодировщика, не очень хорошо рисует, кроме того есть проблемы с игровой
механикой. Делает хорошие аркады, но тестировать не умеет, поэтому продукт выходит, хоть и интересный, но глюкавый
и не всегда востребованный.
Имеет хороший опыт работы в фирмах с высокой культурой разработки ПО.
Игры любит, и считает что ими можно зарабатывать. Основную работу еще не бросил, но если доходы от игр будут позволять,
уйдет в свободное плавание. Интересуется теоретическими основами разработки ПО.
На ошибках учится, даже пытается на чужих. Готов воспринимать критику извне (дорос года полтора назад. до этого юзеров
воспринимал как прямую угрозу).
Помимо компьютеров и программирования имеет хобби - радиоуправляемые машинки. Гоняет с энтузиастами на выходных.

Тоха
40 лет, вольный художник и всегда им был.
До сих пор держит небольшую сеть (являясь субпровайдером), для ограниченного числа пользователей. Но из этого бизнеса постепенно вытесняется крупными провайдерами.
Берется за любую ИТ'шную халтуру (протянуть сеть, настроить 1С, поднять шлюз и т.д.) лишь бы не работать на постоянном месте.
Имеет несколько постоянных клиентов, которые его знают лет 10-15 и подкидывают постоянные заказы.

Выбор редакции.
Тоха или Нина. Скорее сего Нина, Т.к. Тоха может просто "забить" на критику.


  • 2


#93801 О "единственно правильных" вопросах на собеседовании.

Написано SALar 07 Сентябрь 2011 - 10:41

Что бы сделал мистер Фейнман?

A> Примерно так оно и происходит.
B> знаю, я неоднократно сталкивался с этим :)
A> Проблема еще и в том, что это касается не только задач на креативность, но и чисто профессиональных вопросов.
Например знает интервьюер один единственный "правильный" способ организации деревьев в реляционной базе. Ну и все. Ты попал.
B> в итоге - любое собеседование - это лотерея из серии "попал своими ответами в объем компетенций интервьюера или нет"
A> Точно. За исключением того случая, когда интервьюер находится на уровне "Ri" и знает, что не бывает неправильных ответов. Но есть области применения разных ответов. Но таких спецов мало.


Господа, кто вам сказал что "Улучшение качества ПО" или "Поиск ошибок" или "Уменьшение рисков" - это плохие формулировки целей тестирования?
  • 1


#93795 Организация работы отдела тестирования

Написано SALar 07 Сентябрь 2011 - 08:53

Т.к. у меня нету опыта работы в других компаниях, я не знаю, правильно ли организована работа.

Можно так, можно по другому. Но положа руку на сердце - мне никогда не нравилась матричная схема.


чем должен заниматься руководитель отдела?

Тем же, что и руководители других отделов. Отделов кодирования, системного анализа, юридического отдела и даже отдела по сортировке вешенок.
Очень неплохо задачи управленца изложены в работах группы Щедровицкого, но советовать это читать не буду - материал объемный и тяжелый. А вот на тренинги к ним сходить советую.
  • 1


#92178 Метрики процесса тестирования

Написано SALar 05 Август 2011 - 15:00

Скажите, пожалуйста, почему плохая. А какая, например, будет хорошей?


...
Цель контроля тестирования состоит в получении обратной связи и визуализации процесса тестирования.

Классическая ошибка целеполагания. В качестве цели стоит средство. Классика из классик. Процентов 90 целей проектов именно так и пишутся. И в итог е мы имеем то что имеем.

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

PS. Это не совсем правда. Но это правда о том, что цель очень плохая.
  • 1


#91972 Тестировщик с опытом - куда расти?

Написано SALar 02 Август 2011 - 16:00

Берите ответственность, начинайте проявлять больше инициативы, предлагайте что-то улучшать, беритесь за работу так, как-будто вы уже менеджер!

Это не менеджер.
> Берите ответственность, начинайте проявлять больше инициативы - обязанность каждого инженера
> предлагайте что-то улучшать - SEPG + прочие инженеры
На одном из проектов именно будучи инженерами мы все это и делали. А руководителю проекта показывали готовые, работающие процессы, регламенты и инструкции.


Менеджер это:
* планирование
* персонал
* прокси
* обеспечение (завхоз)
И. И почитайте про активного инженера неожиданно ставшего менеджером: http://cartmendum.li....com/83012.html
  • 1


#91971 Тестировщик с опытом - куда расти?

Написано SALar 02 Август 2011 - 15:46

Работа управленца действительно не самая интересная.
* Вам интересны интриги?
* А кропотливое, до рези в глазах планирование?
* Вы с удовольствием работаете наставником?
* Вы помните дни рождения двадцати ваших сотрудников, их жен и детей?
А ведь это основные виды деятельности управленца. Хотите? Вперед - делайте. Делайте прямо сейчас. До попадания на менеджерскую позицию. Если станете менеджером до приобретения навыков, то есть очень высокий шанс "испортить виноматериал" ( http://blog.shumoos.com/archives/236 ). Возможно, навсегда. "Безнадежен, т.к. стал менеджером слишком рано." Примеров масса.

Варианты развития "вбок":
1) Тестирование => контроль качества => обеспечение качества
Ветка дивно хороша. В конце маячит переход в SEPG.
Что рыть? Поройте "Контрольные карты Шухарта" и прочие связанные темы. Поройте финансовый и операционный аудит. Покурите ГОСТ 9126 и 28195, и связанные с ним ГОСТ-ы и статьи.

2) Тестирование => системный анализ + тестирование => бизнес анализ + системный анализ + тестирование
Ветка дивно хороша. Кросфункциональность, хотя бы и частичная - это очень, очень хорошо. Стековая система - отличная штука.
Если выйдете на третий уровень, может стать так, что вас автоматически сделают менеджером проекта, потому как: "А кого же еще!?". Со мной именнно так и было неоднократно. Я не вызывался, оно само.
Что рыть? Мой доклад с ЛАФ-2010, uml2.ru,
книги:
"Современные методы описания функциональных требований к системам" Алистер Коберн
"Разработка требований к ПО" Карл Вигерс
"Принципы работы с требованиями к программному обеспечению. Унифицированный подход" Дин Леффингуэлл, Дон Уидриг

"It's matter (блеск и нищета информационных технологий)" Николас Карр
"Бизнес со скоростью мысли" Билл Гейтс
"Поиск решения"
  • 3


#90716 Бесконечные баги

Написано SALar 04 Июль 2011 - 15:37

Да уж, век живи - век учись. Спасибо, почитаем.
По поводу корневых проблем. Бывает так, что один офис считает корневой проблемой другой офис. Тут главное удалить правильно. Точнее, найти...

Тоже мне проблему нашли. Строите диаграмму "Дерево текущей реальности" по методу из этой книги: http://www.ozon.ru/c...ail/id/5288956/ (Детмер "Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию.")
:biggrin:

PS. Это жестокий совет. Количество матана в этой книге превышает летальную дозу для большинства людей в несколько раз.
Начните с книги "Управленческие дилеммы: Теория ограничений в действии." (Шрагенхайм) http://findbook.ru/r...artner=findbook

Она сильно проще. Но и строить диаграммы она не научит как следует.


PSS. Если нет документации - это большой дефект. Тоже можно завписать.
  • 1


#90550 Нужна ли кнопка "Спасибо" на форуме

Написано SALar 30 Июнь 2011 - 18:52

зря.
  • 1


#90147 С чего начинать изучать тестирование с нуля! Помогите ПЛИЗ!

Написано SALar 20 Июнь 2011 - 19:18

Стажерам или тем кто только начинает.

Зубры из зубров могут искать работу очень просто. Они изменяют статус "в контакте" на "ищу работу". На этом их активная деятельность по поиску работы заканчивается и они просто выбирают куда пойти работать. Иногда они не утруждают себя и этим. Бывает и так. Иногда они выбирают фирму, приходят и говорят: "У вас прикольно, как насчет меня?" - и их берут.

Но для этого нужно много делать. Что же делать сейчас?

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

А если у вас еще нет работы.
Советы:
* делайте как сказал astenix
* Работайте на пользу сообщества. Чаще добровольно и бесплатно. Вам нужны связи, а не деньги.
* Идите на фрилансерские сайты, не торгуясь берите любые работы и честно указав, что вы в параллель с сотрудником нанятым за деньги, будете тестировать бесплатно. Ваш бенефит не деньги, но опыт. Единственное ваше условие - чтение ошибок более опытного тестировщика. Но именно в параллель. деньги за тестирование обязательно должен получить хоть кто-то. Не вы. Вам нужно "читатть код". Поработайте в паре, потом выпросите условие - предоставление текстов найденных вами ошибок будущему работодателю.
* Помните, не вас покупают, но вы продаетесь. По крайней мере пока.
* Учите панбагон и дописывайте его. (К Баранцевым).

Совет, который плохо работает:
* Попроситесь к зубрам или просто спецам поработать на неделю-четыре бесплатно и без оформления. Дальше за деньги. Им это невыгодно, вы едите их время, но может быть сработает. Список зубров и просто спецов не секретен, но нигде не публикуется. Или ложен. Его составление - отдельная большая задача. Трудоемкая.

Советы:
* Прямо сейчас начинайте фиксировать список людей, у которых вы бы хотели учиться/работать. С кем вы бы хотели работать. Я такой список веду.

Удачи.

PS. Некоторые люди - мои ученики. Возможно, не все они об этом знают. Если вы соответствуете некоторым притчам, вас, возможно, тоже кто-то возьмется учить.
"истинное знание не требует платы, ибо вы посвящаете ему жизнь."
Но помните. Плата за это гораздо больше, чем просто оплата тренингов деньгами. Может быть вы не сможете заплатить. Или не захотите. Я захотел.
  • 1


#90132 Бесконечные баги

Написано SALar 20 Июнь 2011 - 07:12

[*]Это первая конкретная вещь, которую мне посоветовали с момента начала поиска информации по проблеме. Спасибо.

Неправда.
1. Вам уже говорили про управление конфигурациями. Теперь ваш вопрос должен быть о том, где об этом читать. Ответ: SWEBOK ( http://swebok.sorlik...management.html ) - очень хорошо, но тяжеловато для начала. Поэтому идите на habrahabr и ищите по тегам "конфигурационное управление", "управление конфигурациями", "Версионный контроль" и т.д. Там где-то и моя статья есть.

2. Я вам уже давал ответ: Дефекты нужно править до написания кода, а не после него.. Не совсем понятно? Тогда вот развернутое объяснение: http://blog.shumoos.com/archives/230 . Опять непонятно? Э-э-э...

3. Может вам специалиста по тестированию пригласить? Алексея Баранцева, например? Благо сейчас он в основном и занимается тренингами и консалтингом.

Настоятельно рекомендую воспользоваться третьим советом. Впрочем, судя по вашим "наградам" вы в этом направлении двигаетесь.

[*]К сожалению, осмысливается тяжеловато. Легче всего поняла часть про психологию. Может быть, по той причине, что старательно пытаюсь понять, что происходит в голове у коллеги. И почему оно происходит только сейчас, а не раньше.
[*]Пока единственное, что вынесла, -- "не делайте вредное и бесполезное". И не удивительно: сомневаюсь в том, что и как делаю в данном контексте, я же не управленец. Всего лишь хочу, чтобы мне не мешали выполнять мою работу. При этом написано, что невозможно отличить хорошее от плохого заранее наверняка. А вопрос "что делать?" никуда не исчез.

Это одна из лучших (или лучшая) книга о менеджменте. Но она контринтуитивна.
В лучшем случае получится примерно так:
1. Что за чушь?
2. Да, ерунда все это.
3. Это неправда потому что: ...
4. Да но...
5. Да но как это сделать?!

Между первым и пятым вполне может пройти 3-10 лет. И вам сильно повезет, если вы не успеете стать "большим начальником" до достижения 4 или 5. пому как потом переучиваться существенно дольше, сложнее и дороже.

PS. То что описал топикстартер сильно похоже на "воронку Деминга" из этой же книги. Попытки компенсировать случайную ошибку ведут к ухудшению ситуации. Вместо этого нужно просто устранить корневые причины.
  • 2


#90104 Бесконечные баги

Написано SALar 17 Июнь 2011 - 13:53


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

И есть ли у нас пример программного продукта, доказывающего это утверждение?

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

Так, что да, у меня есть примеры.

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


И еще. Посмотрите главу 18 из книги "Пространство доктора Деминга". Потом читайте всю, книгу, но сначала туда.
  • 1


#31487 странные вопросы

Написано SALar 08 Август 2006 - 12:35

В этом форуме вы ответ вряд ли найдете.

Есть два (грубо) архетипа собеседующих вас людей.
-- Тип первый
Этот человек прочитал в одной Очень Умной Книге (Услышал На Очень Серьезном Семинаре)
Правильный Ответ на Правильный Вопрос.
Теперь он наделен эзотерическим знанием: "Есть только одна партия, тьфу, религия, тьфу, правильный ответ".
Для того, чтобы пройти это собеседование нужно просто знать, какой же ответ этот человек считает правильным.
И не вздумайте показать что вы знаете несколько решений! Если вы не угадали, у вас еще есть шанс сыграть на самолюбии: "Я не очень опытный, но ведь вы меня научите?". Если же вы сказали, что есть несколько решений и, еще хуже, указали границы применимости - все, вы враг народа, все пункты 58 статьи ваши.
Я вас уверяю, что ответ "за 9 проектов никогда не вылетал из графика " точно является неправильным. Как же так, у них ни один проект в сроки не укладывается, а тут приходит не пойми кто и субординацию нарушает.

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


Эти два архетипа очень хорошо представлены в известной басне "об измеpении высоты башни с помощью баpометpа". Заметим, что Нильс Бор получил неуд у преподавателя соответствующего первому архетипу.

PS. IMHO, применять с осторожностью. среди собеседующих из HR преобладает люди первого архетипа, из технического отдела - также больше людей соответсвующих первому архетипу, но соотношение, скорее, 60/40.
  • 1


#10613 Разновидности тестирования.

Написано SALar 28 Январь 2005 - 16:21

Достаточно?

------------------------------------------------
4.2 Типы тестов
4.2.1 Объект тестирования
Unit (Элемент) – наименьший компонент, который можно скомпилировать.
Unit testing (поэлементное тестирование) – заключается в изолированной проверке каждого отдельного элемента путем запуска тестов в искусственной среде. Для этого необходимо использовать драйверы и заглушки. Поэлементное тестировани – первейшая возможность реализовать исходный код. Оценивая каждый элемент изолированно и подтверждая корректность его работы, точно установить проблему значительно проще, чем если бы элемент был частью системы.
Драйверы – модули тестов, которые запускают тестируемый элемент.
Заглушки - заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:
• возвращаются к элементу, не выполняя никаких других действий;
• отображают трассировочное сообщение и иногда предлагают тестеру продолжить тестирование;
• возвращают постоянное значение или предлагают тестеру самому ввести возвращаемое значение;
• осуществляют упрощенную реализацию недостающей компоненты;
• Имитируют исключительные или аварийные условия.
Тестирование сборки. Проверяется корректность функционирования скомбинированных вместе элементов. Существует четыре стратегии сборки:
• Снизу вверх. Сначала следует выполнить поэлементное тестирование для компонентов, находящихся на более низком уровне, а затем перейти к высокоуровневым компонентам. Для этого метода используются драйверы.
• Сверху вниз. Высокоуровневые подпрограммы становятся драйверами для остальных элементов. В этом методе используются заглушки, имитирующие поведение низкоуровневых элементов.
• Сэндвич. Здесь комбинируются методы сверху вниз и снизу вверх.
• Большой взрыв. Объединяются все элементы. Объединяются все элементы.
System testing (тестирование системы)- Проверяется продукт в целом. После того как все програмные и аппаратные компоненты собраны, подтверждается соответствие продукта исходным требованиям проекта. При наличии полностью скомпонованной системы тестер может оценить многие атрибуты, которые нельзя оценить на более низких уровнях тестирования. Результатом даного тестирования является решение о готовности системы к выпуску. Среда тестирования должна быть как можно ближе к среде развертывания.
Integration testing – в ходе этого тестирования проверяется взаимодействие тестируемого приложения с другими приложениями.


4.2.2 По целям
Инсталляционное тестирование – основная цель, убедиться, что программное обеспечение может быть установлено при различных условиях.
• новая инсталляция,
• усовершенствование системы (upgrade),
• полная или выборочная инсталляция – при нормальных и ненормальных условиях. Недостаточное количество дискового пространства, недостаток привилегий (например, на создание директорий) и т.д.
Данные и целостность базы данных. Проверяется конистентность данных. Включает в себя проверку:
• ссылочной целостности (основной источник проблем)
• ограничений на значения параметров
• ограничений на неинициализацию значений
• ограничений на уникальность значений
Функциональное тестирование - основной тест. Проверка правильности работы. Каждая функция должна отвечать требованиям.
Тестирование бизнес-цикла - должно имитировать действия, выполняемые пользователем и охватывать все типичные операции пользователя. Как правило, тесты объединяются в единый тест сьют.
Тестирование графического интерфейса пользователя.
Тестирование производительности - скорость работы системы при идеальных условиях и максимальная нагрузка
Нагрузочное тестирование – это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).
Объемное тестирование - приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.
Стресс тестирование - поведение системы при недостатке ресурсов (дискового пространства, обрывов сети, …)
Конфигурационное тестирование - тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения (MDAC, .Net, браузеры, …).
Тестирование безопасности и прав доступа - сосредоточено на двух ключевых областях безопасности:
• Безопасность уровня приложения, в том числе доступ к данным или бизнес-функциям.
• Безопасность уровня системы, включая вход в систему или удаленный доступ к системе.


4.2.3 Способ работы с кодом
White-box test. Тестирование методом «Белого ящика». Для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность,что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.
Black-box test. Тестирование методом «Черного ящика». Для конструирования тестов используются требования и спецификации ПО. Недостатки:
• таким способом невозможно найти взаимоуничтожающихся ошибок,
• некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести и т.д.

4.2.4 Стадии тестирования
Исследовательское тестирование – Прогон приложения с целью выяснения функций приложения и их реализации для подготовки тевстовых сценариев. первый этап в принятии решения что и ка будет тестироваться. Применяется при недостаточном документировании процесса разработки (отсутствие или неполнота спецификаций, прототипов интерфейса, …)
Smoke test (проверка на дым) - Оставшийся с доисторических времен способ проверки электронного оборудования в процессе переконфигурации или ремонта, который сводится к элементарной подаче напряжения на данный модуль и визуальной проверке, нет ли искрения, дыма или других явных признаков неработоспособности.
В более общем смысле первый прогон программы (после написания или после внесения существенных изменений). Как правило используется для определения готова ли программа для передачи в тестирование и продолжается 4-8 часов.
Регрисионное тестирование – Повторное использование поднабора тестов в новой версии приложения, чтобы убедиться, что функции, которые работали в предыдущей версии системы, по прежнему работают так, как ожидалось.
Приемочное тестирование – быстрая проверка работоспособности очередного релиза. Является подмножеством функциональных тестов и состоит из типичных пользовательских сценариев, сосредоточенных на основных требованиях к функциональным возможностям. Как правило, это тестирование автоматизируют.


4.2.5 Метод выполнения.
Ручное тестирование – ввод исходных данных и проверка корректности результата производится непосредственно человеком. Слабо применимо для:
• нагрузочного тестирования
• тестирования производительности
Автоматическое тестирование - ввод исходных данных и проверка корректности результата производится специализированным ПО.
  • 3




Яндекс.Метрика
Реклама на портале