Слайды к вебинару, который прошел 18.11.2013.
В ходе вебинара вы:
- Узнаете о том, как из 7 простых принципов возникает стройная тестовая система
- Поймете почему тестирование никогда не станет полностью автоматизованым
- Узнаете как на практике применять каждый из основных принципов
Больше информации по ссылке: http://coach.ak-itconsulting.com/2013/11/7-principov-testirovaniya/
В работе приведен обзор 7 классов метрик и более 50 их представителей, дано детальное описание и используемые алгоритмы вычисления, описана роль метрик в разработке программного обеспечения.
В преддверии тренинга Тест-дизайн и все все все, который пройдет этой осенью в четырех городах (24-25 сентября в Харькове; 15-16 октября в Нижнем Новгороде; 29-30 октября в Москве; 18-19 ноября в Самаре) Александр Федоров решил лучше познакомиться со своей аудиторией и провести бесплатный вебинар Тест-дизайн «в цикле».
Любые процессы цикличны по своей природе, и разработка тестов не исключение. Тест-кейсы придумываются, создаются и используются на продукте и иногда в его последующих версиях. На разных этапах разработки к тестированию и тест-дизайну выдвигаются разные требования, которые мы рассмотрим в рамках вебинара.
Особенности тест-дизайн при итерационной разработке
Польза и спорная эффективность автоматизации тестирования
Наследование тест-кейсов новыми и «родственными» версиями продукта
Поддержание тест-кейсов в актуальном состоянии на разных этапах жизненного цикла продукта
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Слайды к вебинару, который прошел 18.11.2013.
В ходе вебинара вы:
- Узнаете о том, как из 7 простых принципов возникает стройная тестовая система
- Поймете почему тестирование никогда не станет полностью автоматизованым
- Узнаете как на практике применять каждый из основных принципов
Больше информации по ссылке: http://coach.ak-itconsulting.com/2013/11/7-principov-testirovaniya/
В работе приведен обзор 7 классов метрик и более 50 их представителей, дано детальное описание и используемые алгоритмы вычисления, описана роль метрик в разработке программного обеспечения.
В преддверии тренинга Тест-дизайн и все все все, который пройдет этой осенью в четырех городах (24-25 сентября в Харькове; 15-16 октября в Нижнем Новгороде; 29-30 октября в Москве; 18-19 ноября в Самаре) Александр Федоров решил лучше познакомиться со своей аудиторией и провести бесплатный вебинар Тест-дизайн «в цикле».
Любые процессы цикличны по своей природе, и разработка тестов не исключение. Тест-кейсы придумываются, создаются и используются на продукте и иногда в его последующих версиях. На разных этапах разработки к тестированию и тест-дизайну выдвигаются разные требования, которые мы рассмотрим в рамках вебинара.
Особенности тест-дизайн при итерационной разработке
Польза и спорная эффективность автоматизации тестирования
Наследование тест-кейсов новыми и «родственными» версиями продукта
Поддержание тест-кейсов в актуальном состоянии на разных этапах жизненного цикла продукта
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Тестирование параллельного программного обеспечения представляет собой более сложную задачу по сравнению с тестированием последовательной программы. Программист должен знать о подводных камнях при тестировании параллельного кода, имеющихся методологиях и инструментарии.
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
TPI Next®: оптимизируем процессы тестирования по-взрослому
Думали ли вы когда-либо о том, к какому уровню зрелости принадлежит ваш процесс тестирования? Или, например, как ответить на вопрос о том, насколько эффективно работает ваша команда тестировщиков? Здесь легче всего дать субъективный ответ, и, например, сказать: мы работаем хорошо, у нас все автоматизировано и мы находим много дефектов.
Однако нельзя расценивать подобный ответ, как корректный. Оценить зрелость и эффективность процесса тестирования по-настоящему можно лишь используя ту или иную модель оценки, каждая из которых имеет массу своих особенностей и не всегда применима в большинстве случаев.
TPI® Next – модель оценки зрелости процессов тестирования в масштабах компании или отдельного проекта. Она помогает понять какими сильными и слабыми сторонами обладает ваш процесс и дает представление о том, в каком направлении двигаться для его оптимизации.
TPI® Next разбивает процесс тестирования на ключевые подобласти, каждая из которых подвергается анализу и получает свою оценку зрелости – от начальной до оптимальной. Делается это на основе четко описанных критериев для той или иной области, что дает возможность дать конкретный ответ на вопрос о том, чего не хватает процессу для перехода на следующую ступень зрелости.
Используя подход, описанный в TPI® Next, я провел оценку зрелости процесса тестирования в нескольких проектах компании в разные периоды их развития. Подвергнув полученные данные анализу, я смог определить каких практик и подходов не хватает той или иной команде для того, чтобы считать свои проекты более зрелыми и эффективными.
Использовав получе
Domain-тестирование – формальное название методики тестирования, за которым скрывается банальная работа с классами эквивалентности. Впрочем, не такая уж и банальная. Даже в популярной литературе по тестированию часто упоминают только о существовании классов эквивалентности и о том, что с их граничными значениями работать очень полезно.
Мы знакомимся с основами этой методики, когда делаем первые шаги в тестировании, и больше никогда о ней не задумываемся, наивно считая, что она попала в нашу зону неосознанной компетентности и мы всегда используем ее правильно. А так ли это?
Техники тест дизайна для черноящичного тестированияDmytro Protsenko
Разобрано на пальцах несколько техник из книги Lee Copeland "A Practitioner's Guide to Software Test Design". Все что касается BlackBox Testing - cгруппированo в три раздела. Oбъяснены секреты магии Pairwise, почему тестирование областей определения переворачивает самолеты и дана краткая инструкция, как вернуть деньги за билет, если в связи с предыдущим пунктом, вы передумали лететь.
Formal Methods in Robotics
Dmitry Mordvinov, Yury Litvinov, Saint Petersburg State University, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
Тестирование параллельного программного обеспечения представляет собой более сложную задачу по сравнению с тестированием последовательной программы. Программист должен знать о подводных камнях при тестировании параллельного кода, имеющихся методологиях и инструментарии.
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
TPI Next®: оптимизируем процессы тестирования по-взрослому
Думали ли вы когда-либо о том, к какому уровню зрелости принадлежит ваш процесс тестирования? Или, например, как ответить на вопрос о том, насколько эффективно работает ваша команда тестировщиков? Здесь легче всего дать субъективный ответ, и, например, сказать: мы работаем хорошо, у нас все автоматизировано и мы находим много дефектов.
Однако нельзя расценивать подобный ответ, как корректный. Оценить зрелость и эффективность процесса тестирования по-настоящему можно лишь используя ту или иную модель оценки, каждая из которых имеет массу своих особенностей и не всегда применима в большинстве случаев.
TPI® Next – модель оценки зрелости процессов тестирования в масштабах компании или отдельного проекта. Она помогает понять какими сильными и слабыми сторонами обладает ваш процесс и дает представление о том, в каком направлении двигаться для его оптимизации.
TPI® Next разбивает процесс тестирования на ключевые подобласти, каждая из которых подвергается анализу и получает свою оценку зрелости – от начальной до оптимальной. Делается это на основе четко описанных критериев для той или иной области, что дает возможность дать конкретный ответ на вопрос о том, чего не хватает процессу для перехода на следующую ступень зрелости.
Используя подход, описанный в TPI® Next, я провел оценку зрелости процесса тестирования в нескольких проектах компании в разные периоды их развития. Подвергнув полученные данные анализу, я смог определить каких практик и подходов не хватает той или иной команде для того, чтобы считать свои проекты более зрелыми и эффективными.
Использовав получе
Domain-тестирование – формальное название методики тестирования, за которым скрывается банальная работа с классами эквивалентности. Впрочем, не такая уж и банальная. Даже в популярной литературе по тестированию часто упоминают только о существовании классов эквивалентности и о том, что с их граничными значениями работать очень полезно.
Мы знакомимся с основами этой методики, когда делаем первые шаги в тестировании, и больше никогда о ней не задумываемся, наивно считая, что она попала в нашу зону неосознанной компетентности и мы всегда используем ее правильно. А так ли это?
Техники тест дизайна для черноящичного тестированияDmytro Protsenko
Разобрано на пальцах несколько техник из книги Lee Copeland "A Practitioner's Guide to Software Test Design". Все что касается BlackBox Testing - cгруппированo в три раздела. Oбъяснены секреты магии Pairwise, почему тестирование областей определения переворачивает самолеты и дана краткая инструкция, как вернуть деньги за билет, если в связи с предыдущим пунктом, вы передумали лететь.
Formal Methods in Robotics
Dmitry Mordvinov, Yury Litvinov, Saint Petersburg State University, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17OdessaFrontend
Если еще несколько лет назад фронтенд это часто был простой и понятный интерфейс между пользователем и бекендом, то на сегодняшний день с учетом обилия фреймворков, либ и все возможных новшеств, фронтенд уже можно считать полноценным отдельным приложение со своей логикой и множеством подводных камней именно по этом сегодня как никогда важно задумываться о том, а как обеспечить простой и понятный процесс тестирования вашего фронта?
Как сделать так чтоб покрытие авто тестами не стало для вас болью или не для вас, но всё еще болью? Дмитрий Хименес обращает ваше внимание на несколько простых моментов, которые стоит учитывать при разработке фронтенда, чтобы сохранить возможность безболезненно сопровождать его автотестами.
Построение систем автоматического протоколирования Си/Си++ кодаTatyanazaxarova
Иногда единственным методом отладки является использование протоколирования событий приложения. К недостаткам протоколирования (логирования) можно отнести большой объем кода, который приходится писать вручную для сохранения всей необходимой информации. В статье рассматривается методика, позволяющая построить систему автоматического протоколирования кода на языке Си/Си++.
Модуль 8. Лекция 37-38. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Планирование управление качеством
● Определение и характеристики дефекта;
● Задачи управления дефектами;
● Классификация важности дефектов;
● Виды тестирования;
● Правильное описание дефекта;
● Жизненный цикл дефекта;
● Работа с базами дефектов;
● Метрики на основе дефектов.
● Составление тест плана
Статья «Формирование универсальных требований к пользовательским программам п...ph.d. Dmitry Stepanov
предлагается обобщенная структура описания программ. Используя предложенную структуру, формулируются универсальные требования, применимые к любым пользовательским разработкам и необходимые в процессе подготовки функционально-технической спецификации на разработку программы.
Андрей Солоной "Как людям бизнеса работать с программистами"Startup_Technologies
Эксперт Startup Weekend, ведущий .NETразработчик и архитектор с большим опытом, ментор в EffectiveSoft Андрей Солоной выступил на Стартап-школе с мастер-классом: "Как людям бизнеса работать с программистами"
Статья «Проблемы внедрения корпоративных информационных систем: уровень при...ph.d. Dmitry Stepanov
рассмотрены проблемы анализа и описания бизнес-процессов заказчика, подготовки и тестирования спецификаций на разработку, обучения пользователей и перехода к продуктивному использованию корпоративной информационной системы. Проанализированы причины возникновения затруднений при внедрении и предложены альтернативные способы решения данных задач.
1. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
1
Лекция 11 (ч.7)
Синтаксис и программные конструкции Visual C
Подготовительный этап
Практическую часть следует начинать с подготовительного этапа.
1. Создать отдельную папку для проекта.
2. Запустить C++ Builder. Сохранить «пустой» проект в подготовленной папке.
3. Расположить на форме (или на формах) выбранные визуальные компоненты.
4. Задать значения свойств визуальных компонентов, влияющие на внешний вид и
функционирование.
Разработка классов
Именно вопросам разработки классов или вопросам создания абстрактных типов данных
(АТД) требуется максимальное время при создании программы. Проекты, использующие
принципы ООП и предназначенные для решения математических задач, рекомендуется
разрабатывать в следующем порядке.
1. Анализ задачи.
На этом этапе выделяются математические объекты, с помощью которых можно описать
решение задачи. Между ними устанавливаются отношения:
Создавая математическую модель для решения задачи, нужно:
- сформулировать предположения, на которых будет основываться математическая
модель;
- определить, что считать исходными данными и результатами;
- записать математические соотношения, связывающие результаты и исходные данные.
2. Программная постановка задачи.
Устанавливает соответствие между возможностями программы и требованиями
пользователя.
3. Разработка интерфейсов класса.
При создании программы, как и при проектировании классов, разработчик должен
изначально исходить из предположения, что предложенная задача со временем может
претерпевать изменения, связанные с возрастанием и изменением запросов пользователя.
Поэтому необходимо предусмотреть механизм, который бы позволял мобильно изменять
интерфейсы классов. Не затрагивая их реализацию. С этой целью имеет смысл сразу
проектировать семейства классов.
В интерфейс вписываются поля и прототипы методов. Для них устанавливаются правила
доступа - public, private, protected. Методы можно разделить на две группы:
· Стандартные методы – конструкторы, в том числе конструктор копирования,
деструкторы, свойства, унарные и бинарные операторы;
· Специфичные методы, которые следуют из логики задачи.
2. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
2
Особое внимание необходимо уделить конструкторам – методам конструирования
объектов. Конструкторы класса требуют тщательной проработки. Их может быть много – «на все
случаи жизни».
4. Формализация методов класса.
Формализация методов класса – это переход от спецификации метода, представляющего
собой словесное описание назначенного метода, представляющего собой словесное описание
назначения метода, к разработке алгоритма, обеспечивающего выполнение соответствующих
действий.
Этап «формализации методов класса» включает в себя разработку алгоритмов и запись
программной реализации этих алгоритмов. Если эти алгоритмы сложные, то их разработку
следует производить в соответствии с технологией нисходящего проектирования программ:
задача разбивается на новые подзадачи и так далее до тех пор, пока на очередном уровне
решение подзадачи не становиться очевидным. В соответствии с такой технологией интерфейсы
классов дополняются новыми методами со своими правилами доступа. Формализация методов
классов – важнейший элемент программирования.
Разработка алгоритма начинается с его словесного описания. В непростых случаях это
словесное описание в учебнике сопровождается демонстрационным примером. Возможным
шагом может быть написание блок-схемы алгоритма. В простом случае можно ограничиться
комментариями в описании кода метода. Иногда спецификация может быть выражена простой
фразой в контексте интерфейса класса. В сложных случаях в учебнике спецификация выводиться
из контекста интерфейса и более подробно описывается.
Разработка интерфейса приложения и его дизайна
Подразумевается, что соответствие интерфейса задачам пользователя является
неотъемлемым его свойством. Существует четыре основных критерия оценивания качества
любого интерфейса, а именно:
· Скорость работы пользователей;
· Количество человеческих ошибок;
· Скорость обучения; субъективное удовлетворение.
Скорость выполнения работ является важным критерием эффективности интерфейса.
Длительность выполнения работы пользователем состоит из длительности восприятия исходной
информации, длительности интеллектуальной работы (пользователь думает, что он должен
сделать), длительность физических действий пользователя и длительности реакции системы. Как
правило, длительность реакции системы является наименее значимым фактором.
3. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
3
Согласно Дональду Норману, взаимодействие пользователя с системой (не только
компьютерной) состоит из семи шагов: формирование цели действий; определение общей
направленности действий; определение конкретных действий; выполнение действий; восприятие
нового состояния системы; интерпретация состояния системы; оценка результата.
Согласно этому списку процесс размышления занимает почти все время, в течение
которого пользователь работает с компьютером. Во всяком случае, шесть из семи этапов
полностью заняты умственной деятельностью. Соответственно, повышение скорости этих
размышлений приводит к существенному улучшению скорости работы.
К сожалению, существенно повысить скорость мышления пользователей не возможно. Тем
не менее, уменьшить влияние факторов, усложняющих процесс мышления, вполне возможно.
Пользователь должен знать:
· Что он хочет получить на выходе (решение задачи);
· Как минимум одну последовательность действий, приводящую к
успешному результату;
· Где ему найти все объекты, участвующие в процедуре решения;
· Как определять пригодность объектов для их использования;
· Как управляться с объектами.
Список довольно внушителен. И если с первым пунктом проблем обычно не возникает, то
остальные требуют определенных усилий. А помочь разобраться в этом должен интерфейс со
встроенной системой подсказок действий. Следовательно, должен быть продуман механизм
управления программой через элементы интерфейса.
Обеспечение функциональности приложения
Обеспечение функциональности приложения связано с разработкой кода программы,
предназначенного для:
· Операций с объектами класса, обеспечивающих их взаимодействие и
согласованную работу;
· Управление программой через элементы интерфейса.
Тестирование приложения
Тестирование программного продукта следует начинать с разработки плана тестирования. При
этом следует помнить, что весь процесс тестирования можно разделить на три этапа:
4. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
4
· Проверка в нормальных условиях. Предполагает тестирование на основе данных, которые
характерны для условий функционирования программы.
· Проверка в экстремальных условиях. Тестовые данные включают граничные значения
области изменения входных переменных, которые должны восприниматься программой
как правильные данные. Типичными параметрами таких значений являются очень малые
или очень большие числа и отсутствие данных. Если один тип экстремальных условий –
это граничные объемы данных, когда массивы состоят из слишком малого или слишком
большого числа элементов.
· Проверка в исключительных ситуациях. Проводится с использованием данных, значения
которых лежат за пределами допустимой области изменений.
Известно, что все программы разрабатываются в расчете на обработку ограниченного
набора данных. Поэтому важно получить ответ на следующие вопросы:
· Что произойдет, если в программе, не рассчитанной на обработку отрицательных и
нулевых значений переменных, в результате какой-либо ошибки придется иметь
дело как раз с такими данными?
· Как будет вести себя программа, работающая с массивами, если количество их
элементов превысит величину, указанную в объявлении массива?
· Что произойдет, если числа будут слишком малыми или слишком большими?
Наихудшая ситуация складывается тогда, когда программа воспринимает не верные
данные как правильные и выдает не верный результат, но правдоподобный результат.
Хорошая программа должна сама отвергать любые данные, которые она не в
состоянии обрабатывать правильно.
Следует попытаться представить возможные типы ошибок, которые пользователь способен
допустить при работе с Вашей программой и которые могут иметь неприятные для нее
последствия. Нужно не забывать, что способ мышления пользователя отличается от способа
мышления программиста. Нужно предусмотреть обработку ошибок типа: отсутствие нудного
файла, неправильные форматы даты и т,д, Список действий, которые могут привести к
неправильному функционированию программы, довольно длинный и зависит от того, что делает
приложение в данный момент времени.
Для тестирования можно изготовить программу, которая будет вызывать выполняемую
процедуру и следить за ходом ее выполнения. Эта подпрограмма должна содержать: подготовку
входных данных, которые должны быть прочитаны из файла для запуска тестируемой
программы; сравнение выходных данных отдельных подпрограмм с контрольными значениями,
которые также извлекаются из файла.