Отчет по практике в ООО «Вип Ай Ти Маркет»

Автор работы: Пользователь скрыл имя, 14 Мая 2014 в 22:01, отчет по практике

Краткое описание

Преддипломная практика была пройдена в отделе тестирования. Целью работы отдела тестирования является:
1. Выявление проблем, связанных с несоответствием разрабатываемого программного продукта – требованиям к нему;
2. Учёт статуса проблем;
3. Снижение рисков проекта, связанных с качеством разрабатываемого продукта.
Задачи отдела тестирования:
1. Разработка тестовых планов и сценариев тестирования;
2. Проведение тестирования на основе сценариев;
3. Составление отчётов об ошибках в процессе тестирования;
4. Подготовка документации к выпуску продукта;
5. Обработка ошибок, найденных в процессе эксплуатации системы;

Прикрепленные файлы: 1 файл

реф.doc

— 541.00 Кб (Скачать документ)

 

 

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

 

Таблица 3. Время создания документа

Тип документа

Строк в документе

Выполняемая операция

Время создания документа, мин

Тестовый сценарий

2–15

Проведение тестового испытания

40

Дефект

20

Исправление дефекта

30

Отчёт по тестированию

30–100

Окончание итерации

120

Пользовательская документация

80 – 400

Эксплуатация программного продукта

480

Выпускная документация

150

Эксплуатация программного продукта

180

Ответ по заявке на дефект

5–30

Внедрение и эксплуатация программного продукта

30


 

Текущий вариант документооборота имеет ряд существенных недостатков:

  • Медленный поиск информации;
  • Сложность контроля состояния документа на этапах его обработки;
  • Сложность масштабирования системы документооборота при увеличении числа сотрудников;
  • Риск потери информации при текучке кадров;
  • Риск потери информации при проведении профилактических работ на рабочих станциях сотрудников;
  • Трудоёмкость получения сводных отчётов о работе отдела.

Таким образом, документооборот в отделе тестирования ООО «Вип Ай Ти Маркет» оказывается неэффективным. Все эти минусы можно избежать, внедрив систему автоматизации бизнес-процессов.

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

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

На рисунке 4 представлена схема документооборота компании.

 

Рисунок 4. Схема документооборота ООО «Вип Ай Ти Маркет»

 

3. Анализ существующих разработок и выбор стратегии автоматизации «КАК ДОЛЖНО БЫТЬ»

 

3.1 Анализ существующих разработок для автоматизации задачи

 

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

  1. Microsoft Visual Studio 2010 Test Professional

Microsoft® Visual Studio® 2010 Test Professional – специализированный набор средств для групп контроля качества, который упрощает планирование и выполнение ручных тестов. Test Professional используется вместе со средой Visual Studio, что обеспечивает эффективную совместную работу разработчиков и тестеров в течение всего цикла разработки приложения.

Преимущества:

  • Эффективное координирование совместной деятельности групп;
  • Более широкое покрытие кода тестами благодаря произвольному тестированию;
  • Полная прозрачность процесса тестирования;
  • Информативные отчеты об ошибках для разработчиков;
  • Автоматизация повторяющихся задач;
  • Встроенные средства приоритезации тестов;
  • Упрощенное управление виртуальной лабораторией тестирования;
  • Управление рабочими элементами;
  • Полная прослеживаемость действий;
  • Отчёты:

 

 

  1. Atlassian JIRA
  2. Atlassian JIRA – коммерческая система отслеживания ошибок, предназначена для организации общения с пользователями, хотя в некоторых случаях систему можно использовать для управления проектами. Разработана компанией Atlassian Software Systems. Платная.

Движения задач / дефектов:

 

 

Отчёты и диаграммы

 

  1. Разработка собственного АРМ специалиста по тестированию

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

В основу конструирования АРМ положены следующие основные принципы:

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

 

В рамках автоматизации отдела тестирования было принято решение разрабатывать собственное АРМ. Это обусловлено балансом между гибкостью системы и возможностью встраивать необходимые артефакты для связи с текущим документооборотом на предприятии.

 

 

3.2 Выбор и обоснование стратегии автоматизации задачи

 

Обычно разработка систем автоматизации специалистами осуществляется в несколько этапов:

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

Существует четыре варианта стратегии автоматизации:

    • хаотичная;
    • по участкам;
    • по направлениям;
    • полная;

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

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

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

Полная автоматизация предполагает автоматизацию абсолютно всех бизнес-процессов компании.

Компания ООО «Вип Ай Ти Маркет» имеет небольшой размер и довольно высокие темпы развития. Поэтом наиболее целесообразной стратегией принято использовать вторую модель автоматизации: автоматизации по участкам (отдел тестирования). С возможностью расширить систему до автоматизации по направлению (полная разработка).

Разработка и внедрение автоматизированной системы документооборота отдела тестирования в компании ООО «Вип Ай Ти Маркет» будет осуществляться следующим образом:

  1. Предпроектный аудит.
  2. Компания-разработчик вместе с Заказчиком проводят предпроектное исследование автоматизируемого участка. Определяются функциональные требования.
  3. Выбор оптимального решения.

На втором этапе Заказчик с Разработчиком выбирают максимально эффективный вариант реализации системы автоматизации.

  1. Разработка технического задания.

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

  1. Кодирование.

Написание кода продукта в соответствии с текстом технического задания. Отладка программы;

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

Проверка работоспособности программы на платформе Заказчика. Все выявленные ошибки отправляются Разработчику на доработку.

  1. Сдача проекта.

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

 

3.3 Выбор и обоснование способа приобретения ИС для автоматизации комплекса задач

 

Существуют различные варианты разработки и внедрения автоматизированных систем документооборота:

  • Разработка системы собственными ресурсами.
  • Использование стороннего разработчика.
  • Использование прототипов.
  • Приобретение готовой системы.

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

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

Использование прототипов – довольно гибкий вариант. Но в настоящее время системы управления тестированием не сильно распространены. А использование прототипов сторонней тематики может обернуться непониманием специалистов терминологии системы.

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

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

 

 

 

4. Обоснование проектных решений

 

4.1 Обоснование проектных решений по информационному обеспечению

 

АРМ специалиста по тестированию используется как основное средство взаимодействия отдела тестирования с отделом программирования и с отделом информационных технологий. Основа АРМ специалиста по тестированию – список дефектов и тестовых сценариев. Эти рабочие элементы должны быть классифицированы.

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

Информация о работе Отчет по практике в ООО «Вип Ай Ти Маркет»