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

• Scrum Master
• Product Owner
• Team

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

• Создает атмосферу доверия,
• Участвует в митингах в качестве фасилитатора ((англ. facilitator — «посредник») — человек, занимающийся организацией и ведением групповых форм работы с целью повышения их эффективности. Задача фасилитатора следить за регламентом и способствовать комфортной атмосфере, сплочению группы и плодотворному обсуждению. Группы поддержки и взаимопомощи относятся к тем видам групповой работы, при которых необходимо присутствие фасилитатора.)
• Устраняет препятствия
• Делает проблемы и открытые вопросы видимыми
• Отвечает за соблюдение практик и процесса в команде
• ведет Daily Scrum Meeting
• отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте
• может также помогать Product Owner создавать Backlog для команды

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

Обязанности Product Owner таковы:

• Отвечает за формирование product vision
• Управляет ROI ( (от англ. Return on Investment), также известен как ROR (от англ. Rate of Return) — финансовый коэффициент, иллюстрирующий уровень доходности или убыточности бизнеса, учитывая сумму сделанных в этот бизнес инвестиций.)
• Управляет ожиданиями заказчиков и всех заинтересованных лиц
• Координирует и приоритизирует Product backlog
• Предоставляет понятные и тестируемые требования команде
• Взаимодействует с командой и заказчиком
• Отвечает за приемку кода в конце каждой итерации
• ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

Команда является самоорганизующейся и
самоуправляемой. Команда берет на себя обязательства по выполнению
объема работ на спринт перед Product Owner. Работа команды оценивается
как работа единой группы. В Scrum вклад отдельных членов проектной
команды не оценивается, так как это разваливает самоорганизацию команды.

Обязанности команды таковы:

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

Команда в Scrum кроссфункциональна. В нее входят люди с различными навыками - разработчики, аналитики, тестировщики.  Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи. Для облегчения коммуникаций команда должна находиться в одном месте (colocated).
Артефакты
Product Backlog
Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.
Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д.. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добить всем памяти"


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


Sprint Backlog
Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.

или


Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

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

Спринт (Sprint)
В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней).

Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает  возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.

Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта.

Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Жизненный цикл спринта
Планирование спринта
В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.

Планирование спринта состоит из двух последовательных митингов.

Планирование спринта, митинг первый
Участники: команда, Product Owner, Scrum Master, пользователи, менеджемент
Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.

Артефакт: Sprint Backlog
Планирование спринта, митинг второй
Участники: Скрам Мастер, команда

Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность.

Артефакт: в Sprint Backlog появляются задачи

Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.

Остановка спринта (Sprint Abnormal Termination)
Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла.

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


Daily Scrum Meeting
Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга - поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга.


Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды

• Что сделано вчера?
• Что будет сделано сегодня?
• С какими проблемами столкнулся?

Демо и ревью спринта
Рекомендованная длительность: 4 часа

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


Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет.

Подготовка к митингу не должна занимать у команды много времени (правило - не более двух часов). В частности, именно поэтому запрещается использовать презентации в Power Point. Подготовка к митингу не должна занимать у команды более 2-х часов.


Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:
Individuals and interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaborationover contract negotiation
Responding to changeover following a plan


That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Источник:
http://citforum.ru/SE/project/scrum/
http://www.genon.ru/GetAnswer.aspx
http://agilemanifesto.org/
http://www.osp.ru/os/2007/04/4220063/

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

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


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

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

Если посмотреть на эти три процесса с точки зрения вопроса, на который они дают ответ, то тестирование отвечает на вопрос "Как это сделано?" или "Соответсвует ли поведение разработанной программы требованиям?", верификация - "Что сделано?" или ""Соответствует ли разработанная система требованиям?", а валидация - "Сделано ли то, что нужно?" или "Соответствует ли разработанная система ожиданиям заказчика


Источники:
http://www.intuit.ru/department/se/verify/class/free/

Microsoft Solutions Framework (MSF)
это методология ведения проектов и разработки решений, базирующаяся на принципах работы над продуктами самой фирмы Microsoft и предназначенная для использования в организациях, нуждающихся в концептуальной схеме для построения современных решений [35].Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.
MSF состоит из двух моделей:

• модель проектной группы;
• модель процессов,

и трех дисциплин:

• управление проектами;
• управление рисками;
• управление подготовкой.

В MSF нет роли "менеджер проекта" и иерархии руководства, управление разработкой распределено между руководителями отдельных проектных групп внутри коллектива, выполняющих следующие задачи:

• Управление программой
• Разработка
• Тестирование
• Управление выпуском
• Удовлетворение потребителя
• Управление продуктом

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



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


Треугольник приоритетов в MSFТреугольник приоритетов является основой для матрицы компромиссов - заранее
утвержденных представлений о том, какие аспекты процесса разработки будут четко заданы, а какие будут согласовываться или приниматься как есть.
Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF - Microsoft Visual Studio 2005 Team Edition. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы.
В состав Visual Studio Team Edition входит специальная редакция для тестировщиков - Team Edition for Software Testers.

Rational Unified Process
- это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.
RUP обеспечивает строгий подход к распределению задач и ответственности внутри организации-разработчика. Его предназначение заключается в том, чтобы гарантировать создание точно в срок и в рамках установленного бюджета качественного ПО, отвечающего нуждам конечных пользователей.
RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования и процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.
RUP организует работу над проектом в терминах последовательности действий (workflows), продуктов деятельности, исполнителей и других статических аспектов процесса, с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО (milestones), т.е. в терминах динамических аспектов процесса - с другой. [29]

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

• командную работу с тесными связями внутри команды и с заказчиком;
• разработку наиболее простых работающих решений;
• гибкое адаптивное планирование;
• оперативную обратную связь (путем модульного и функционального тестирования).

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

• Планирование процесса
• Частые релизы
• Метафора системы
• Простая архитектура
• Тестирование
• Рефакторинг
• Парное программирование
• Коллективное владение кодом
• Частая интеграция
• 40-часовая рабочая неделя
• Стандарты кодирования
• Тесное взаимодействие с заказчиком

Сравнение технологий MSF, RUP и XP
из приведенной ниже таблице можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.
Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP - сопровождаемость. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации.

Технология	Оптимальная команда	Соответствие стандартам	Допустимые технологии и инструменты	Удобство модификации и сопровождения
Rational Unified Process	10 - 40 чел.	стандарты Rational	UML и продукты Rational	Удобно (RUP)
Microsoft Solutions Framework	3 - 20 чел.	адаптируема	любые	Удобно (MSF+MOF)
XP	2 - 10 чел.	стандарты отсутствуют	любые	Сложно (зависимость от конкретных участников коллектива)

Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.

Источники:
http://www.intuit.ru/department/se/verify/class/free/

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

V образная модель


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

Спиральная модель

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

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


Сравнение различных типов жизненного цикла

Тип жизненного цикла	Длина цикла	Верификация и внесение изменений	Интеграция отдельных компонент системы
Каскадный	Все этапы разработки системы. Длинный	В конце разработки всей системы. Изменения вносятся редко	Четко определенные до начала кодирования интерфейсы
V-образный	Все этапы разработки системы. Длинный	В конце полной разработки каждого из этапов системы. Изменения вносятся со средней частотой	Редко изменяемые интерфейсы
Спиральный	Разработка одной версии системы. Средний	В конце разработки каждого из этапов версии системы. Изменения вносятся со средней частотой	Периодически изменяемые интерфейсы, редко меняемые в пределах версии
XP	Разработка одной истории. Короткий	В конце разработки каждой истории. Изменения вносятся очень часто	Часто изменяемые интерфейсы

Источники:
http://www.intuit.ru/department/se/verify/class/free/

Рассматривается процесс тестирования в составе современных CASE-средств c целью выявления систематизации и оценки используемых метрик

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

Для оценки и управления качеством при производстве ПП необходимы метрики, которые должны давать количественные оценки качества конечного продукта. В настоящее время CASE-средства собирают и анализируют некоторые метрики, используемые как для оценки качества ПП, так и для оценки результативности процесса тестирования. К таким средствам ,прежде всего, следует отнести Rational Suite компании Rational Software, входящей в состав корпорации IBM с февраля 2003 года, и Together Control Center компании Together Soft, являющейся ныне подразделением Borland. Однако отмечаются проблемы в метрическом обеспечении тестирования в частности это касается критериев завершения тестирования В связи с этим нами предпринят анализ и систематизация метрик, используемых в CASE-средствах.


Множество метрик процесса тестирования будем разделять на два класса:

• первичные или накопительные метрики
• вычисляемые метрики

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


В отличии от первичных метрик, которые не применяются для управления тестированием, вычислимые метрики позволяют оценить результативность процесса.



Из сказанного выше видно что для оценки готовности ПП в современных,CASE-средствах используется метрика, основанная на анализе тестового покрытия. Однако существуют проблемы в определении первичных метрик, необходимых для ее вычисления. Существующие метрики, используемые в CASE-средствах, в основном, сводятся к учету дефектов, времени и затрат и поэтому непригодны для оценки готовности продукта и, тем самым, не являются критерием завершения тестирования. Несмотря на это, о применении следует сказать более подробно. В зрелых компаниях по разработке ПО, которые используют в качестве средств управления проектами MS Project 2000 или
Primavera Enterprise, эти данные составляют статическую основу для планирования проектов и управления ими. Для примера сошлемся на модель качества CMM, где необходимым условиям является ведение и анализ статистики проекта,которая иногда называется Knowledge Base. Что касается возможных направлений исследований, то внимание концентрируется на оценке рисков в случае неполного тестирования (т. е. управление тестированием с учетом рисков) и исследовании методологий,основанных на попытках поиска наиболее "важных" тестов, т е исследовании методов
ранжирования тестов в зависимости от важности (приоритетности) требований.

Конфигурационное тестирование
Предназначено для проверки правильности работы на различных программных и аппаратных окружениях.
Автоматизированное тестирование 2
Составная часть процесса тестирования. Использует специальные приложения для проведения тестов. что помогает сократить время тестирования и упростить процесс.
Инструмент для автоматизированного тестирования (Automation Test Tool)
ПО, по средствам которого специалист по автомат. тестированию осуществляет создание, отладку, выполнение и анализ тест скриптов.
Тест скрипт (Test Script)
Набор инструкций, для автоматической проверки определенной части ПО
Тестовый комплект
Набор тест скриптов, для проверки определенной части ПО, объединенной общей функциональностью или целями, преследуемыми запуском данного набора.
Автономное тестирование
Тестирование нижнего уровня, компонент, модулей, подпрограмм. Может быть внутренним приемочным тестированием.
Альфа тестирование
Тестирование штатными работниками либо заказчиком на стороне разработчика.
Артефакт
Семантически законченная часть информации, которая формируется, изменяется или используется процессами, определяет область ответственности.
Семантика
(фр. sémantique от др.-греч. σημαντικός — обозначающий), также семасиология — наука о понимании (значении) определённых знаков, последовательностей символов и других условных обозначений; раздел семиотики.
Бета тестирование
 Распространение среди пользователей готовой версии продукта с ограничениями (по функциональности или времени работы), с целью выявления и устранения максимального количества ошибок.
Гамма тестирование
Тестирование по отчетам пользователей
Заглушка
Компонент, содержащий функциональность, необходимую при тестировании. Это либо полностью пустышка, либо просто возвращает предопределенное значение или имитирует более сложное поведение.
Инсталлятор
Программа, основные функции которой - Установка (инсталляция), обновление и Удаление (Деинсталляция)
Инсталляционное тестирование2

1. Проверка корректной установки системы при различных условиях с ПО и ресурсами. Проверка работы системы при апрейде со старой версии на новую, так же как и установки с нуля.
2. Направлено на проверку успешной инсталляции и настройки а также обновления или удаления ПО.

Миграционное тестирование
Проверка правильности работы функций и процедур, конвертирующих данные для последующего использования в других приложениях
Модульное (Unit-) тестирование2
Тестирование отдельных компонентов, изолируя модули от их реального окружения. Служит для проверки правильности работы отдельных модулей системы, как правило - классов.
Нагрузочное/стрессовое тестирование2
Тестирование предназначено для проверки работоспособности системы при нестандартных нагрузках и для определения максимально возможного пика, при котором система работает правильно, и выявления результатов, при которых система переходит в нерабочее состояние.
Оценка качества ПО
Оценка производится для того, что бы заказчик мог понять,  в каком состоянии находиться система в данный момент и какие шаги на основании этого можно предпринимать в дальнейшем для ее улучшения.
Патч
Экземпляр ППО (или подпрограммное обеспечение, или прикладное по), являющийся обновлением, выпущенным для исправления ошибок, обнаруженных  в версии или релизе ППО. В состав патча входит исполняемый код и описание исправленных в патче ошибок. Патч может распространяться без документации.
Покрытие кода
Это тестирование "белого ящика". Тестируемое ПО собирается со специальными настройками ил библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется ее местонахождение в исходном коде. Это процесс позволяет определить части системы. которые, при нормальной работе, используются очень редко или никогда (например: код обработки ошибок).
Система отслеживания ошибок
Прикладная программа, разработанная с целью учета и контроля за ошибками, найденными в программах, и отслеживания процесса устранения этих ошибок
Системное тестирование2
Высокоуровневая проверка функционала всей программы.
Скрипт
Общие условия проведения тестирования (сценарий тестирования) при ручном тестировании. текст программы для выполнения автоматизированных тестов.
Статическое тестирование
Тестирование без реального выполнения программы
Тест
Выполняемая тестовая процедура с конкретными входными данными. начальными условиями и ожидаемым результатом, разработанными для определенной цели, такой как проверка отдельной программы ил верификация соответствия на определенное требование.
Тест-план 2
Полное описание функционала системы с отражением всех требований к ней. как правило описывает только реальные требования к системе. Является гарантом того, что система в целом работает правильно.
Тестирование белого ящика
Тестирование на соответствие ПО требованиям с знанием внутренней структуры реализации системы (исходный код и тех.спецификация в наличии).Позволяет проводить локализацию ошибок, анализ надежности и устойчивости и т.п.
Тестирование черного ящика
Тестирование на соответствие программы требованиям без знания внутренней структуры реализации системы.
Тестовое покрытие2

1. Мера полноты тестирования для определенной стратегии. Степень, до которой с помощью контрольных примеров проверяют требования к системе или программному продукту.
2. отношение планируемого тестового набора к полному тестовому набору

Техническое задание
Документ, используемый заказчиком в качестве средства для описания и  определения задач, выполняемых при реализации договора.
Управление дефектами
Базовое понятие тестирования, которое включает в себя документацию по тестированию и необходимые документы для описания найденных дефектов.
Функциональное тестирование2
Проверяет, что система работает в точности, как и описано в спецификации (требованиях к системе)
Юзабилити тестирование2
Предназначено для оценки удобства пользования системой и соответствующих рекомендаций по ее улучшению.
Риски некорректной работы исталлятора

• Потеря пользовательских данных
• вывод ОС из строя
• неработоспособность приложения
• не корректная работа приложения

CRUD операции
Базовые операции создания, чтения, изменения, удаления сущностей.
CASE-средства (от Computer Aided Software/System Engineering)
позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат использования CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.
Накопительные (первичные) метрики
Числовые значения показателей, полученные на этапе тестирования ПО. (время, стоимость тестирования, количество дефектов)
Вычислимые метрики
Вычисляются на основании первичных метрик. (тестовое покрытие, количество дефектов на строку исходного кода, результативность тестирования)
Подготовка тестирования
Деятельность по планированию, разработке тестовых действиий и развертыванию тестовой среды
Выполнение тестирования
Тестовые прогоны и документирование результатов тестирования
Объем тестирования
планированный тестовый набор, выраженный в количестве разработанных тестов.
Структурное тестирование
тестирование программы в соответствии с принципом “белого ящика”, при котором известна структура программы и доступен исходный код. Тестируются блоки ветвлений, циклы и т.д.
Типы Структурного тестирования
1) покрытие операторов,2) покрытие решений, 3) покрытие решений / условий, 4) комбинаторное покрытие условий, 5) тестирование циклов.
Плотность ошибок
Общее количество дефектов, обнаруженных в ПП, в пересчете на количество строк в исходном коде
Результативность тестирования
Отношение количества дефектов, найденных на этапе тестирования, к общему числу дефектов, найденных на этапе тестирования и эксплуатации.
План работы над тест-дизайном

• Анализ проектных артефактов: документация (спецификации, требования. планы), модели, исполняемый код и т.д.
• Написание спецификации по тест дизайну
• Проектирование и создание тестовых случаев

Подходы к оценке и измерению тестового покрытия

1. Покрытие требований - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матрицы трассировок (traceability matrix)
2. Покрытие кода - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей ПО

Различия: метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, а анализ покрытия кода - на полноте проверки тестами, разработанной части продукта (исходного кода)
Покрытие требований
Расчет проводиться по формуле:
Где
T_cov-тестовое покрытие
L_cov - количество требований, проверяемых тесткейсами
L_total - общее количество требований
Покрытие кода
Расчет проводиться по формуле:

Где
T_cov-тестовое покрытие
L_tc - количество строк кода, покрытых тестами
L_code - общее количество строк кода
Техники тест дизайна
Эквивалентное разделение (Equivalence Partitioning - EP), Анализ граничных условий (Boundary Value Analysis - BVA), Причина/следствие (Cause/Effect - CE), Предугадывание ошибок (Error Guessing - EG), Исчерпывающее тестирование (Exhaustive Testing - ET)
Класс эквивалентности (Equivalence class)
это набор значений переменной, который считается эквивалентным. Тестовые сценарии эквиваленты, если a) они тестируют одно и тоже; b) Если один из них выявляет ошибку, то и остальные выявят ее; c) Если одни из них не выявляет ошибку, то и остальные не выявят.
Эквивалентное разделение (Equivalence Partitioning)
Рассматриваемая область приложения разделяется на коллекцию наборов или
эквивалентных классов, которые считаются эквивалентными с точки зрения
рассматриваемых связей и характеристик. Для теста выбирается одно значение внутри интервала допустимых значений, и одно -вне интервала.
Анализ граничных значений (Boundary value Analysis)
Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Для тестов берется минимальное и максимальное значение класса, а так же значения болье  и меньше границ.
Причина/следствие (Cause/Effect)
Ввод комбинаций условий (Причин,) для получения ответа от  системы (Следствие)
Предугадывание ошибки (Error Guessing)
Использование знаний системы и способность к интерпретации  спецификации на предмет "предугадывания" при каких входных условиях система может выдать ошибку.
Исчерпывающее тестирование (Exhaustive Testing)
Проверка всех возможных комбинаций входных значений.
Необходимыми условиями истинности утверждения А
называют условия, без которых А не может быть истинным
Достаточными условиями истинности утверждения А
называют условия, при наличии (выполнении, соблюдении) которых А является истинным
Необходимые условия тестирования

1. наличие объекта тестирования, доступного, для проведения испытаний
2. наличие исполнителя (человека, машина)

Достаточные условия тестирования

1. наличие объекта тестирования, доступного, для проведения испытаний
2. наличие исполнителя (человека, машина)
3. наличие плана тестирования
4. наличие тест-кейсов/тестов
5. наличие отчета, подтверждающего выполнение задач и достижения целей, по тестированию объекта./li>

Тестовые артефакты
План тестирования, Набор тест-кейсов и тестов, Дефект/Баг репорты.
Набор тестовых случаев (Test case suite)
набор связанных тестов, как правило, относящихся к  одной группе функций или программных компонентов и, как правило, определенных одной и той же базой данных. Эти наборы могут объединяются в группы.
Набор тестов (Test suite)
набор  из одного или нескольких тестов для программного обеспечения в стадии тестирования. В Test Suite‘ах обычно хранятся тестовые кейсы для тестирования различной функциональности продукта.
Серьезность дефекта (Severity)
атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет дефекта (Priority)
атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Чем выше  - тем быстрее нужно исправить.
Серьезность дефекта: Блокирующая (Blocker)
Ошибка, приводящая приложение в неработающее состояние,  в результате которого, дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы
Серьезность дефекта: Критическая (Critical)
Ошибка, неправильно работающая ключевая бизнес-логика. дыра в системе безопасности, проблема, приведшая к временному падению сервера или приведшая в нерабочее состояние некоторую часть системы , без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системы.
Серьезность дефекта: Значительная (Major)
Ошибка, при которой часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность работы для работы с тестируемой функцией, используя другие входные  точки.
Серьезность дефекта: Незначительная (Minor)
Ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
Серьезность дефекта: Тривиальная (Trivial)
Ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее
Верификация2
Процесс определения. выполняют ли программные средства и их компоненты требования, наложенные на них в последовательных этапах жизненного цикла разрабатываемой программной системы.
Жизненный цикл разработки

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

...



дАЛИ БУДе

Источники:
http://www.protesting.ru/testing/types/configuration.html
http://ru.wikipedia.org/
http://www.intuit.ru/department/se/intuml/7/
http://www.rsdn.ru/article/testing/SoftwareTesting.xml
http://www.mista.ru/isu/index.htm
http://www.protesting.ru/testing/testdesign.html
http://www.it4business.ru/lib/42/
http://sqalife.blogspot.com/2009/05/aka-equivalence-partitioning.html
http://testitquickly.com/2007/06/25/46/
http://www.intuit.ru/department/se/verify/class/free/1/

Функциональное тестирование
Функциональное тестирование рассматривает заранее указанное поведение системы и основывается на анализе спецификаций функциональности компонента или системы в целом.
Функциональные тесты базируются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования: компонентном/модульном, интеграционном, системном, приемочном. Как правило, эти функции описываются в спецификациях функциональности, или в виде случаев использования системы (use case)
Функциональное тестирование - это тестирование функций приложения на соответствие требованиям.
Оценка производится в соответствии с ожидаемыми и полученными результатами (на основании функциональной спецификации), при условии, что функции отрабатывались на различных значениях.
Тестирование функциональности может проводиться в следующих аспектах:

• Требования. Используется спецификация функциональных требований к системе как основа для тестовых случаев. В этом случае необходимо сделать список того, что будет протестировано, а что - нет. приоритезировать требования на основе рисков (если это не сделано в документации с требованиями ранее), и на основе этого приоритезировать тест кейсы (тестовые сценарии). (Test Case)
•  Бизнес-процессы Тестирование в перспективе "бизнес-процессы" использует знание этих бизнес процессов, которые описывают сценарии ежедневного использования системы. В этой перспективе, тестовые сценарии основываются, как правило на случаях использования системы (use case).

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

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

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

Тестирование безопасности (Security and Access Control Tesing)
Стратегия тестирования, используемая для проверки безопасности системы, а так же для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Тестирование безопасности основывается на трех основных принципах:

• Конфиденциальность (confidentiality) Это сокрытие определенных ресурсов информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей.
• Целосность (integrity)существует 2 основных критерия при определении понятия целостности:
• Доверие Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей.
• Повреждение и восстановление В случае когда данные меняются авторизованным или неавторизованным пользователем, необходимо определить насколько важно является процедура восстановления данных.
• Доступность представляет собой требование о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Чем более критичен ресурс, тем выше уровень доступности должен быть.

Другое видение

Тестирование безопасности представляет собой ряд услуг от разработки политики безопасности до тестирования безопасности на уровне приложения, ОС и сетевой безопасности.
Может иметь различную степень покрытия:

• Первичное тестирование безопасности;
• Полное тестирование приложения;
• Полное тестирование приложения и сервера.

Аспекты в зависимости от покрытия:

• Тестирование контроля доступа - дефекты, в результате которых пользователь получает несанкционированный доступ к объектам и функциям приложения;
• Тестирование авторизации - дефекты авторизации пользователей и их групп и проверки подлинности;
• Тестирование валидации ввода - проверка валидации данных серверов до того, как они попадают в приложение.
• Тестирование надежности шифрования данных - дефекты, свзанные с шифрованием и расшифровкой данных, использованием цифровых подписей и проверкой их подлинности;
• Тестирование правильности обработки ошибок - проверка: вывод на экран фрагментов кода при ошибке, влияние ошибок на работу всего приложения, раскрытие излишней информации о сбое в работе;
• Тестирование на переполнение буфера - выявляет ненадлежащее раскрытие данных. 
• Тестирование конфигурации сервера - ошибки в многопоточных средах, в результате которых могут быть повреждены или использованы совместно (пременные, совместно используемые разными потоками и приводящие к дефектам типа "time-of-check-time-of-use", некорректные шаблоны проектирования "Singleton" и плохое построение кэша)

Тестирование взаимодействия (Interoperability Testing)
Это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (Integration testing)

Тестирование совместимости (compatibility testing) — метод, основной целью которого является обеспечение качественной работы конечного продукта с другим программным обеспечением.
Интеграционное тестирование (Integration testing) — одна из фаз тестирования программного обеспечения, при котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

Нагрузочное тестирование
В нагрузочное тестирование входят следующие тесты:

• Тестирование производительности(Performance testing);
• Стрессовое тестирование (Stress testing);
• Объемное тестирование (Volume testing);
• Тестирование стабильности или надежности (Stability/Reliability Testing).

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

Cанитарное тестирование (Sanity Testing)
или тестирование согласованности/исправности. Узконаправленное тестирование достаточное для доказательства работоспособности отдельной функции согласно спецификации требований, после изменений в ней или окружении.
В отличии от дымового тестирования, санитарное тестирование направлено вглубь тестируемой функции, а дымовое - вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.

Тестирование сборки (Build Verification Test)
Тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. Аналог Дымового тестирования,  вглубь оно может приникать дальше, в зависимости от требований к качеству выпущенной версии.

Регрессионное тестирование (Regression testing)
Тестирование направленное на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта. слияние кода, миграция на другую ОС, БД, веб сервер или сервер приложения) для подтверждения того факта, что существующая ранее функциональность работает как и раньше. Регрессионными могут быть тесты как функциональные так и нет.
Для регрессионного тестирования используют ТС,   написанные на ранних стадиях разработки  и тестирования. Это дает гарантию, что изменения в новой версии не повредили уже существующую функциональность.
Типы регрессионного тестировния по С. Кенеру:

1. Регрессия багов (Bug Regression) - попытка доказать, что исправленная ошибка не исправлена
2. Регрессия старых багов (Old  bugs regression) - попытка доказать, что недавнее изменение кода или данных привело в воспроизведению старых ошибок
3. Регрессия побочного действия (Side effect regression) - попытка доказать что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.

Тестирование установки (Installation testing)
Тестирование направленное на проверку успешной инсталляции и настройки, а так же обновления или удаления ПО.
В распределенных системах, где система разворачивается на уже работающем окружении, зачастую пишется план установки (Deployment Plan), включающий не только шаги по инсталляции, но и шаги отката (roll-back) к предыдущей версии, в случае неудачи. Сам по себе, план установки должен пройти процедуру тестирования.
Такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталяции, можно назвать тестировнием установки

Тестирование процедур установки и механизмов лицензирования  (Installation and Licensing testing)
Тестирование процедуры установки разделяется на следующие этапы:

• Формальное тестирование программы установки (графический интерфейс пользователя, общее удобство пользования, соответствие стандартам)
• Функциональное тестирование программы установки
• Тестирование механизма лицензирования и способности противостоять взлому
• Проверка стабильности работы приложения после установки

Формальное тестирование программы установки

• Формальное тестирование графического интерфейса
• Тестирование навигации
• Тестирование удобства пользования
• Тестирование региональных и языковых настроек
• Выявление любых ошибочных ситуаций :)
• Проверка доступности контактной информации

Функциональное тестирование программы установки

• Тестирование различных опций установки

• Типы установки (типичная, компактная. пользовательская....)
• Установка с CD-ROM
• Установка патчей и специальных функций
• Тестирование разных режимов (исправить, изменить, удалить)

• Проверка правильности возврата к началу программы при отмене установки или деинсталляции

• Объекты файловой системы
• Ключи регистрации и значения ключей
• Регистрация компонентов  COM .NET
• Файлы инициализации, ODBC DNS, общие папки и т.д.

• Общая функциональность

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

Тестирование механизма лицензирования и функций защиты от пиратства

• Тестирование на уровне пользователя
• Функциональное тестирование механизма лицензирования
• Атаки на уровне пользователя

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

Проверка стабильности работы приложения после установки

• правильность структуры папок
• корректность работы с различными вариантами окружения
• стабильность работы самого приложения.

Тестирование удобства пользования (Usability testing)
Это метод тестирования направленный на установление степени удобства пользования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. (ISO 9126)
Тестирование удобства пользования дает оценку  уровня удобства пользования приложения по следующим пунктам:

• производительность, эффективность (efficiency)-сколько времени и шагов понадобиться пользователю для завершения основных задач приложения (меньше-лучше)
• правильность (accuracy) - сколько ошибок сделал пользователь во время работы с приложением (меньше - лучше)
• активизация в памяти (recall) - как много пользователь помнит о работе приложения после приостановки работы с ним на длятельное время (повторное выполнение операций должно проходить быстрее чем у нового пользователя)
• эмоциональная реакция (emotional response) - как пользователь чувствует себя после завершения задачи , порекомендует ли систему (положительная реакция - лучше)

Другое видение:

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

• Однородность;
• Логика и структура;
• Навигация.

Тестирование графического интерфейса пользователя (GUI testing)
Тестирование графического интерфейса пользователя предполагает проверку соответствия приложения требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли в едином стиле.
Виды тестирования интерфейса пользователя:

• Тестирование на соответствие стандартам графических интерфейсов;
• Тестирование с различными разрешениями экрана;
• Тестирование в ограниченных условиях (например нехватка памяти);
• Совместимость с различными интернет-браузерами;
• Тестирование локализованных версий:

•  точность перевода
• проверка длинны названий элементов интерфейса
• ...

• Тестирование графического интерфейса пользователя на целевых устройствах (для КПК- совместимых приложений)

Тестирование прототипа (Prototype testing)
Это метод выявления структурных ошибок, логических ошибок и ошибок проектирования на ранней стадии развития ПО до начала фактической разработки.
Цель тестирования прототипа:

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

Тестирование прототипа охватывает следующие аспекты:

1. Структура приложения;
2. Формы;
3. Прототип бизнес-логики;
4. Логические связи между модулями;
5. Навигация;
6. Графический интерфейс пользователя.

Тестирование совместимости с различными Интернет-браузерами  (Cross-browser  testing)
Основной целью тестирования совместимости является обеспечение качественной работы работы конечного продукта с различными интернет браузерами

Тестирование баз данных  (Database testing)
Тестирование БД помогает обнаружить узкие места в производительности разрабатываемого приложения и проверить все механизмы, обеспечивающие целостность и конфиденциальность данных.
Типы тестирования БД

• Тестирование логической модели
• Проверка модели на логическую согласованность и отсутствие повторяющейся информации
• Поиск возможностей для упрощения логической модели

• Тестирование логической схемы базы данных
• Тестирование на соответствие нормальным формам (обычно третьей)
• Тестирование на согласованность базы данных (внешние ключи, ограничивающие условия, триггеры)
• Тестирование на избыточность данных
• Тестирование физической структуры БД (для различных РСУБД)


• Анализ и настройка покрытия индекса
• Анализ системы хранения данных (табличные части (Oracle, DB2), массивы данных и группы файлов (MS SQL)) настройка для увеличения производительности и надежности
• Анализ политики безопасности и разработка предложений по ее улучшению (пользователи, роли приложения, логины, интегрированные с ОС, хранимые процедуры)
• Анализ денормализации (проверка потенциального прироста производительности и модификации схемы  БД)
• Анализ и реализация распределения БД
• Анализ и реализация стратегии репликации БД
• Анализ и реализация стратегии резервного копирования.
• Тестирование программируемости базы данных


• Анализ эффективности хранимых процедур  и триггеров
• Оптимизация запросов, настройка индекса для охвата определенных запросов
• Анализ эффективности клиентского приложения

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

• Тесты производительности (Performance tests) - измерение характеристик различных бизнес-процессов и транзакций, критичных по времени. в условиях низкой нагрузки, но с реальным размером базы данных
• Нагрузочные тесты (load testing) - полные тесты производительности в условиях ожидаемой реальной нагрузки  и служат для измерения различных бизнес-процессов и транзакций, критичных по времени
• Стресс тесты (Stress tests) - помогают определить нагрузку, при которой происходит сбой в системе, и отследить, как это происходит.
• Ресурсные тесты - подвергают систему повышенным нагрузкам в течении длительного времени

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

• Проверка функций офисной АТС
• Контроль пропускной способности потока вызовов
• Ручное и автоматизированное нагрузочное тестирование
• Тестирование доступа и качества вызовов
• Тестирование удаленных VoIP систем

Оборудование зависит от требований проекта

• Телефоны стандартов ISDN, PSTN, GSM
• Телефоны для сетей Wi-Fi, Ethernet
• Программные телефоны H.323/SIP
• Различные кодеки и протоколы

Тестирование приложений для мобильных устройств (mobile applications  testing)
Тестирование приложений для мобильных телефонов, смартфонов и КПК включает в себя автоматизированное и ручное тестирование на ряде эмуляторов и ручное тестирование на реальных устройствах.
Автоматизированное тестирование включает в себя следующие типы:

• Стресс-тестирование
• Тестирование производительности (для эмуляции вызовов, входящих сообщений, разядки батареи, сбоев сети и т.д.)
• Функциональное тестирование

Ручное тестирование включает в себя следующие типы:

• Функциональное тестирвоание
• Тестирование удобства пользования
• Тестирвоание графического интерфейса пользователя

Технология	Эмуляторы	Реальные устройства
Мобильные телефоны
J2ME	Sun Jаva Wireless Toolkit с эмуляторорами отдельных модулей, поставляемых производителями.	Популярные одели мобильных телефонов с поддержкой Java (технология J2ME) - Nokia, Sony Ericsson, Siemens и др.
Brew	BREW Emulator (BREW SDK 2.0.1)
Смартфоны
	Symbian OS Emulator	Symbian OS 6,7,8
PDA

Тестирование документации (documentation testing)
Тестирование документации осуществляется на этапе разработки требований к программному продукту после создания функциональных спецификаций .
Этот тип тестирования помогает:

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

Тестирование документации  охватывает:

• Функциональные спецификации
• Спецификации по графическому интерфейсу пользователя
• Руководства пользователя и онлайновые справочные системы.

В ходе тестирования проверяются следующие аспекты:

• Логика и согласованность
• последовательность изложения и однородность формы подачи информации
• Полноту и ясность изложения


• соответствие уровня детализации целевой аудитории, достаточность изложенной информации для понимания
• Точность


• актуальность информации, правильность ссылок и графических элементов
• Структуру документа


• соответствие порядка следования элементов документа и его цели
• Орфография. грамматика, правильность употребления слов и пунктуация


• Форматирование


• отсутствие отклонений от стиля оформления, соответствие элементов документа корпоративному стилю.

дАЛИ БУДе
Источник: дядя Интернет и курс лекций академии Шаг

Тестирование.

1. Проверка соответствия реального и ожидаемого поведение ПО выполненная на конечном наборе тестов, выбранных определенным образом.
2. Одна из техник контроля качества ПО включающая в себя активности по планированию работ (Test management) проектированию тестов (test design), выполнению тестов (test execution), оценке полученных тестовых результатов (test analysis).
3. Техническое исследование тестируемого продукта с целью обеспечения заинтересованных сторон информацией о качестве данного продукта.Техническое-потому, что мы используем в тестировании технические средства, логические и математические модели, множество инструментов. Исследование - потому, что мы постоянно ищем информацию, исследуем продукт. Тестируемого продукта - в продукт входят данные, документация, железо или что-либо, что получает заказчик. Если все это не является единой системой, работающей вместе - продукт не работает. Заинтересованная сторона - это все те, у кого есть интерес в успешности процесса тестирования (успешности выполнения проекта). Информация о качестве продукта - это обычно информация о присутствии/отсутствии ошибок, либо другая информация, которая более важна для заинтересованных сторон

Верификация (Verification)
Процесс оценки системы или ее компонентов , с целью определения, удовлетворяют ли результаты этапа разработки тестируемого продукта сформированным условиям в начале этого этапа, т.е. выполняются ли цели, сроки и задачи разработки проекта поставленные в начале текущей фазы.
Валидация (Validation)
Определение соответствия тестируемого приложения потребностям и ожиданиям пользователя, требованиям к системе.
План тестирования (Test Plan)
Документописывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, оценки рисков с вариантами их разрешения.
Тест дизайн (Test Design)
Этап процесса тестирования на котором проектируются и создаются тестовые случаи в соответствии с поставленными критериями качества и целями тестирования.
Тестовый случай (Test Case)
Документ описывающий совокупность шагов, конкретных условий и параметров, необходимая для проверки реализации тестрируемой функции или ее части.
Bug Report
Документ описывающий ситуацию или последовательность действий, приводящих к некорректной работе тестируемого объекта с описанием причин и ожидаемого результата.
Тестовое покрытие (Test Coverage )
Одна из метрик качества тестируемая представляющая собой плотность покрытия тестами требования или исполняемого кода.
Детализация тестового покрытия (Test Case detalization )
Уровень детализации описания тестовых шагов и ожидаемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию.
Время прохождения случая тест кейса(Test Case pass time)
Время от начала прохождения шагов тест кейса до получения результата теста.
Типы тестирования
В зависимости от целей тестирование можно разделить на следующие типы: Функциональные, Нефункциональные, Связанные с изменениями.
Функциональные виды тестирования
Функциональное тестирование (Functional testing), Тестирование безопасности (Security and Access Control Testing), Тестирование взаимодействия (Interoperability Testing).
Нефункциональные виды тестирования
Тестирование производительности {нагрузочное тестирование (Performance and Load Testing), стрессовое тестирование (Stress testing), тестирование стабильности или надежности (Stability and Reliability Testing), объемное тестирование (Volume Testing)}, тестирование установки (Installation testing), тестирование удобства пользования (Usability testing), тестирование на отказ и восстановление (Failover and Recovery testing), Конфигурационное тестирование (Configuration testing).
Bиды тестирования, связанные с изменениями
Дымовое тестирование (Smoke testing), Регрессионное тестирование (Regression testing), Тестирование сборки (Build verification test), Санитарное тестирование или проверка согласованности/исправности (Sanity testing).
Автоматизированное тестирование (Automation Testing)
Процесс верификации ПО при котором основные функции и шаги теста, такие как: запуск, инициализация, выполнение, анализ и выдача результатов выполняются автоматически, с помощью инструментов автоматизированного тестирования.
Автоматизированное функциональное тестирование (Functional Automation Testing)
Процесс верификации функциональных требований и особенностей системы по средствам инструментов для автоматизированного тестирования.
Функциональное тестирование

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

Функциональные тесты
Основываются на функциях (описываемых в требованиях, функциональных спецификациях, случаях использования (тест кейсах)), выполняемых системой, а так же взаимодействии с другими системами, и могут проводиться на всех уровнях тестирования: компонентном/модульном, интеграционном, системном и приемочном.
Нефункциональное тестирование
Описывает тесты, необходимые для определения характеристик, которые могут быть измерены в различных величина, это тестирование того КАК система работает.
Бизнес-процессы
Описывают сценарии ежедневного использования системы.
Уровень тестирования
Определяет то, над чем производятся тесты: над отдельными модулями, группой модулей или системой в целомежедневного использования системы.
Разделяют на : Компонентное или Модульное тестирование (Component Testing or Module Testing), Интерграционное тестирование (Intergration Testind), Системное тестирование (System Testing), Приемочное тестирование (Acceptene Testing)
Компонентное или Модульное тестирование (Component Testing or Module Testing)
Проверяет функциональность и ищет дефекты в частях системы, которые доступны и могут быть протестированы по по отдельности (модули,программ, объекты, классы, функции и т.д.).
Разработка от тестирования (Test-driven development) или Подход тестирования вначале (test first approach)
Это подготовка автоматизированных тестов до начала основного кодирования (разработки) ПО. при этом подходе создаются и интегрируются куски кода. напротив которых запускаются тесты, написанные до начала кодировнаия. Разработка ведется, пока все тесты не будут успешными.
Разница между модульным и компонентным тестированием
В том, что в модульном тестировании в качестве параметров функций используют конкретные значения, а в компонентном - реальные объекты и драйверы.
Интеграционное тестирование
предназначено для проверки связи между компонентами, а так же взяимодействия с различнми частями системы (операционной системой, оборудованием либо связи между различными системами)
Уровни интеграционного тестирования
Компонентный интеграционный уровень и системный интеграционный уровень
Компонентный интеграционный уровень
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Системный интеграционный уровень
Проверяется взаимодействие между разными системами после проведения системного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration), Сверху вниз (Top Down Integration), Большой взрыв ("Big Bang" Integration)
Подход "Снизу вверх"
Все низкоуровневые модули, процедури или функции собираются воедино и затем тестируются .После чего собирается следующи уровень модулей для проведения интеграционного тестирования.
Подход "Сверху вниз"
Вначале тестируются все высокоуровневые модули, и постепенно, один за дркгим, добавляются низкоуровневые.
Подход "Большой взрыв"
Все разработанные модули собираются воедино в виде законченной системы или ее основной части и затем проводится инетграционное тестирование.
Системное тестирование(System Testing)
Основной задачей системного тестирования является проверка как функциональных, так и нефункциональных требований к системе в целом.
Подход "на базе требований" (requirements based)
Для каждого требования пишут тестовые случаи (test cases), проверяющие выполнение данного требования.
Подход "на базе случаев использования" (requirements based)
На основе представления о способах использования продукта создаются случаи использования системы (use cases). На 1 случай использования определяется 1 или несколько сценариев. Для проверки каждого сценария пишут тест кейсы (test cases) которые должны быть протестированы.
Use case
Случаи использования системы, основанные на представлении о способах использования продукта
Приемочное тестирование или Приемо-сдаточное испытание (Acceptance Testing)
проверяет соответствие системы требованиям, и проводится с целью: 1) определения удовлетворяет ли система приемочным критериям; 2) вынесения заказчиком решения принимается приложение или нет.
Tестирование безопасности (Security and Access Control Testing)

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

Конфиденциальность (confidentiality)
Cокрытие определенных ресурсов или информации. Ограничение доступа к ресурсу некоторой категории пользователей.
Целосность (integrity). Критерии определения
Доверие: Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей. Повреждение и восстановление: Определения важности процедуры восстановления данных, которые были повреждены или изменены пользователем (авторизованным, или нет)
Доступность (availability)
Представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту, устройству. чем критичнее ресурс, тем выше уровень доступности должен быть.
Тестирование контроля доступа
Помогает обнаружить дефекты, в результате которых пользователи могут получать несанкционированный доступ к объектам и функциям приложения.
Тестирование авторизации пользователей
Выявляет дефекты, связанные с авторизацией отдельных пользователей и групп пользователей с проверкой их подлинности.
Тестирование валидации ввода
используется для поверки валидации данных с сервером до того, как они попадут в приложение
Тестирование надежности шифрования данных
Используется для выявления дефектов, связанных с шифрованием и расшифровкой данных, использованием цифровых подписей и проверкой их подлинности.
Тестирование правильности обработки ошибок
Включает в себя проверку таких аспектов, как вывод на экран фрагментов кода при ошибке, влияние ошибки на работу всего приложения и раскрытие излишней информации о сбое в работе
Тестирование на переполнение буфера
Выявляет ненадлежащее раскрытие данных
Тестирование конфигурации сервера
Помогает обнаружить ошибки в много-поточных средах, в результате которых могут быть повреждены или использованы совместно.
Степени покрытия при тестировании безопасности
 1) Первичное тестирование безопасности, 2)Полное тестирование приложения, 3)Полное тестирование приложения и сервера
Аспекты тестирования безопасности в зависимости от покрытия1)Тестирование контроля доступа, 2) Тестирование автоматизации пользователей, 3) тестирование валидации кода, 4) тестирование надежности шифрования данных, 5)тестирование правильности обработки ошибок,  6) тестирование на переполнение буфера, 7) тестирование конфигурации сервера.Тестирование взаимодействия (Interoperability testing)
Функциональное тестирование , проверяющее способность приложения взаимодействовать с одним и более компонентами или системами, включающее в себя тестирование совместимости и интеграционное тестирование.
Тестирование совместимости (Compatibility testing)
Метод,  целью которого является обеспечение качественной работы конечного продукта с другим ПО
Тестирование совместимости с различными Интернет-браузерами (cross-browser testing)
Целью тестирования кроссбраузерности является обеспечение качественной работы конечного продукта с различными браузерами.
Интеграционное тестирование (Integration testing)
Фаза тестирования ПО, при котором отдельные программные модули объединяются и тестируются в группе.
Составляющие нагрузочного тестирования
Тестирование производительности; Стрессовое тестирование; Объемное тестирование; Тестирование стабильности.
Нагрузочное тестирование в техническом тестировании (Load testing)
представляет собой полные тесты производительности в условиях ожидаемой реальной нагрузки и служат для измерения характеристик различных бизнес-процессов и транзакций, критичных по времени.
Задача тестирования производительности (Performance testing)
определение масштабируемости приложения под нагрузкой. При этом происсходит: 1) измерение времени выполнения выбранных операций при определенных интенсивностях  выполнения этих операций. 2) определение количества пользователей, одновременно работающих с приложением. 3) определение границ  приемлимой производительности при увеличении нагрузки. 4) исследование производительности на высоких, предельных, стрессовых нагрузках.
Тестирование производительности в техническом тестировании (Performance testing)
заключается в измерении характеристик различных бизнес-процессов и транзакций, критичных по времени, в условиях низкой нагрузки, но с реальным размером БД
Стрессовое тестирование (Stress testing)
позволяет проверить насколько прилодение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации. Оценка деградации производительности - одна из задач стрессового тестирования.
Стрессовое тестирование в техническом тестировании(Stress testing)
помогает определить нагрузку, при которой происходит сбой в системе, и отследить как это происходит.
Ресурсные тесты в техническом тестировании
подвергают систему повышенным нагрузкам в течении длительного времени.
Задача объемного тестирования (Volume testing)
получение оценки производительности при увеличении объемов данных в БД приложения. При этом происходит: 1)измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций. 2) может производиться определение количества пользователей, одновременно работающих с приложением.
Задача тестирования стабильности/надежности (Stability/Reliability  testing)
проверка работоспособности приложения  при длятельном (многочасовом) тестировании со средним уровнем нагрузки.
Дымовое тестирование (Smoke testing)
Поверхностная проверка всех модулей приложения на предмет работоспособности и наличие быстро находимых критических и блокирующих дефектов. По результатам делается вывод о принятии установленной версии в тестирование, эксплуатацию, поставку заказчику.
Санитарное  тестирование (проверка согласованности/исправности) (Sanity testing)
Узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает  согласно заявленным в спецификации требованиям. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде.
Тестирование сборки (Build verification testing)
Тестирование, направленное на определение соответствия выпущенной версии, критериям качества для начала тестирования.
Регрессионное тестирование (Regression testing)
Тестирование, направленное на проверку изменений, сделанных в приложении или окружающей среде, для подтверждения прежней функциональности.
Типы регрессионного тестирования по С.Канеру1)Регрессия багов, 2) регрессия старых багов, 3)регрессия побочного эффекта
Регрессия багов
Попытка доказать, что исправленная ошибка, на самом деле не исправлена.
Регрессия старых багов
Попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые ошибки снова воспроизводятся.
Регрессия побочного эффекта (Side effect regression)
Попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.
Тестирование установки (Insallation testing)

1. Тестирование, направленное на проверку успешной инсталляции и настройки, а так же обновления или удаления ПО.
2. Комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляций.
3. 1)Формальное тестирование программы установки (графический интерфейс пользователя, общее удобство пользования, соответствие стандартам); 2)Функциональное тестирование установки; 3)Тестирование механизма лицензирования и способности противостоять взлому; 4)проверка стабильности работы приложения после установки.

Формальное тестирование программы установки 1) формальное тестирование графического интерфейса пользователя; 2) тестирование навигации; 3) тестирование удобства пользования приложением; 4) тестирование региональных и языковых настроек; 5) выявление любых ошибочных ситуаций :-))) 6) проверка доступности контактной информации
Функциональное тестирование программы установки 1) тестирование различных опций установки 2) проверка правильности возврата к началу программы при отмене установки или деинсталяции 3) общая функциональность.
Тестирование различных опций установки 1) типы установки (типичная, компактная, пользовательская и т.д.) 2)Установка с компакт-диска 3) установка патчей и специальных функций 4) тестирлвоание разных режимов (исправить, изменить, удалить)
Проверка правильности возврата к началу программы при отмене установки или деинсталяции  при тестировании установки1) Объекты файловой системы 2) ключи регистрации и значения ключей 3) регичтрация компоненов COM и .NET 4)файлы инициализации ,ODBC DSN ,общие папки и т.д.
Тестирование общей функциональности при тестировании установки1) проверка прав локального администратора 2) правильная обработка исключительных ситуаций (недостаток места, памяти, прав) 3) приемлимый уровень призводительности и использования ресурсов.
Тестирование механизма лицензирования и функции защиты от пиратства на уровне пользователя1) функциональное тестирование механизма лицензирования 2) атаки на уровне пользователя
Тестирование механизма лицензирования и функции защиты от пиратства на повышенном уровне1) разбор форматов файлов лицензии и мест в реестре или файлах, где хранится важная информация о лицензировании; 2) разборка, исправление или повторная сборка бинарных модулей; 3) запуск приложения в режиме отладки; 4) создание генераторов ключей, эмуляторов устройств и т.д.; 5) подсчет объема работы на предыдущих этапах и принятие решения о надежности системы защиты; 6) разработка рекомендаций по улучшению механизма лицензирования и системы  защиты.
Проверка стабильности работы приложения после установки  Проверяются 1) правильность структуры папок; 2) корректность работы с различными вариантами окружения; 3) стабильность работы самого приложения.


Тестирование удобства пользования (Usability testing)

1. Метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей в контексте заданных условий. Дает оценку по следующим пунктам: 1) производительность, эффективность; 2) правильность; 3) активация в памяти; 4) эмоциональная реакция.
2. Определяет, соответствует ли приложение потребностям целевой аудитории, и отвечает ли оно требованиям пользователя.

Аспекты тестирования удобства пользования
Однородность, Логика и структура, Навигация.
Тестирование прототипа (Prototype testing)
Метод выявления  стурктурных ошибок, логических ошибок и ошибок проектирования на ранней стадии развития ПО до начала фактической разработки.Цель тестирования прототипа
Выявить потенциальные проблемы в ПО, проверить, насколько приложение соответствует потребностям и ожиданиям пользователяб обнарцжить расхождение с требованиями к графическому интерфейсу пользователя.
Аспекты тестирования прототипа
1) Структура приложения, 2) Формы, 3) Прототип бизнес логики, 4) Логические связи между модулями, 5) Навигация, 6) Графический интерфейс пользователя.
Тестирование графического интерфейса (GUI testing)
Предполагает проверку соответствия приложения требованиям к графическому интерфейсу, профессионально ли оно выглядит, выполнено ли в едином стиле.
Виды тестирования графического интерфейса Тестирование на соответствие стандартам графических интерфейсов; Тестирование с различными разрешениями экрана; Тестирование в ограниченных условиях; Кроссбраузерность; Тестирование локализованных версий (точность перевода, длинна названий и т.д.); Тестирование на целевых устройствах.
Тестирование  баз данных
Помогает обнаружить узкие места в производительности разрабатываемого ПО и проверить все механизмы, обеспечивающие целостность и конфиденциальность данных.
Типы тестирования  баз данных
1) Тестирование логической модели, 2) Тестирование логической схемы баз данных, 3) Тестирование физической  структуры баз данных (для различных РСУБД), 4) Тестирование программируемости базы данных.
Тестирование логической модели БД
1) Проверка модели на логическую согласованности и отсутствие повторяющейся информации, 2) Поиск возможностей для упрощения логической модели.Тестирование логической схемы БД
1) Тестирвоание на соответсвие нормальным формам 2) Тестирование на согласованность базы данных (внешние ключи, ограничивающие условия, триггеры), 3) Тестирование на избыточность данных
Тестирование физической структуры БД (для различных РСУБД)
1) анализ и настройка покрытия индекса, 2) анализ системы хранения данных (табличные области (Oracle, DB2), массивы данных и группы файлов (MS SQL)), настройка для увеличения производительности и надежности, 3) анализ политики безопасности и разработка предложений по ее улучшению (пользователи, роли, роли приложения, логины, интегрированные с операционной системой, хранимые процедуры.) 4) Анализ денормализации  (+проверка потенциального прироста производительности и модификации схем баз данных), 5)анализ и реализация распределения базы данных, 6)анализ и реализация стратегиии репликации, 7) анализ и реализация стратегии резервного копирования.
Тестирование программируемости БД 
1)анализ эфективности хранимых процедур и триггеров, 2)Оптимизация запросов, настройка индекса для охвата определенных запросов, 3)анализ эффективности клиентского приложения.
Техническое тестирование (Technical testing)
Показывает способность приложения работать безопасно, эффективно и надежно в нормальных и пиковых условиях использования.Тестирование VoIP приложений (VoIp testing)
может быть представлено на различных уровнях , от функционального до контроля трафика: 1) Проверка офисной АТС, 2) контроль пропускной способности потока вызова, 3) нагрузочное тестирование (ручное и автомат.) 4) тестирование доступа и качества вызовов  5)Тестирование удаленных VoIP систем. С использованием оборудования: 1) Телефоны стандартов ISDN, PSTN и GSM. 2) Телефоны для сетей Wi-Fi, Ethernet. 3) програмные телефоны , 4) Различные кодеки и протоколы.
Тестирование приложений для мобильных устройств (Mobile app. testing)
Включает в себя автоматизированное  и ручное тестирование на ряде эмуляторов и ручное тестирование на реальных устройствах. Автомат. тестирование приложений для мобильных устройств

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


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



1) Логика и согласованность (последовательность изложения и однородность формы подачи информации), 2) Полнота и ясность изложения (соответствие  уровня детализации целевой аудитории, достаточность изложенной информации для понимания), 3) Точность (актуальность информации , правильность ссылок и графических элементов), 4) Структура документа (соответствие порядка следования элементов документа и его цели), 5) Орфография, грамматика, правильность употребления слов и пунктуация, 6) Форматирование (отсутствие отклонений от стиля оформления, соответствие элементов документа корпоративному стилю)
Виды документов при Тестирование документации




1) Функциональные спецификации, 2) спецификации по графическому интерфейсу пользователя, 3)руководства пользователя и онлайновые справочные системы.

дАЛИ БУДЕ

Источник: дядя Интернет и курс лекций академии Шаг

  Администрация Блогов@Mail.Ru от всей души поздравляет  Penelope fon Mullen с днем рождения.

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

Материал из Википедии — свободной энциклопедии
Common User Access (типовой пользовательский интерфейс, CUA) — стандарт интерфейсов пользователя для операционных систем и компьютерных программ. Он был разработан компанией IBM и впервые опубликован в 1987 г. как составляющая часть её архитектуры SAA. Первоначально использовался в операционных системах MVS, VM, OS/400, OS/2 и Microsoft Windows, фрагменты стандарта CUA сейчас реализованы в программах других операционных систем, в том числе и в разновидностях Unix. Он также применяется в пакетах Java: AWT и Swing.

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

• В WordPerfect команда открытия файла была:   F7 ,   3 .
• В Lotus 1-2-3 файл открывался с помощью   /  (открыть меню),   W  (Workspace — рабочая область),   R  (Retrieve — получить).
• В Microsoft Word для открытия файла нажималось:   Esc  (чтобы открыть меню),   T  (Transfer — передача),   L  (Load — загрузить).
• В WordStar сочетание клавиш было   Ctrl +  K +  O .
• В emacs файл открывался так:   Ctrl +  X , а затем   Ctrl +  F  (Find-File — поиск файла).

В некоторых программах клавишей   Esc  действие отменялось, в других — совершалось; WordPerfect она выполняла повтор символа. В одних программах   End  делала переход в конец строки, в других она означала окончание заполнения формы. Клавиша   F1  использовалась для вызова справки, а в WordPerfect для этой цели служила   F3 . Зачастую   Ins  переключала режимы вставки и замены символов, хотя в некоторых она использовалась для вставки из буфера обмена.

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

Многие аспекты стандартизации были сформулированы под влиянием подробных дизайнерских инструкций
(гайдлайнов) по интерфейсам пользователя компьютеров Apple.
Гайдлайны Apple представляли собой объёмную книгу, чётко разъясняющую, как должно было выглядеть и работать программное обеспечение для компьютеров с системой Apple Macintosh. Когда это руководство было написано, и сам «Mac», и программы с GUI
вообще были новинками, поэтому Apple стоило огромных усилий привести программы к единому внешнему виду и стандартному поведению (look and feel).
Перед CUA ставились аналогичные задачи, однако дело усложнялось необходимостью применения стандарта к уже созданным, активно используемым, хотя и не систематизированным программным продуктам.

Система CUA включает в себя стандарты функционирования таких элементов, как диалоговые окна, меню и сочетания клавиш.
Эти стандарты стали настолько значимыми, что их сегодня реализуют большинство программистов, даже не читавших CUA. Применение этих стандартов можно наблюдать в Windows и в основанных на DOS приложениях, например в полноэкранном текстовом редакторе EDIT для MS-DOS 5.

Ключевые положения CUA:

• любую операцию можно выполнить как мышью, так и клавиатурой;
• меню вызываются и скрываются клавишей   F10 ;
• меню открываются нажатием клавиши   Alt  и подчёркнутой буквы в их названиях;
• команды меню, требующие уточнения параметров выполняемого действия, заканчиваются многоточием («…»);
• параметры запрашиваются вторичными (диалоговыми) окнами;
• параметры сортируются по разделам с помощью вкладок (как в бумажных записных книжках);
• перемещение внутри полей в диалоговых окнах осуществляется клавишами управления курсором; между самими полями — клавишей   Tab ⇆ , а сочетанием   ⇧ Shift +  Tab ⇆  — в обратном направлении;
• в диалоговых окнах есть кнопка «Отмена», эквивалентная нажатию   Esc , которая сбрасывает изменения, а также «ОК», эквивалентная нажатию   ↵ Enter , которая принимает изменения;
• В программах есть встроенная справочная система, вызываемая из меню «Справка», расположенного в конце строки меню; контекстно-зависимая справка может вызываться клавишей   F1 ;
• Первое меню должно называться «Файл» и должно содержать операции по работе с файлами (создать, открыть, сохранить, сохранить как) и команду выхода; следующее меню «Правка» содержит команды отмены, повтора, вырезания, копирования, вставки и удаления;
• Команда «вырезать» выполняется нажатием   ⇧ Shift +  Del , «копировать» —   Ctrl +  Ins , а «вставить» —   ⇧ Shift +  Ins ;
• Размер окна меняется путём перетаскивания одного из 8 элементов его границы.

CUA распространялся не только на приложения DOS, но и был также основой стандарта интерфейсов Windows (CUI) и программ для OS/2 — как текстовых, так и основанных на GUI Presentation Manager — а также мейнфреймов IBM на основе архитектуры SAA.

CUA был более, чем просто попыткой упорядочить программы DOS, — он был частью плана по объединению, упорядочению и взаимосвязыванию общих функций программного и аппаратного обеспечения во всей линейке продукции IBM, от микрокомпьютеров до мейнфреймов. Вероятно, это отчасти и было причиной неполного успеха CUA.

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

http://www.studfiles.ru/dir/cat32/subj1173/file9485/view99701/page4.html
Система международных стандартов графических пользовательских интерфейсов.
Особенностью пользовательского интерфейса как архитектурного компонента среды ИС является необходимость высокой согласованности всех функциональных элементов интерфейса. В связи с этим организации по стандартизации и промышленные консорциумы разрабатывают спецификации пользовательского интерфейса в виде гармонизированных профилей на основе базовых стандартов. Однако, на настоящий момент не существует подобного рода спецификации, которая охватывала бы все аспекты пользовательского интерфейса. Традиционно такие профили описывают либо структуру графического оконного интерфейса в целом, либо архитектуру построения распределенных приложений. Для построения профилей интерфейсов пользователя должны использоваться базовые стандарты, относящиеся к
следующим классам объектов стандартизации:
— типовые формы документов и процедуры работы с ними;
— элементы взаимодействия пользователя с алфавитно-цифровым интерфейсом;
— элементы взаимодействия пользователя с графическим интерфейсом;
— структура распределенных приложений в части средств, поддерживающих интерфейсы пользователя.
Типовые формы документов и процедуры работы с ними, рассматриваемые как объекты стандартизации, относятся к функциональному уровню взаимодействия пользователей с информационными системами. Объектами стандартизации, соответствующими процедурам из этого перечня являются элементы интерфейса пользователя, определяющие возможность начала соответствующей операции, ее ход и результат. Должна быть предусмотрена идентификация ошибочных действий и стандартизирована форма сообщения об ошибках. В связи с жестким регламентом выполнения процедур, средства настройки интерфейса пользователя на большинстве АРМов этих систем должны быть весьма ограничены либо отсутствовать.
Для информационно-аналитических и административно-вспомогательных систем в настоящее время типовые процедуры не определены. В этих документах должны быть описаны:
— соответствие между элементами интерфейсов пользователя (экранными формами) и типовыми процедурами;
— последовательность допустимых операций и переходы между экранными формами;
— форма идентификации ошибочных действий и/или ситуаций;
— формы входных и выходных документов.
Большинство приложений, использующих алфавитно-цифровой интерфейс, предоставляют либо вариант интерфейса, разработанного специально в составе приложения, либо интерфейс, который может быть сконструирован при помощи средства разработки этого приложения. Существуют фирменные стандарты,
определяющие построение алфавитно-цифровых интерфейсов.
Деятельность в области графических систем возглавляется и координируется 24-м подкомитетом ISO/IEC JTC1/SC24 при активном участии NIST, IEEE и ряда крупных программистских фирм. При создании графических стандартов используется принцип виртуальных ресурсов и разделения графической
системы на несколько уровней (см. выше). Уровни могут использовать информацию нижних уровней и взаимодействовать с другими подсистемами посредством стандартизированных программных интерфейсов, а также с помощью стандартизированных файлов или протоколов. Для этого выделены три направления стандартизации:
— базисные графические системы;
— интерфейсы виртуальных устройств;
— форматы обмена графическими данными.
Стандарты базисных систем направлены на унификацию визуализации графических объектов. Интерфейсы виртуальных устройств разделяют аппаратно-зависимую и аппаратно-независимую части графических систем. При этом важную роль сыграло развитие растровых дисплеев и принтеров. Первоначально растровые
файлы содержали только статические изображения. Появились проекты стандартов на форматы динамических (анимационных) изображений. На международном уровне упорядочена система непосредственного графического взаимодействия пользователей с базовыми средствами манипулирования
графическими образами, которые стандартизированы де-юре ISO:
1.       ISO 9040:1990. СОИ. ВОС. Услуги виртуального терминала. Базовый класс.
2.       ISO 9041:1990. СОИ. ВОС. Протокол виртуального терминала. Базовый класс.
3.       ISO 7942:1985. СОИ. МГ. Функциональное описание ядра графической системы (GKS). Приложение 1:1991.
4.       ISO 8651-1-4:1988. СОИ. МГ. Языковые связи ядра графической системы (GKS). Ч.1:Фортран. Ч.2:Паскаль. Ч.З: Ада.Ч.4: Си.
5.       ISO 8805:1988. СОИ. МГ. Функциональное описание трехмерного ядра графической системы (GKS-3D).
6.       ISO 8806-1-4:1991. СОИ. МГ. Языковые связи трехмерного ядра графической системы (GKS-3D). 4.1: Фортран. 4.2: Паскаль. 4.3: Ада. 4.4: Си.
7.       ISO 8632-1-4:1992.
СОИ. МГ. Метафайл для хранения и передачи информации, описывающей
изображение (CGM). 4.1: Функциональные требования. Дополнение 1:1990.
4.2: Символьное кодирование. Дополнение 1:1990. 4.3: Двоичное
кодирование. Дополнение 1:1990. 4.4: Кодирование открытого текста.
Дополнение 1:1990.
8.       ISO 9281-1,2:1990. ИТ. Методы кодирования изображения. 4.1: Обозначение. 4.2: Процедуры для регистрации.
9.       ISO 9282-1:1988. ИТ. Кодированные представления изображений. 4.1: Принципы кодирования для представления изображения в 7- и 8-битной среде.
10.    ISO 9592-1-3:1989.
СОИ. МГ. Иерархическая интерактивная графическая система программиста
(PHIGS). 4.1: Функциональное описание. 4.2: Формат архивного файла. 4.3:
Открыто-текстовое кодирование архивного файла.
11.    ISO 9593-1-4:1990.
СОИ. МГ. Языковые связи иерархической интерактивной графической системы
программиста (PHIGS). 4.1: Фортран. 4.2: Расширенный Паскаль. 4. 3:
Ада. 4.4: Си.
12.    ISO 9636-1-6:1991. ИТ.
МГ. Методы сопряжения для диалогов с графическими устройствами.
Функциональные требования. 4.1: Обзор, профили и согласованность. 4.2:
Контроль. 4.3: Вывод. 4.4: Сегменты. 4.5: Ввод и отображение. 4.6:
Растр.





Услуги, регламентируемые представленной группой стандартов виртуальных терминалов и графики (GUI), определяют способы взаимодействия прикладных интерактивных систем, ориентированных на терминальную связь, в терминах передачи и манипулирования абстрагированными графическими образами. В базовой эталонной модели ВОС виртуальные терминалы и графика организуются на прикладном уровне и используют сервис представительского уровня. Базовый класс GUI организует образы, состоящие из блочно-символьных графических элементов, организованных в одно-, двух- / или трехмерные структуры.
Услуги базового класса виртуальных терминалов позволяют [15,17,13]
— устанавливать соединение между двумя пользователями; -
— запрашивать и согласовывать подмножества услуг и сервисных параметров;
— передавать и манипулировать структурированными данными, независимо от способа внутреннего представления их информации, используемого каждым пользователем GUI;

http://msdn.microsoft.com/en-us/library/ms997448.aspx
Checklist for a Good Interface The following checklist
summarizes the information in the previous section and in this book. Use
it to help you confirm that your application is designed to provide the
best user experience:

• Your application installs easily in a minimum number of steps.
• Your application installation does not require the system to restart.
• Users do not have to read a Readme file before using your application.
• User-generated data files are stored by default in the My Documents folder.
• Your application avoids cryptic file names that are visible to users.
• Your application does not create folders outside of the Program Files folder.
• Your application does not write files to the root of the hard disk.
• If your application uses a disk cache, it also registers with the Disk Cleanup utility.
• Your application does not include entries to its Help, Readme, and Uninstall files on the Start menu.
• Your application does not install icons to the Windows desktop without the user's permission.
• If your application is run at startup, it loads without displaying splash screens and dialog boxes.
• Your application does not use the taskbar notification area for status, for launching applications or utilities, or for querying properties. It uses the notification area only to alert the user of an important change.
• Your application appropriately applies the color choices the user selected in Display properties in Control Panel.
• Your application is keyboard accessible.
• Your application works correctly if the user increases the size of the default font.
• Your application supports the standard set of keyboard shortcuts, where applicable.
• Your application's uninstall process leaves no remaining files or registry entries other than files created by the user.
• Your application does not use jargon in its user interface text. Use industry-specific or technical terms only if they are clearly understood by the user.
• Your application adjusts appropriately when the user changes the display resolution as well as for multiple-monitor configurations.

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

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

Стрессовое тестирование (Stress testing)

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

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

Одной из задач стрессового тестирования является оценка деградации производительности.

Объемное тестирование (Volume testing)

Задача объемного тестирования: получение оценки производительности при увеличении объемов данных в базе данных приложения. При этом выполняется:

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

Тестирование стабильности или надежности (Stability/Reliability testing)

Задачей тестирования стабильности, надежности является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. При  этом выявляютсяследующие аспекты влияющие на стабильность работы:

• утечки памяти;
• перезепуски серверов под нагрузкой...

Источник: дядя Интернет и курс лекций академии Шаг

Уровень тестирования определяет то, над чем производятся тесты: над отдельным модлем, группой модулей или системой, в целом

Компонентное или Модульное тестирование (Component testing or Unit testing)
Компонентное или Модульное тестирование проверяет функциональность ищет дефекты в частях приложения, которые доступны,и могут быть протестированы по-отдельности такие как модули, объекты, классы, функции и т.д. Обчычно производится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймферки для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в багтрекинговой системе.

Один из наиболее эффективных подходов к компонентному (модульному) тестированию - это подготовка автоматизированных тестов ДО начала основного кодирования программного обеспечения. Это разработка от тестирования (Test-driven development) test first approach (подход тестирования вначале). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор, пока все тесты не будут успешными.

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

Интеграционное тестирование (Integration t testing)
Интеграционное тестирование предназначено для проверки связи между компонентами, а так же взаимодействия с различными частями системы (операционной системой, оборудованием, либо связи между различными системами).

Уровни интеграционного тестирования:

Компонентный интеграционный уровень (Component Integration Testing): Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования
Системный интеграционный уровень (System Integration testing) Проверяется взаимодействие между разными системами после проведения системного тестирования.

Подходы к интеграционному тестированию

Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Подход считается полезным, если почти все модули разрабатываемого уровня, готовы

Сверху вниз (Top Down Integration)
Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все низкоуровневые модули симулируются заглушками с аналогичной функциональностью , затем по мере готовности они заменяются реальными активными компонентами

Большой взрыв ("Big Bang" Integration)
Все, или почти все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводиться интеграционное тестирование.

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

неверное использование ресурсов системы;

непредусмотренные комбинации данных пользовательского уровня;

несовместимость с окружением;

непредусмотренные сценарии использования;

отсутствующая или неверная функциональность;

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

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

Подходы к системному тестированию:

на базе требований (requirement based)
Для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.

на базе случаев использования (use case based)
На основе представления о способах использования продукта, создаются случаи использования системы (use cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест кейсы, которые должны быть протестированы

Приемочное тестирование (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводиться с целью:

определения удовлетворяет ли система приемочным критериям

вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

Решение о проведении приемочного тестирования принимается, когда:

продукт достиг необходимого уровня качества;

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

Фаза приемочного тестирования длятся до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения.

Источник: дядя Интернет и курс лекций академии Шаг

Эпилог
Я люблю работать, особенно я люблю работать тестером, тем который QA. Еще больше люблю приносить пользу людям . А тут такая хрень, под зад коленом в самый мой слабый момент, когда сыну не исполнилось еще и 2 недели. Жутко. Врагу не пожелаю.
Предыстория
Когда то мы с Сашей сделали компании большое одолжение. Очень большое, в обмен на полные социальные гарантии, а именно, в случае моей беременности, я обязуюсь выйти на работу пораньше, а меня за это время не уволят.
Завязка
Я очень любила работать, я бралась за самые тяжелые задания, и доводила их до конца. Всего лишь 1 проект не был мной доведен до конца по причине его немецкоязычности, недружелюбного интерфейса и отсутствия описания (вообще). Список явных и критических ошибок был составлен, но проект до конца, на тот момент был не понят (через год я уже владела им на хорошем уровне).
Я тестировала. Я планировала. Я документировала. Я управляла. Я успешный серый кардинал, с моей легкой руки на работу был принят технический писатель, все проекты задокументированы, программистам поставлено лицензионное ПО, и много еще чего.
Я, тестер, все время всех защищала, входила в положение всех, при этом качество росло. под качеством я понимаю небольшое кол-во открытых ошибок, документирование, укладывание в сроки и т.д. Я никогда и никого не подставила и не подсидела, была масса возможностей подсидеть директора, я этого не сделала, ни разу.
Я была вторым тестером в компании, первого к сожалению уволили, я просила немецкого шефа одуматься, я писала ему длинные письма, и вела мучительные чаты в скайпе. не получилось. Но я хотя бы попробовала.
Через пять лет работы в компании я забеременела. Я написала немецкому шефу, об этом и о том, что я очень хочу остаться работать в компании. Он заверил меня, что все будет хорошо )) Мы купили дорогой ноут, что бы я свободно могла работать из дома.
18 июня 2010 года, за 19 дней до родов у меня состоялся разговор с шефом по скайпу:
[18.06.2010 16:36:47] Ulrich: hi Masha
[18.06.2010 16:36:59] Ulrich: is actual 7.2 working?
[18.06.2010 16:37:06] Ulrich: how are your tests?
[18.06.2010 19:40:21] Maria: hello Ulrich. sorry I was away from the computer. version 7.2.1.2 that was in testing last 3 days had a lot af bugs including interface bugs (this is not good because this is a face of the program) thay did fixes in the new version 7.2.1.3 that was in testing today, Irina G tested it, after this testing they made version 7.2.1.4. also in v 7.2.1.3 they made functional changes. so I can say nothing about v 7.2.1.4.
for me all of them need to be tested and not debuget after thet to say if it is ready. for now my answer is NO, it's not ready
[18.06.2010 19:41:52] Ulrich: but, sorry, we defined that today 7.2 is finished
[18.06.2010 19:42:10] Ulrich: we have 2 installations next week
[18.06.2010 19:42:42] Ulrich: we moved customer to next week because of waiting for stable version
[18.06.2010 19:44:45] Ulrich: last update we did with 7.1.7
with all problems and changes we told customer, that we changed startey have versonising and we bring stable version middle of june
[18.06.2010 19:45:27] Ulrich: we already moved date to end of the week
[18.06.2010 19:45:38] Ulrich: I cannot wait more longer time
[18.06.2010 19:49:12] Maria: yes but the good solution 'd be it to make it STABLE - fix bugs and test it fix and test it fix and test it, and not what we did - fix bugs in 7.1 and make 7.2 in papralel, so now we have 2 versions with bugs. :(
I understand that you can not wait. and customers can't wait. i REALLY do. but this proccedure that we have now even worse then we had in past with 1 version
[18.06.2010 19:49:50] Maria: about stability - this v 7.2. is better then 7.1 it eats less memory and usualy doesn't falls
[18.06.2010 19:52:31] Ulrich: but how should we continue?
I planned all features for version 7.3, we need urgent
[18.06.2010 19:52:55] Ulrich: when 7.2 is not finished now, how can we start with 7.3?
[18.06.2010 19:53:25] Ulrich: and features of 7.3 we have deadlines by actual projects
[18.06.2010 19:54:07] Ulrich: OK I will discuss this with Alex
[18.06.2010 19:54:23] Ulrich: At the moment I am absolutely frustrated
[18.06.2010 19:55:30] Ulrich: have a nice weekend
[18.06.2010 19:55:40] Ulrich: I am at customers next week
[18.06.2010 19:56:08] Ulrich: have discussions with boss of weimar, because of problems in LMMMS
[18.06.2010 20:00:00] Maria: 1. you should deside the list of urgent fetures (stable one with no changes)
2. give it to work
3. we should develop those changes
4.make 3 cycles of testing and debug
5. we should give you the version that was teste, and not debuged.
6. you should see the open bug and deside is it is o to give it to customer
7. if it is not ok then we make debug and after that testing
8. then if you deside then bugs are ok to be given to customer
9. then we start working on the new version with new fetures.
one tested and several programmers can do it in a monthI think if a tester will be only on the logimen.
[18.06.2010 20:00:47] Maria: newt time it will takemless time and less time
[18.06.2010 20:02:01] Maria: but always it is better to give to az customer version with known bugs (that service can explain how to avoid it ) then a debuged version when noone knows what was really done there
[18.06.2010 20:02:58] Ulrich: this sounds too complicated to me
[18.06.2010 20:03:06] Maria: i'm not saying that urgent new features and fixes should not be done. no/ this is a real life and real people, but proccess that we have now is totaly wrong. but noone listen to me (
[18.06.2010 20:03:47] Ulrich: I think to the words of Mr Knopp
[18.06.2010 20:04:16] Ulrich: he told me last year the same problems in his development
[18.06.2010 20:04:23] Maria: this sounds too complicated to meit's not complicated. it is the correct way, a lot of real development models are working like this.
[18.06.2010 20:04:31] Ulrich: then he removed all testers
[18.06.2010 20:04:50] Ulrich: and programmers has to test by themselves
[18.06.2010 20:05:07] Ulrich: and are resposible for quality
[18.06.2010 20:05:24] Ulrich: abd final tester is in Vienna
[18.06.2010 20:06:40] Maria: if they are really responsible - then it's good, nut I do not think that developer can really test after hisself, Imean the deep testing. but if our logimen programmers would make test themselg smokly - it'd be nice, but they don't
[18.06.2010 20:07:20] Ulrich: micha does it, I do it bernhard does it, Tanja does it
[18.06.2010 20:08:48] Ulrich: because they trust in testers!
[18.06.2010 20:09:01] Ulrich: so remove tester, then they must
[18.06.2010 20:09:22] Ulrich: and money only gets payed when it works
[18.06.2010 20:09:27] Maria: but also I can't say then LogiMen5 is really work good - but maybe this is a database problems an I now this logimen badly
[18.06.2010 20:10:24] Maria: and money only gets payed when it worksyes. but how you'll know if it's work? customer will?
[18.06.2010 20:13:01] Ulrich: this areas you work with logimen5 special recipes, articles does not work good. There are a lot of problems in. But customers did not need it in tha past. But now they do and my plan was, to replace this part with LM7 asap. But first the LMMMS must work stable. and all this procedures takes too many time
[18.06.2010 20:14:52] Ulrich: For this reason micha works on a redesign of LMC, because I cannot wait until I can get it from LogiMatika
[18.06.2010 20:16:14] Maria: I see.
[18.06.2010 20:19:55] Ulrich: At the moment all at logimatika takes too long time.
I accepted that it takes too long time and agreed to wait until middle of june, to get a stable version which I can give to customer without get beated.
[18.06.2010 20:21:08] Ulrich: that version I get is still with known errors makes me sad and angry and frustrazted
[18.06.2010 20:22:32] Ulrich: and changes I ashed for in last time, I always asked is that possible for this date? Ald programmers says 'no problem'
[18.06.2010 20:22:43] Maria: then you should give the lst version 7.2.1.4. and also to seebuyourself if all what you need there is working. all changes that were made in 7.2 are applied ok. i afraid of bugs that could be done in a debug process.
[18.06.2010 20:23:22] Maria: sorry but this is my job to tell you about all problems that I see
[18.06.2010 20:23:49] Ulrich: I am not angry about you personally
[18.06.2010 20:24:08] Ulrich: I am angry about situation
[18.06.2010 20:24:28] Ulrich: and not get informed in advance from Alex
[18.06.2010 20:25:54] Maria: and changes I ashed for in last time, I always asked is that possible for this date? Ald programmers says 'no problem'this is normal humen neature. it's better to make smth new then fix error.
but also it is normal to have bugs in a program. programs with no bugs are not exists. this is normal.
[18.06.2010 20:27:21] Ulrich: this I know also I'l accept known small errors, which do not disturb the normal work
[18.06.2010 20:27:38] Maria: yes
[18.06.2010 20:28:22] Maria: and sometime bugs from tester that is critical are not so critical from you side.
[18.06.2010 20:28:26] Ulrich: but when You, as quality contoler tells me, that te software is not ready to give to a customer, what should I do?
[18.06.2010 20:28:42] Ulrich: ignore it?
[18.06.2010 20:28:59] Ulrich: then I do not neeed a quality control
[18.06.2010 20:29:46 | Изменены 20:31:30] Ulrich: When I cannot trust in the result I get, must test all by myselfe....
[18.06.2010 20:31:32] Maria: then I do not neeed a quality control

with this proccess - yes
is you'll get only tested version - then you can decide if you agry with this conlusion or not, according to the known bugs. if we do not know what bugs are it - then I do not know what to do - then I say, it's not ready.
[18.06.2010 20:32:28] Maria: When I cannot trust in the result I get, must test all by myselfesure, version after debug SHOULd be tested!! if not by tester then by you
[18.06.2010 20:34:05] Ulrich: sure
[18.06.2010 20:34:21] Ulrich: but sometime I think, better to have testers here
[18.06.2010 20:34:38] Ulrich: ok
[18.06.2010 20:34:57] Ulrich: this I will discuss with Alex next week
[18.06.2010 20:35:05] Maria: I see
[18.06.2010 20:35:15] Ulrich: As I see, i have the same situation as before
[18.06.2010 20:35:46] Ulrich: Andrey told me, that most stable version is 7.2.1.4
[18.06.2010 20:35:58] Ulrich: this I will take to install next week
[18.06.2010 20:36:18] Ulrich: but it is untested by you
[18.06.2010 20:38:39] Maria: As I see, i have the same situation as beforewe never had such big program as Logimen7

smaller program webstation - is a stable version we made a lot oftesting cycles and now make new features only, and do not neww million+1 cycles to give it to the customer - all customers problems about I know , comes from the service (program was not updated, or database works wron or...)
[18.06.2010 20:41:09] Maria: Andrey told me, that most stable version is 7.2.1.4this is the last one. Irina will test it next week, I'll be with webstation and BO .
[18.06.2010 20:41:19] Ulrich: at the moment we have 1 customer who really works with webstation
[18.06.2010 20:41:36] Ulrich: Feiburg still not accepted it
[18.06.2010 20:42:21] Ulrich: today I had a meeting with them.
[18.06.2010 20:42:44] Ulrich: they give us one last chance to get it run
[18.06.2010 20:42:48] Maria: Feiburg still not accepted itthey have very old version of the service as I know
[18.06.2010 20:43:10] Ulrich: as I know it is actualized
[18.06.2010 20:43:50] Ulrich: monday we install the version Sasha sent us
[18.06.2010 20:44:06] Ulrich: but there still is an error, where we need sasha
[18.06.2010 20:44:24] Ulrich: weekly plan loads only half of plan
[18.06.2010 20:45:19] Ulrich: it seems like it stoppes somwhere in the middle.
but this will talk tobi with sasha next week
[18.06.2010 20:45:36] Maria: he does not know about this problam. is it in Stationbedart tab Wochenblatt section?
[18.06.2010 20:46:00] Maria: it seems like it stoppes somwhere in the middle.
but this will talk tobi with sasha next weeki see
[18.06.2010 20:46:00] Ulrich: I got this problem today
[18.06.2010 20:46:23] Ulrich: we cannot reproduce it in leonberg
[18.06.2010 20:46:28 | Изменены 20:46:44] Ulrich: it is in Freiburg only
[18.06.2010 20:47:21] Maria: i see
[18.06.2010 20:47:49] Ulrich: I go home now
[18.06.2010 20:48:04] Ulrich: have a nice evening and a nice weekend
[18.06.2010 20:48:05] Maria: have a nice weekend.
[18.06.2010 20:48:15] Maria: thank you for talking to me
[18.06.2010 20:48:24] Maria: thank you
[18.06.2010 20:48:29] Ulrich: thank you (testing LMV7 (sweat))

Во время этого разговора, я сказала Саше: "кажись, меня увольняют" . Но, на следующий день я вышла на работу, и все было как обычно. Да, тут можно удивиться, до родов 19 дней - а я на работу? Да, таки да. я перестала ходить на работу за 2 недели до родов, потому что уже не могла ходить, однако еще неделю я работала из дома, пока могла сидеть . За неделю до родов я могла только лежать.
За несколько дней до нашей выписки (а выписались мы на 6е сутки), Сашу вызвали на работу, где сообщили, что я уволена. Отдел тестеров расформировали, в Германии будет свой тестер.

P.S.
Роды прошли для меня очень тяжело физически (во время кесарево, моему сыну спасли жизнь) в эмоциональном плане. Мне казалось. что жизнь моя закончена,я все время плакала. меня удерживало то, что я смогу первое время работать из дома (с директором было договорено,что первые 3 месяца я буду из дома работать в основном). На третий день после выписки, я сидела за компьютером и работала (я тогда еще ничего не знала)

P.Р.S. Такое ощущение, что меня вышвырнули как собаку, никто из начальства не потрудился со мной поговорить лично или по скайпу, почти никто из коллег не потрудился выразить свое мнение, никто даже не скинулся мне на рождение, кроме Иры Б. она и написала и подарила подарок, и вообще поддержала. Спасибо. Я никому не сдавала дела, "отходной" мне тоже не поставили. Меня не стало. всем добавили 10% к ЗП, купили кофеварку и наняли уборщицу.
Кстати, когда Саша мне сказал, об этом, я была в шоке и поперлась на собеседование в ГЛ. очень ольшая ошибка: во первых мыслительный процесс еще не восстановился, из за этого на технические вопросы я отвечала не очень хорошо, но и собеседование проводилось предвзято , мне поставили 2 по английскому )) люди, уровень которых был далеко не выше моего. короче это мою самооценку и желание жить убило. Люди, не ходите через 3 недели после родов на собеседование!

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

• Тестирование функций (Functional testing)
• Тестирование безопасности (Security and Access control testing)
• Тестирование взаимодействия (Interoperability testing)

Нефункциональные виды тестирования (НФВД)
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик ПО, которые могут быть измерены различными величинами. Это тестирование КАК система работает. Основные виды НФВД:

• Все виды тестирования производительности

  нагрузочное тестирование (Performance and Load testing)

  стрессовое тестирование (Stress testing)

  тестирование стабильности или надежности (Stability/Reliability testing)

  объемное тестирование (Volume testing)

• Тестирование установки (Installation testing)
• Тестирование удобства пользования (Usability testing)
• Тестирование на отказ и восстановление (Fail-over and Recovery Testing)
• Конфигурационное тестирование (Configuration testing)

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

• Беглое тестирование (Smoke testing)
• Регрессионное тестирование (Regression testing)
• Тестирование сборки (Build Verification testing)
• Санитарное тестирование или проверка согласованности/исправности (Sanity testing)

fgfgf

fgfgf

SDP and testing in it 1.5
Requirements testing and analysis 1.5
Test Documentation 2
Test Reports and metrics 0
Testing types and classification 1.5
Testing techniques practice 2
Risk management 0
English 2
: По 5 бальной шкале
Very weak candidate, insufficient knowledge almost in all aspects of Software Testing.

http://www.it4business.ru/video/2180/

http://www.it4business.ru/lib/1362/

02.11.2009 от EOK

Сейчас ночь с воскресенья на понедельник, 1-2 ноября 2009 г. Завтра Украина ожидает прибытия мудрых экспертов ВОЗ, завтра должна дать ответ некая особо правильная Лондонская лаборатория.

Я искренне собирался написать о гриппе через пару дней - уж очень хотелось дождаться хоть какой-нибудь адекватной и объективной информации. Но вот только что разговаривал со знакомой медсестрой, которая работает в поликлинике. Ей позвонила начальница (зав. отделением) и сказала: завтра на работу, так чтоб с собой принесла 3 маски. На вполне справедливое возражение, дескать, где ж я их возьму, последовал более чем адекватный по нынешним украинским реалиям ответ: «твои проблемы, приказ главврача, ночь длинная, сошьешь…». Эта информация стала последней каплей: похоже, молчать больше нельзя, надо говорить.

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

В пятницу я разговаривал с руководителем одного из Харьковских телеканалов. Выяснилось, что шансов поговорить с жителями города нет никаких. Абсолютно все время занято политиками. Вечером того же дня шло шоу Савика Шустера, посвященное ситуации в Украине в связи с гриппом. Это шоу было моим самым большим потрясением за последние годы: такого жгучего стыда за собственную страну я не испытывал никогда… В субботу, наивная душа, позвонил в Киев. Говорил не с самыми последними людьми на телевидении. Сказал, что готов приехать, что стыдно, что надо успокоить людей, что это ж национальный позор… Люди постарались помочь. Не смогли. Причин не объясняли. И так все ясно. Грипп и выборы так же несовместимы, как грипп и аспирин - куча осложнений (не на печень, так на мозги).
Конкретная информация

На Украине с максимально возможной вероятностью эпидемия ОСТРОЙ РЕСПИРАТОРНОЙ ВИРУСНОЙ ИНФЕКЦИИ.

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

Теоретически здесь я должен дать (и даю) ссылку на главу из своей книги про ОРЗ (профилактика ОРВИ) и замолчать, поскольку все уже сказано. Но практически давайте все самое главное еще раз повторим.

Если вы (ваш ребенок) встретитесь с вирусом, а у вас нет в крови защитных антител, вы заболеете. Антитела появятся в одном из двух случаев: либо вы переболеете, либо вы привьетесь.

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

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

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

Основная польза всех этих лекарств - психотерапия. Вы верите, вам помогает - я рад за вас, только не надо штурмовать аптеки - оно того не стоит.

3. Источник вируса - человек и только человек. Чем меньше людей, тем меньше шансов заболеть. Карантин - замечательно! Запрет на массовые сборища - прекрасно! Пройтись остановку пешком, не пойти лишний раз в супермаркет - мудро!

4. Маска. Полезная штука, но не панацея. Обязательно должна быть на больном, если рядом здоровые: вирус она не задержит, но остановит капельки слюны, особо богатые вирусом.

5. Руки больного - источник вируса не менее значимый, чем рот и нос. Больной касается лица, вирус попадает на руки, больной хватает все вокруг, вы касаетесь этого всего рукой, - здравствуй, ОРВИ.

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

Учитесь сами и учите детей, если уж нет платка, кашлять-чихать не в ладошку, а в локоть.

Начальники! Официальным приказом введите в подчиненных вам коллективах запрет на рукопожатия.

Пользуйтесь кредитными карточками. Бумажные деньги ­- источник распространения вирусов.

6. Воздух!!! Вирусные частицы часами сохраняют свою активность в сухом теплом и неподвижном воздухе, но почти мгновенно разрушаются в воздухе прохладном, влажном и движущемся. В этом аспекте митинг в центре Киева, на который собралось 200 000 человек, менее опасен, чем собрание 1000 человек в клубе в Ужгороде.

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

Оптимальные параметры воздуха в помещении - температура около 20 °С, влажность 50-70%. Обязательно частое и интенсивное сквозное проветривание помещений. Любая система отопления сушит воздух. Именно начало отопительного сезона стало началом эпидемии! Контролируйте влажность. Мойте пол. Включайте увлажнители воздуха. Настоятельно требуйте увлажнения воздуха и проветривания помещений в детских коллективах.

Лучше теплее оденьтесь, но не включайте дополнительных обогревателей.

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

Увлажняйте слизистые оболочки! Элементарно: 1 чайная ложка обычной поваренной соли на 1 литр кипяченой воды. Заливаете в любой флакон-пшикалку (например, из-под сосудосуживающих капель) и регулярно пшикаете в нос (чем суше, чем больше народу вокруг - тем чаще, хоть каждые 10 минут). Для той же цели можно купить в аптеке физиологический раствор или готовые солевые растворы для введения в носовые ходы - салин, аква марис, хумер, маример, носоль и т.д. Главное - не жалейте! Капайте, пшикайте, особенно тогда, когда из дома (из сухого помещения) вы идете туда, где много людей, особенно если вы сидите в коридоре поликлиники.

В отношении профилактики это все.
Лечение

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

Тамифлю реально разрушает вирус, блокируя белок нейраминидазу (ту самую N в названии H1N1).

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

Внимание!!!

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

ГРИПП - ЛЕГКАЯ БОЛЕЗНЬ ДЛЯ БОЛЬШИНСТВА.

Лечение ОРВИ вообще и гриппа в частности - это не глотание таблеток! Это создание таких условий, чтоб организм легко с вирусом справился.

ПРАВИЛА ЛЕЧЕНИЯ.

1. Тепло одеться, но в комнате прохладно и влажно. Температура около 20 °С, влажность 50-70%. Мыть полы, увлажнять, проветривать.

2. Категорически не заставлять есть. Если просит (если хочется) - легкое, углеводное, жидкое.

3. Пить (поить). Пить (поить). Пить (поить)!!!

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

4. В нос часто солевые растворы.

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

6. Если надумали бороться с высокой температурой - только парацетамол или ибупрофен. Категорически нельзя аспирин.

Главная беда в том, что тепло одеть, увлажнить, проветрить, не пихать еду и напоить - это по-нашенски называется «не лечить», а «лечить» - это послать папу в аптеку…

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

8. Противоаллергические средства не имеют к лечению ОРВИ никакого отношения.

9. Вирусные инфекции не лечатся антибиотиками. Антибиотики не уменьшают, а увеличивают риск осложнений.

10. Все интерфероны для местного применения - лекарства с недоказанной эффективностью или «лекарства» с доказанной неэффективностью.

11. Гомеопатия - это не лечение травами, а лечение заряженной водой. Безопасно. Психотерапия (надо что-то делать).
Когда нужен врач

ВСЕГДА!!!

Но это нереально. Поэтому перечисляем ситуации, когда врач нужен обязательно:

* отсутствие улучшений на четвертый день болезни;

* повышенная температура тела на седьмой день болезни;
* ухудшение после улучшения;
* выраженная тяжесть состояния при умеренных симптомах ОРВИ;
* появление изолированно или в сочетании: бледности кожи; жажды, одышки, интенсивной боли, гнойных выделений;
* усиление кашля, снижение его продуктивности; глубокий вдох приводит к приступу кашля;
* при повышении температуры тела не помогают, практически не помогают или очень ненадолго помогают парацетамол и ибупрофен.

Врач нужен обязательно и срочно:

* потеря сознания;
* судороги;
* признаки дыхательной недостаточности (затрудненное дыхание, одышка, ощущение нехватки воздуха);
* интенсивная боль где угодно;
* даже умеренная боль в горле при отсутствии насморка;
* даже умеренная головная боль в сочетании с рвотой;
* отечность шеи;
* сыпь, которая не исчезает при надавливании на нее;
* температура тела выше 39 °С, которая не начинает снижаться через 30 минут после применения жаропонижающих средств;
* любое повышение температуры тела в сочетании с ознобом и бледностью кожи.

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

Все остальное я пишу в надежде, что какой-нибудь кандидат в президенты, или жена кандидата, или муж кандидата, или советник кандидата, или жена советника все-таки прочитает да подумает, проанализирует… В конце концов, прочитал же президент Медведев статью Ходорковского, а вдруг и мне повезет…
Отражение первое:

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

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

Другой кандидат в президенты горько сетует, что в нашей стране нет оксолиновой мази, и преступные фармацевты ее не завезли. Разумеется, никто из присутствующих не смог объяснить кандидату, что эффективность оксолиновой мази не доказана, и ее не завезли и не собираются завозить ни в США, ни во Францию, ни в какую другую страну.

Ну да ладно. Среди кандидатов в президенты врачей нет, а иметь медицинского советника, по-видимому, очень дорого. Но есть ведь и политики-врачи!

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

Кого будут слушать те, кто принимает решения?

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

Совет власти: попросите экспертов ВОЗ составить список обязательных лекарств.
Отражение второе:

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

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

От всех этих заявлений у рядового обывателя создается впечатление, что врачам известны некие тайные лекарства, которые могут помочь при ОРВИ.

Ну вот я врач, который занимается лечением ОРВИ без малого тридцать лет. Вот придет ко мне пациент в первый день болезни (т.е. своевременно) и скажет - помогите! Что я ему отвечу? Да все то, что написано выше: увлажнить, проветрить, не кормить, напоить, лекарств не надо. И он мне поверит.

А что делать врачу, от которого все хотят золотой таблетки? Который точно знает, что за десять ненужных лекарств скажут спасибо, а за инструкцию о правилах адекватной помощи обвинят в невнимательности: что это за врач, который не назначил лекарств!

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

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

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

О слухах.

Студент-заочник Харьковской юридической академии умер в Донецке от осложнений после операции. Все это произошло в разгар «успокаивающих» выступлений наших политиков, поэтому все студенты, контактировавшие с погибшим, почувствовали недомогание, и один даже был госпитализирован.

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

Вот текст письма, полученного мною (таких было много, это самое показательное):
СРОЧНО!!! Доктору Комаровскому
Добрый день!
Помогите, пожалуйста, разобраться. Из многих (неофициальных) источников: сегодня в ночь с 30 на 31 над Киевом будут распылять какое-то вещество, якобы для защиты от гриппа или профилактики. Для меня, звучит нелепо, и я бы не обращалась к вам с этим вопросом, если бы
а) мне об этом не сообщил редактор милицейского издания, кот-ому, по его словам сообщили работники органов, кот-ые будут непосредственно проводить операцию.
б) подруга, знакомый кот-ой работает в Аппарате Президента и говорит, что инф-ция достоверная.
в) соседка, у кот-ой кто-то работает в санстанции и этот кто-то сообщил, что с 12 до 5 утра будут распылять, нужно закрыть окна и потом 2 дня не высовываться.
г) незнакомый человек в интернете на форуме, утверждающий, что вирус гриппа, очень вероятно, произведен в лаборатория Украины и его уже распылили над ее западными областями. А по поводу распыления чего-то над Киевом 30 окт уверен, т.к его отец работает на авиазаводе и у них для этого. нанимали самолеты.
д) девушка-студентка с запада Украины говорит, что у них пару дней назад летали самолеты и что-то распыляли.
Итак, вопрос:
1. Существует ли это вещество-защита от гриппа для распыления с самолета, что это каков механизм его действия
2. Есть ли опасность для маленького ребенка?
3. Сколько времени не выходить из дому?
4.Если они распыляют не антигрипп, а что-то другое, то что это может быть.
Спасибо большое. К. г.Киев

Вопрос: до чего надо довести народ, чтобы люди в подобное верили?

Тем не менее по сравнению с заявлением о легочной чуме - все это цветочки.

Для тех, кто мог не то чтобы поверить, а даже усомниться: во-первых, при легочной чуме никто не обращается в больницу на 7-й день болезни - к этому дню уже успевают завянуть цветы на могиле; во-вторых, при легочной чуме заболевают все, контактировавшие с больным, и умирают 100%. Но если лечить, умирает всего 10%. Так что персонал больниц уже весь должен был заболеть…

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

Кстати, в четверг, у того же Савика Шустера была в шоу Барбара Брыльская. Когда узнала, что речь пойдет о гриппе, сказала: я в этом ничего не понимаю, встала и ушла. Вот пример замечательный!
Отражение четвертое

Почему остались беззащитными врачи? Почему в ситуации, когда мы точно знали, что есть свиной грипп и что он будет у нас осенью, почему врачи, которые 100% от вируса не спрячутся, не были в сентябре от свиного гриппа привиты да и сейчас не прививаются?

На Украине нет вакцины. Даже для врачей. Поэтому сейчас, в разгар эпидемии, врачи лягут в кровати первыми или будут принимать с соплями (про медсестер, которые будут дома шить маски, я вообще молчу). Могли ли мы купить (заказать вакцину) хотя бы для врачей, хотя бы в ограниченном количестве? НЕ МОГЛИ.

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

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

Прививки, которые отодвинули угрозу дифтерии, полиомиелита, кори… Болезни, которые наши СМИ массово пытаются приблизить - сделать угрозой реальной. Вот тогда будет, о чем поговорить. Кстати ровно неделю назад местная новостная компания захотела пообщаться со мной на тему гриппа, и я 15 минут распинался да рассказывал. Из всего разговора оставили да показали 15 секунд, в течение которых я сказал о том, что эпидемия гриппа - хороший повод заработать производителям вакцин и что нет ничего плохого в том, чтобы продавать качественный товар.

ИТОГИ

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

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

Нам очень не повезло, что так все совпало: кризис, выборы, осень, грипп.

Но мы твердо должны знать и понимать: сопли, кашель температура - это ОРВИ. Самая распространенная и легкая болезнь. Требующая спокойствия и совершенно конкретных, элементарных действий, вполне доступных людям с любым уровнем материального благосостояния.

Какие это действия - см. выше.

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

P.S.S.

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

Т.е. я знаю, что чувствует человек, когда знает: у него болезнь, от которой он умрет.

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

Я только не пойму: зачем и за что они все это делают с нашим народом?

Источник: http://www.komarovskiy.net/blog/svinoy-gripp.html

приятно, что в музыку :)

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

рабочее настроение на нуле - много ж я натестирую до завтра, учитывая, что сейчас пол четвертого

источник Марина Лапшина