Кори сандлер том баджетт гленфорд майерс искусство тестирования программ

Обновлено: 26.04.2024

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

1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.

Принцип 1: обязательная часть тестирования – определение ожидаемого результата

— описание входных данных
— точное описание корректных выходных данных для указанных входных данных.

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

Принцип 2: программистам следует избегать тестирования их собственных программ (и участков кода)

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

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

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

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

Это не значит, что путь тестирования собственных программ для программиста закрыт. Просто лучше (эффективнее), чтобы это делал кто-то другой. Разработчики могут быть полезными участниками команды тестирования, когда проводится оценка спецификации и самого программного кода.

И еще. Речь не шла о процессе дебаггинга. В этом случае автор кода является наиболее эффективным участником процесса.

Принцип 3: организациям, создающим программы, следует избегать тестирования их собственных программ

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

Следует сказать и тут, что участие организации в процессе тестирования собственных продуктов не обязательно является бессмысленным. Здесь мы говорим, что наиболее удачно с экономической точки зрения выполнять такую работу независимой стороной.

Принцип 4: процесс тестирования должен включать в себя тщательную проверку результатов каждого теста

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

Принцип 5: тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых

Это естественная и здравая тенденция – концентрироваться на допустимых и ожидаемых условия в процессе тестирования. Пренебрегать недопустимыми и неожиданными условиями также естественно, но не также здраво. Много ошибок может выявится, когда программный продукт используется неким новым или неожиданным путем. Невозможно определить все сценарии, какими пользователь будет работать с продуктом, однако что-то отличное от спокойного, привычного течения программы, кажется, имеет все шансы на успех (в деле поиска ошибок).

Принцип 6: исследование Системы на предмет того, что она не делает, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает

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

Принцип 7: одноразовые тест-кейсы для одноразовых программ, в остальных случаях следует избегать таковых тестов

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

Принцип 8: не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок

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

Принцип 9: вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок

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

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

Картинка даже есть:

Принцип 10: тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие

Бесспорно, это так. Творческие способности, необходимые для тестирования программного продукта, превышают (да там так и написано) творческие способности, необходимые для создания этого программного продукта. Существует множество методик и техник для дизайна проникновенных тестов, но все это останется не высоко, если не будут приложены творческие усилия с Вашей стороны.

Кто это?

Тестировщик (буду называть именно так, чуть позже объясню, в чём причина оговорки), он же QA-инженер (Quality Assurance) — это специалист, который проверяет качество программного обеспечения и уровень его соответствия заранее определённым потребностям и ожидаемым результатам. В своей работе он использует различные инструменты, стратегии тестирования, включается в SCRUM-команды и т.д.

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

Скажу сразу: первые несколько месяцев работы в тестировании напоминают день сурка, ты делаешь одно и то же, прогоняешь одни и те же тесты по нескольку раз, ставишь passed или failed, заводишь баги и, кажется, что это работа точно не для тебя, а скорее для школьника или мартышки. И это вот самоощущение чудовищно угнетает и столь же чудовищно неверно. Всё меняется, когда приходит опыт.

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

Далее — от нескольких месяцев до 2 лет — ручное тестирование. Вы будете выполнять большинство видов тестов в ручном режиме, начнёте составлять свои тест-планы и взаимодействовать с разработчиками. На этом этапе наступает тот самый день сурка, когда кажется, что кони бегают по кругу и дальше — рутина и скука. Это не так. В этот промежуток времени инженер по тестированию наращивает интегральное понимание тестирования, учится работать с программистами, видеть не только сам баг, но и анализировать его возможные причины. Главное, что приходит за это время — осознание того, что ручное тестирование должно остаться в прошлом веке и… настаёт время перехода к автоматизации тестирования, когда вы начинаете осваивать язык программирования (или использовать ранее освоенный) и пишете свои скрипты — те, которые считаете нужными для работы с ПО. Наступает реально крутая часть работы. (Впрочем, многие тестировщики, особенно девушки, предпочитают остановиться на ручном тестировании и стать реальными асами именно в нём — кстати, весьма полезные сотрудники и, как показывает опыт, лучшие наставники для новичков).

От 2 лет и далее — квалифицированный специалист, готовый работать в офисе и на стороне клиента, тестировать крупные проекты, а не только фрагменты и модули, глубоко знающий свою специализацию и не очень глубоко все остальные, способный работать не только с профильным ПО, но и тестировать взаимодействия внутри различных конфигураций оборудования, ПО и интеграций. Такие ребята классно и доходчиво выступают на конференциях и митапах, делятся профессиональными секретами, обучают и… думают о своём дальнейшем карьерном пути. Об этом чуть ниже.

Работа тестировщика программного обеспечения хороша тем, что можно выбрать компанию, связанную с тем, что вам интересно в какой-то перспективе: можно тестировать телефонию, софт, бизнес ПО, игры, мобильные приложения, системы безопасности и т.д. Тестируя тот или иной продукт, вы глубоко в него погружаетесь, узнаёте изнутри и в дальнейшем сможете стать разработчиком или менеджером проекта/продукта с доскональным знанием предмета.

И да, тестирование является одним из оптимальный путей начала карьеры в ИТ-сфере, доступных большинству ребят с головой на плечах. Поэтому, если хочется, но пока не ясно чего и куда, идите в ~~тестеры~~ тестировщики, быстро прояснится.

Плюсы и минусы работы тестировщиком

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

▍Плюсы

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

▍Минусы

Где нужен?

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

Любые компании-разработчики, а также поставщики программно-аппаратных комплексов (от процессоров до касс и терминалов).
Разработчики игр и развлекательных мобильных приложений.
Финтех компании: банки, брокеры, финансовые учреждения и проч.
Системные интеграторы, которые поставляют корпоративному сегменту сложные многослойные технические решения.
Нередко тестировщики ПО требуются в штат заводов, автомобильных компаний, онлайн СМИ, ритейлеров, онлайн-курсов и т.д.

Средняя заработная плата

Для специалистов ручного тестирования:

Уровень специалиста	Средняя заработная плата
Стажёр (Intern)	33 333 руб.
Младший (Junior)	44 024 руб.
Средний (Middle)	68 031 руб.
Старший (Senior)	107 203 руб.
Ведущий (Lead)	146 428 руб.

Уровень специалиста	Средняя заработная плата
Стажёр (Intern)	36 366 руб.
Младший (Junior)	61 486 руб.
Средний (Middle)	88 246 руб.
Старший (Senior)	131 222 руб.
Ведущий (Lead)	201 461 руб.

Как видите, есть все основания для того, чтобы развиваться и переходить на новый уровень тестирования.

Базовые требования к профессионалу

В этот раз таблиц с наиболее часто упомянутыми технологиями не будет, потому что методологии и инструменты тестирования от компании к компании могут здорово отличаться. Рассмотрим те навыки, без которых карьера ну совсем не получится (обратите внимание — вы их можете приобрести в ходе работы, иметь их на старте круто, но совсем не обязательно).

Опыт технической поддержки — это плотное изучение технологий в сжатые сроки, умение понимать проблемы и быстро сопоставлять их с причинами и путями решения + навыки документирования заявок. Отличная почва для старта карьеры тестировщика.
Основы программирования — желательно Java, SQL, Python, но сойдёт буквально всё.
Знание методологии Agile, умение встроиться в микро-команды.
Основы Linux.
Основы архитектуры ПК.
Модель OSI и сети (базовое понимание, знание структуры заголовков пакетов и проч.). Практически сразу потребуется свободная работа с утилитой Wireshark.
Инструменты управления тестированием — Bugzilla, Jira или любой другой багтрекер.
Selenium — инструмент для автоматизации действий веб-браузера. Очень популярный инструмент тестирования.
Желательно — понимание стратегий тестирований чёрного, белого, серого ящиков и осознание того, где вы наиболее хорошо применимы как специалист.

Кстати, если у вас совсем нет опыта, но есть немного времени, чтобы параллельно с учёбой подготовиться к будущей работе тестировщиком, у меня для вас есть три лайфхака.

Станьте QA-фрилансером, чтобы выполнять небольшие проекты по ручному тестированию. Платят мало, но вы научитесь мыслить как тестировщик, писать контрольные примеры и сообщать о результатах.
Если цель — тестирование веба (а это чаще всего), создайте свой кривой-косой, но полноценный сайт без шаблонов и готовых CMS. Так вы поймёте, как среда работает изнутри и будете знать места обитания всех типичных багов.
Найдите программу любого курса по тестированию, ищите по ней материалы и накапливайте теоретическую базу, чтобы успешно пройти первое собеседование.

Важные личные качества

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

Аналитические навыки, чтобы понимать взаимосвязи, анализировать огромные массивы данных, результаты тестов и т.д.
Управление временем и скиллы планирования — только с ними можно обеспечить высокую производительность на фоне серьёзной рабочей нагрузки.

Необходимость знания иностранных языков

Пожалуй, инженер по тестированию — редкий вид специализации в ИТ, где можно знать язык исключительно на уровне команд инструментов. Это связано с двумя важными особенностями:

очень много статей и методик переведено на русский язык;
часто объём знаний языка обусловлен именно особенностями продукта и компании — соответственно, если компания работает на англоязычный рынок, уровень нужен (например, чтобы тестировать документацию или общаться с интернациональной командой и клиентами), а если на российский рынок, то требования к языку практически нулевые.

У меня был пример, когда понадобился тестировщик со знанием японского и отдельно — со знанием немецкого в том числе для работы с клиентами (удалённо). Так вот, нашли, обучили и дали зарплату выше разработчиков в компании. Потому что специалисты уникальные. Они и сейчас не пропали :)

Где учиться

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

Принципиального обучения на инженера по тестированию в России не существует.

Лучшее обучение в этой сфере — пройти путь от стажёра до миддла или сеньора в компаниях. На фоне усилий по самообразованию — вообще идеально. Как правило, после первого полученного опыта в компании устроиться тестировщиком в другие довольно легко. Главное найти заветную первую практику :)

Лучшие книги и средства обучения

▍Книги

▍Онлайн-обучение

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

▍Полезные статьи на Хабре о самой профессии

▍Тусовки тестировщиков

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

▍Википедия

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

Будущее тестировщика

Кроме стандартного пути внутри тестирования (от стажёра к лиду), есть несколько наиболее вероятных путей развития карьеры тестировщика.

Разработка программного обеспечения — логичный и не самый сложный путь для тех, кто увлечётся языками программирования и захочет не только ковырять чужой код и готовый проект, но и создавать что-то внутри команды.
Руководитель проекта. Отличное знание проекта в целом, понимание потребностей и требований клиентов — прямой путь к этой точке.
Скрам мастер — интересный разворот, который у тестировщиков хорошо удаётся благодаря опять же знаниям проекта в целом и умениям жёстко планировать сроки работ.
Бизнес-аналитик, внедренец — денежные, но не столь технические должности для ребят с прокачанными коммуникативными навыками.

Мифы профессии

Тестировщики — это полноценные, сильные ИТ-специалисты, которые отличаются комплексным подходом к ПО и АПК, глубоким знанием продукта и умением видеть неочевидные взаимосвязи внутри разработок.

▍Тестирование — это просто поиск ошибок

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

▍Тестировщикам мало платят

▍Не применяются технические навыки

Главный совет

Здесь не будет совета, их в статье и так хватает. Я расскажу, что самое страшное в профессии тестировщика. Вот такое страшное, что до мурашек и головокружения. Самый первый самостоятельный заход на тестирование. Ты сидишь, проводишь тесты и ставишь passed, passed, passed… И ни одного, даже самого малюсенького, самого глупого и минорного бага! И ты боишься, что в тебе нет этого — видеть ошибки, отвечать за качество, находить что-то, что пошло не так. И какое же это счастье, когда находится он, первый, первая странность в заголовке пакета или первое слово интерфейса с опечаткой.

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

Друзья, а вы прошли через работу в тестировании? Каким он был, ваш первый баг или самый глупый, смешной, может, даже страшный? Время жутких историй!

50 %

Аннотация к книге "Искусство тестирования программ"

Несмотря на то что с момента выхода первого издания книги прошло уже более тридцати лет, в течение которых мир компьютерных технологий претерпел радикальные изменения, глубина и основательность изложенных в книге идей помогли ей успешно выдержать испытание временем. Обычно в книгах по тестированию программного обеспечения основное внимание уделяется конкретным методам разработки, языкам программирования или методикам тестирования, что приводит к быстрому устареванию материала. В отличие от этого книга "Искусство тестирования программ, 3-е издание" содержит сжатое и вместе с тем емкое и исчерпывающее описание принципов тестирования, справедливость которых доказана временем. Если вы разрабатываете критически важный проект, то книга послужит залогом его успеха.
Профессиональные программисты, менеджеры ИТ-проектов и студенты компьютерных специальностей найдут в третьем издании книги обновленное описание классических принципов тестирования в наиболее проблемных областях компьютерной индустрии.- Тестирование приложений для мобильных устройств: iPhone, iPad, Android и др.- Сквозной просмотр и инспекция кода без его выполнения на компьютере (прикладные аспекты обнаружения ошибок).- Тестирование удобства использования (актуальность которого возросла в связи с появлением сложных программ, ориентированных на массовый рынок).- Применение коллективного (ориентированного на пользователей и осуществляемого с их участием) подхода при разработке и тестировании приложений.- Тестирование интернет-приложений, систем электронной коммерции и гибкое тестирование.
3-е издание.

Аннотация к книге "Искусство тестирования программ"

Библия для тесторов ПО. Одна из основополагающих книг.
Достаточно широко и популярно излагаются основные принципы методологии тестирования и отладки программ. Рассматриваются вопросы психологии и экономики тестирования. Значительное место отводится методам корректировки программ.
Для специалистов, занимающихся программированием, студентов и аспирантов.

Бейзер Б. Тестирование черного ящика

формат djvu
размер 3.83 МБ
добавлен 14 июля 2010 г.

-М., "Питер", 2004 г. Книга доктора Бейзера "Тестирование черного ящика" давно была признана классическим трудом в области поведенческого тестирования разнообразных систем. В ней глубоко рассматриваются основные вопросы тестирования программного обеспечения, позволяющие отыскать максимум ошибок при минимуме временных затрат. Черезвычайно подробно излагаются основные методики тестирования, покрывающие все спектры аспектов разработки программных си.

Ван Тассел Д. Стиль, разработка, эффективность, отладка и испытание программ

формат djvu
размер 4.44 МБ
добавлен 03 февраля 2011 г.

1981г. -320с. -Москва Стиль написания программ. Рациональные методы их разработки и оптимизации. Стратегия отладки и тестирования. Книга предназначена для начинающих программистов.

Гвоздев, Мукасеева. Методичка. Специфицирование и тестирование программ

формат jpg
размер 28.14 МБ
добавлен 25 декабря 2008 г.

Методичка для курсовой работы 2 курса (3 семестр) Специфицирование программы с помошью таблиц решений; стратегии тестирования; Метод тестирования таблиц решений; Методика выполнения курсовой Работы: ограничения, блок-схемы, теория по курсачу; тестирование методами белого и черного ящиков; оформление курсача. Отфотканная методичка. Незаменим для выполонений курсача по требованиям Гвоздева и Мукасеевой. rn

Калбертсон Р., Браун К., Кобб Г. Быстрое тестирование

формат pdf
размер 4.53 МБ
добавлен 06 июля 2010 г.

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

Криспин Л., Грегори Д. Гибкое тестирование часть 2

формат pdf
размер 77.17 МБ
добавлен 17 мая 2011 г.

Архивы можно качать и читать по частям. Двое из наиболее опытных в области гибкого тестирования практиков и консультантов, Лайза Криспин и Джанет Грегори, объединились в команду, чтобы предоставить окончательные ответы на эти и многие другие вопросы. В настоящей книге они дают определение гибкого тестирования и показывают роль тестировщиков в реальных гибких командах. Вы узнаете, как использовать квадранты гибкого тестирования для идентификации п.

Липаев В.В. Тестирование программ

формат djvu
размер 7.88 МБ
добавлен 01 октября 2010 г.

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

Методичка по лабораторной работе №1

формат doc
размер 15.92 КБ
добавлен 26 мая 2005 г.

Автор неизвестен. Методические указания к лабораторной работе тестирование программ методами белого ящика’ по дисциплине технология программирования. Усвоение студентами методов тестирования логики программы, формализованного описания результатов тестирования и стандартов по составлению схем программ.

Савин Роман. Тестирование dot com

формат pdf
размер 5.26 МБ
добавлен 07 октября 2010 г.

Очень интересная книга о тестировании ПО. С примерами из жизни и юмором. Очень легко читается, а главное запоминается. Что такое баг. Цель тестирования DECODED. Искусство создания тест-кейсов. Цикл разработки ПО. Идея. Разработка дизайна продукта и создание спека. Кодирование. Исполнение тестирования и ремонт багов. Релиз. Большая картина цикла разработки ПО. Цикл тестирования ПО. Изучение и анализ предмета тестирования. Планирование тестирования.

Степанченко И.В. Методы тестирования программного обеспечения: Учебное пособие

формат pdf
размер 918.31 КБ
добавлен 26 ноября 2010 г.

/ - Волгоград: ВолгГТУ, 2006. - 74 с. Ил .15. Табл .2. Библиогр. : 18 назв. © Волгоградский государственный технический университет, 2006 Излагаются подходы и методы тестирования, начиная с проблемы определения термина "тестирование" и общих принципов и заканчивая описанием методов и стратегий тестирования. В частности, рассмотрены методы белого и черного ящика (покрытие операторов, условий, решений, комбинаторного покрытия условий и решений, эк.

Тамре Луиза. Введение в тестирование программного обеспечения

формат djvu
размер 6.57 МБ
добавлен 02 октября 2008 г.

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

Читайте также: