Лекции по тестированию ПО

Ситуация следующая:
Мой бывший завкаф спросил, не хочу ли я рассказать магистрам про тестирование программного обеспечения. А я взял и согласился. Так что вскоре надо будет вести лекции.
Это будет часть большого курса по технологии разработки ПО, на тестирование выделено 7 лекций, 14 практик.

Пока накидал примерно следующий план:
1. Качество ПО. Критерии оценки качества. Тестирование ПО. Место тестирования в процессе разработки.
2. Виды и уровни тестирования. Тестирование «белого ящика», модульное и интеграционное тестирование (если про модульное тестирование расскажут в курсе по программированию, то эту лекцию можно пропустить)
3. Тестирование «черного ящика», системное тестирование. Функциональное тестирование.
4. Методы проектирования функциональных тестов: работа с документацией, классы эквивалентности и анализ граничных значений. Методы оптимизации количества тестов.
5. Тестовая документация. Чек-листы. Тесты, тест-кейсы, тест-планы. Отчеты.
6. Нефункциональное тестирование: тестирование документации, юзабилити, нагрузки, стресс-тестирование, тестирование уязвимостей.
7. Автоматизация тестирования. Когда и для чего применять.
8. Обзор инструментов для тестирования ПО. TMS, генераторы данных, системы для автоматизации, скриншотеры и пр.
Замечания, вопросы, предложения?

По практикам: что можно дать в самом начале, для первой лекции?

Сообщение отредактировал Freiman: 11 июля 2012 - 11:51

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

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

Эти пожелания уже тут учтены.

Темы 5 и 6 очень практически насыщенные, по каждой из них можно тренинги на несколько дней делать. А первые три темы скорее больше теоретизированы, особенно первая. Я бы исходила сразу из планов лекций, где что рассказывать. Сразу станет видно, какая сколько времени занимает и не лучше ли их перекомбинировать. К примеру, первые три слить в одну, а тест-дизайну и нефункциональным тестам выделить по две...

Всё естественно ИМХО.

Темы 5 и 6 очень практически насыщенные, по каждой из них можно тренинги на несколько дней делать.

Да, есть такое дело..
На каждую лекцию выделяется по практике + часы самостоятельной работы. Так что реально времени будет чуть побольше, особенно в связи с теоретическими лекциями вначале.

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

Я планировал рассказывать как сначала теория, чтобы было понимание, что это вообще такое, а потом уже «расширять и углублять».
Первую можно оставить «как есть», а 2-3 объединить.

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

Freiman!

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

Если это так, то я бы посоветовала ввести еще и знакомство с ГОСТ34 и ГОСТ19.
))),естественно в той части, которая к тестированию относится))!

Если это так, то я бы посоветовала ввести еще и знакомство с ГОСТ34 и ГОСТ19.
))),естественно в той части, которая к тестированию относится))!

спасибо за дополнение, ушел гуглить )

Если это так, то я бы посоветовала ввести еще и знакомство с ГОСТ34 и ГОСТ19.
))),естественно в той части, которая к тестированию относится))!

спасибо за дополнение, ушел гуглить )

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

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

ГОСТ34 имеет не самое близкое отношение к тестированию.
Среди интересного там есть "Программа и методика испытаний". Этот документ описывает как заказчику будет сдаваться функционал из ТЗ по пунктам. Например, есть требование, что в систему нужно логиниться каждому пользователю. Пишем.
Начальные условия - созданы пользователи.
Действия - запускаем программу, ждем окна ввода пароля и заведенным пользователем заходим в систему.
Результат - зашли.
Можно еще показать, что несуществующим пользователем залогиниться невозможно.

Похоже на тестирование? Похоже. Но! В ПМИ не надо писать, что вы проводите еще 70 вариантов и убеждаетесь, что и правда залогиниться в систему можно только заведенным (корректным) пользователем. То есть там описана только работа функционала по ТЗ.

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

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

Если это так, то я бы посоветовала ввести еще и знакомство с ГОСТ34 и ГОСТ19.
))),естественно в той части, которая к тестированию относится))!

спасибо за дополнение, ушел гуглить )

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

Вот примерно это у меня вчера и получилось..
К тому же где накопать актуальные ГОСТы — загадка. Все попадаются сайты сомнительного вида.

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

Хорошо бы, но в управлениии конфигурацициями я не силен.

ГОСТ34 имеет не самое близкое отношение к тестированию.
Среди интересного там есть "Программа и методика испытаний". Этот документ описывает как заказчику будет сдаваться функционал из ТЗ по пунктам. Например, есть требование, что в систему нужно логиниться каждому пользователю. Пишем.
Начальные условия - созданы пользователи.
Действия - запускаем программу, ждем окна ввода пароля и заведенным пользователем заходим в систему.
Результат - зашли.
Можно еще показать, что несуществующим пользователем залогиниться невозможно.

Похоже на тестирование? Похоже. Но! В ПМИ не надо писать, что вы проводите еще 70 вариантов и убеждаетесь, что и правда залогиниться в систему можно только заведенным (корректным) пользователем. То есть там описана только работа функционала по ТЗ.

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

)) я поэтому и написала -- попробовать здесь поговорить с практиками.
34 так, по диагонали знаю.
Но ситуацию, когда в написании ПМИ принимает участие тестировщик, легко представляю)). Достаточно логично, согласитесь?
Точно так же как и ПМИ по 19 ГОСТ-у --- тоже тестировщик скорей всего будет писать.
Поэтому знать-то хоть примерно что сие за звери, ему надо.
хм.. да и ТЗ -- разве это не аналог Требований/спецификации ПО?
А тестировать на соответствие требованиям - это вполне расхожий вариант.
Ну это - ИМХО.

Вот примерно это у меня вчера и получилось..
К тому же где накопать актуальные ГОСТы — загадка. Все попадаются сайты сомнительного вида.
Хорошо бы, но в управлениии конфигурацициями я не силен.

я на ругост лазаю http://www.rugost.com.

Это нормальная реакция на ГОСт.
Ну и представьте - каково выпускнику с ними(ГОСТами) столкнутся по приходу на работу?

Управление конфигурациями?
)) ну... а как без него?

Баги-то как-то версиям(сборкам) привязывать.
Собственно, ничего сложного.
Т.е. механизм, который позволяет четко привязать все артефакты (тесты, баги и тыпы) к весии/сборке софта.
)) ну вот тут

http://www.pmprofy.r...525-article.asp

от Адланы можете глянуть, давно не смотрела, но запомнился четкостью и понятностью))

...
Хорошо бы, но в управлениии конфигурацициями я не силен.

По управлению конфигурациями вы как минимум должны сказать: "Уровень процесса тестирования не может быть выше уровня процесса КУ. Без развития КУ внедрение тестирования бесполезно. Или вредно."

Точно так же как и ПМИ по 19 ГОСТ-у --- тоже тестировщик скорей всего будет писать

На практике да, может быть. Но вы должны понимать, что тот кто пишет ПМИ - это аналитик, высокой квалификации, требующий соответствующей оплаты. Если аналитик не может написать ПМИ, то он как аналитик не очень.


ГОСТ-ы:

• ГОСТ Р ИСО'МЭК 9126-93 - совершенно обязательно. Не знание этого ГОСТ-а для тестировщика, это как не знание PMIBOK для менеджера. Т.е. если даже название не слышали, то все очень запущено.
• ГОСТ 28195 - не показался, но почитать можно.
• 34.602 раздел 6 или 34.603
• Р 50779.42-99 - совершенно напрасно неиспользуется в QA и QC
• ГОСТ Р ИСО МЭК 12207-2010 и 34.601 - для вводной лекции пойдут

Ну и хватит для начала.

Судя по общему описанию курса, я бы предложил рассказать не про конкретные ГОСТы, а про стандарты в целом. Какие они бывают, зачем их применяют, в каких случаях что лучше подходит.