Управление качеством продукции на иностранном предприятии "EPAM Systems"
Отчет по практике - Менеджмент
Другие отчеты по практике по предмету Менеджмент
?ружен техническими подробностями, структурами файлов и прочими технологическими деталями.
Ответственный за спецификацию только один человек. Может быть ответственной и группа людей, если проект очень велик, но даже в этом случае каждый из группы должен отвечать за отдельную часть документа.
Разработка тестовых сценариев
Одним из методов технического контроля качества является составление тестовых сценариев, которые содержат в себе описание тестирования граничных состояний, общий подход к оценке качества ПО и в то же время описывает специфику тестирования каждого отдельно взятого модуля.
Тестовые сценарии разрабатываются в соответствии с функциональной спецификацией.
Использование тестового сценария позволяет снизить влияние человеческого фактора на процесс тестирования: пропускается меньше ошибок, возможность тестирования дополнительных функций и требований, регрессионное тестирование, передача информации, напоминание о тестах некоторой давности, позволяют контролировать результаты и обмен опытом, тестирование можно отслеживать в целом (% сделано), позволяет не упустить ни одно требование.
Следующим этапом контроля качества является тестирование приложений.
Тестирование Web приложений
Основы тестирования Web приложений:
реализация и дизайн
Клиент - сервер установка
WEB-ориентированная помощь
конфигурация
база данных
безопасность
производительность, загруженность и устойчивость к стрессам
При тестировании следует понимать цели и реализацию (технологию)
Два основных класса тестирования:
дизайн компонентов;
реализация компонентов;
Список проверок - максимальный набор тестовых случаев, который может быть использован при составлении тестовых сценариев.
Тестирование навигации:
Навигация должна быть проста, логична, интуитивна. Наиболее используемые функции быстро доступны, доступны посредством клавиатуры и мыши, навигация в прямом и обратном порядке.
Тестирование презентабельности:
Должен быть доступ с разрешениями 1024*768 и 600*800, не должно быть лишних скролов, текст на кнопках д/быть виден полностью, цвета линков соответствующие, без разрывов картинок, цветовой контраст не д/быть низким, без пробелов в таблицах, соответствующим образом оформлены границы, выравнивание, форматирование, правильное расположение всех кнопок, проверка анимации (ненавязчивая, корректно проигрывается).
Обработка ошибок:
сообщение должно максимально обрисовывать проблему, пользователю, предлагать возможные пути выхода из неё, не должны содержать грамматических ошибок. Лучше, если валидация происходит на обмене данных, желательно указание конкретных проблем.
Безопасность:
шифрование
аутентификация
цифровые сертификаты
брандмауэры
авторизация
Тестирование базы данных:
поиск
добавление дублирующейся информации
добавление/редактирование/удаление информации
использование примеров
Производительность, загруженность и устойчивость к стрессам:
доступ нескольких пользователей одновременно
разные приложения
все в одно время
Тестирование производительности - скорость отклика (работы) при многопользовательском режиме;
Нагрузочное тестирование - есть требование к загрузке системы - проверяется всё то же самое на определенном наборе hard-soft configuration;
Стрессовое тестирование - сочетает в себе первые 2 пункта, попытка поставить приложение в стрессовую ситуацию при эмуляции работы многих пользователей - выявить предельно допустимую нагрузку.
2.5 Центр управления проектами-PMC (Project Management Center)
PMC - Это специальный программный продукт, разработанный компанией EPAM Systems, который поддерживает процесс создания программных продуктов.
Для тестирования наиболее важен раздел Bugs, который содержит описание всех найденных ошибок.
Для обеспечения надежности очень важным является правильно документировать найденную ошибку. Тестировщик после обнаружения ошибки передает ее в виде отчета об ошибке программисту.
Отчет об ошибке имеет следующие поля:
Summary - содержит краткое описание ошибки, возникшей в приложении, где она произошла и ее краткая суть.
Build found - версия приложения, где была обнаружена ошибка
Symptom - вид ошибки
Severity - серьезность найденной ошибки
Reproducible - воспроизводимость ошибки
Description - подробное описание ошибки. Приводится для того, чтобы программист понял суть проблемы
Steps to reproduce - шаги для воспроизведения
2.6 Управление продукцией не соответствующей качеству
Программный продукт (ПП) не соответствующий предъявленным к нему требованиям по качеству, как правило, не передается заказчику. По требованию заказчика допускается поставка ПП, прошедшего тестирование с отрицательными результатами. В этом случае заказчик информируется обо всех дефектах, обнаруженных в ПП.
Несоответствующий ПП выявляется на следующих этапах разработки :
при анализе исходной информации, поступающей от заказчика
при разработке программного продукта
при тестировании программного продукта
при эксплуатации программного продукта у заказчика.
Регистрация несоответствующего ПП осуществляется при наличии соответствующих требований в описаниях процессов и документированных процедурах.
ПП, не соответствующий