vga's blog
Welcome to my Blog
Russian ABAP Developer's Club Forum Index -> Blogs -> vga's blog

Users browsing this blog: None

Testing Overview | Типы тестирования

Thu Apr 10, 2008 9:22 pm

[ Category: Шаблоны документов ]
This Article defines the various types of testing from a technical perspective. For most SAP projects, the key types of testing are discussed in Process terms – Unit Testing and Integration Testing. It is important to understand how all types of testing are used to ensure quality and completeness.

These definitions should be used to help ABAP Developers understand how testing fits into the context of the project.

A. Unit Testing.

In the context of an SAP project, the term 'Unit testing' is used by Process Team Members to signify any testing done to validate that configuration is working as intended. This is usually part of an iterative process. A design is created based on a business process. This design mandates that certain configuration be completed in SAP. As this configuration is done, small tests are done along the way to ensure that it is working as intended. Once all of the Unit Testing has been completed successfully, the configuration is considered complete.

In summary:
Owner – Process Team Member
Objective – Ensure that configuration works as intended
System – Development System

B. Technical Testing.

Technical Testing – Technical Regression Testing and Development Unit Testing. Technical testing is done to ensure that ABAP programs are working as intended. There are two types of testing which will be done to verify ABAP programs:
  • Technical Regression Testingis the testing which a developer does after completing the ABAP programs. This testing is done to verify that everything functions as designed – prior to involving a Process Team Member for further testing. If a “bug” is identified by a Process Team Member, a Developer will make the change and run a series of regression tests to ensure that the unaffected parts of the program are still in working order.

    Owner – Developer
    Objective – Test basic functions of program prior to involving the Process Team
    System – Development System

  • Development Unit Testing is the testing done by a Process Team Member to verify that the development is working as requested in the Functional Specification. Every development/FRICE object must be unit tested by the Process Team prior to moving it to the quality environment for Integration Testing.

    Owner – Process Team Member
    Objective – Verify that the development works as requested in the Functional Specification document
    System – Development System

C. Integration Testing

Integration Testing – Development objects will also be part of Integration Testing. Process Team Members must perform certain tests to ensure that these development items work in the context of a business scenario. For example, if an enhancement has been made within the 'Change Order' processing, this enhancement will be tested within Integration Tests designed to change orders. It is at this stage that development objects must be executed against 'production-level' security and the expected results validated.

Owner – Process Team Member
Objective – Verify that development objects work in integration environment
System – Quality System

D. Stress Testing

Stress Testing – This system must be able to accommodate the peak loads that will be placed on it as part of normal business conditions. Stress Testing is the act of testing the system performance by simulating peak business volumes. A substantial amount of analysis must be done to analyze and simulate these business conditions.

Stress Testing is usually owned by the Basis Team. This team works with the Process Teams to understand the peak business volumes to be placed on the system. This analysis helps the Basis Team create 'day in the life' scenarios which are re-created using a testing tool. They also create other scenarios to simulate activities like quarterly close and year-end close. The Process Teams are also involved to help set-up data required for these tests.

Load Testing is also done within the Stress Testing phase. This would involve identifying the peak loads for specific activities and using scripts to simulate these loads. The impact on the system would be analyzed. Any bottlenecks would be identified and a plan would be created to resolve these capacity issues. Some solutions may involve changing software settings while others will involve purchasing and installing new hardware.

A testing tool is usually used to 'record' and 'rerun' tests in order simulate system activity. For example, if the peak period for order entry includes a time where 60 Customer Service Representatives are entering orders, this can be recreated by the tool. An order entry scenario is 'recorded' and then 'played back' to simulate the affect of having 60 different orders occurring at once.

Owner – Basis Team
Objective – Verify that the system architecture can accommodate peak system loads
System – Quality System or additional environment created only for stress testing



Posted By: vga    0 Comments    С уважением, vga

Trackbacks (0) Permalink

Шаблоны документов: Информация о версии (Release Notes)

Sun Feb 24, 2008 5:07 pm

[ Category: Шаблоны документов ]

Титульный лист

<Project>

Release Notes

Версия 1.0

Дата создания


Подготовлен:
Фамилия И. О.
E-mail:

Контактная информация:
Фамилия И. О.
E-mail:


Полное название организации
Адрес:
Телефон:

1. Введение

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

1.2 Предмет
Предметом данного документа является релиз продукта <Project>.

1.3 Ссылки
[Данный подраздел предоставляет полный список всех документов, на которые имеется ссылка где-либо в Project Proposal.]

НомерНазваниеДата и ИздательствоАвторКомментарий
-----


2. Описание релиза

<INSERT>
[Этот раздел содержит информацию о версии, о том, что вошло в этот релиз, о документации, лицензировании и т.д.]

3. Совместимые продукты

<INSERT>
[Данный раздел включает в себя информацию по программному обеспечению, взаимодействующему с другими системами, а также информацию о совместимости различных версий.]

4. Установка и обновление

<INSERT>
[Этот раздел содержит указания по инсталляции продукта (или ссылки на документы, описывающие процесс инсталляции), инструкции по преобразованию данных (если необходимо), и т.д.]

5. Новые возможности

<INSERT>
[Список всех новых возможностей продукта.]

6. Известные ошибки и ограничения

<INSERT>
[Список всех известных ошибок и ограничений, с предложениями по тому, как их обойти.]

История изменений

Person NameTitleApproval DateStatus
----



Posted By: vga    32 Comments    С уважением, vga

Trackbacks (0) Permalink

Шаблоны: Запрос на изменение (Software Change Request)

Sat Feb 16, 2008 4:18 pm

[ Category: Шаблоны документов ]

Титульный лист

<Project>

Software Change Request

Версия 1.0

Дата создания


Подготовлен:
Фамилия И. О.
E-mail:

Контактная информация:
Фамилия И. О.
E-mail:


Полное название организации
Адрес:
Телефон:

1. Введение

1.1 Назначение
Документ Software Change Request описывает изменения, которые предлагается внести в <Project>, включая подробное описание новых требований к продукту, с точки зрения бизнес-процессов. Наряду с функциональными изменениями, он также описывает и нефункциональные, а также изменения в проектных требованиях и ограничениях и другие факторы, необходимые для предоставления полного и ясного описания требований к продукту.
Данный документ создается каждый раз, когда подается формальный запрос на изменение какого-либо элемента проекта.

1.2 Предмет
Предметом данного документа является описание изменений, которые необходимо внести в продукт <Project>, а также изменение его особенностей и требований к нему.

1.3 Термины, определения и соглашения
1.3.1 Аббревиатуры
<INSERT>
1.3.2 Соглашения
<INSERT>

1.4 Ссылки
[Данный подраздел предоставляет полный список всех документов, на которые имеется ссылка где-либо в Project Proposal.]

НомерНазваниеДата и ИздательствоАвторКомментарий
-----


2. Описание изменений

<INSERT>
[Этот раздел кратко излагает суть запрашиваемого изменения]

1.1 Описание
<INSERT>
[Этот раздел подробно описывает обстоятельства, вызвавшие необходимость внесения изменения и описание этого изменения.]
1.1.1 Основные обстоятельства
<INSERT>
[Информация о причинах запроса на изменение.]
1.1.2 Примеры
<INSERT>
[Дополнительная информация, т.е. отчеты об ошибках, скрин-шоты отображающие некорректное поведение продукта и т.д.]

3. Оценка запроса на изменение

1.2 Область действия изменения
<INSERT>
[Оценка области действия изменения, с приведением списка всех объектов проекта, на которые окажет влияние вносимое изменение, включая всех лиц, подлежащих информированию.]
1.2.1 Необходимая техническая работа
<INSERT>
[Описание работ, которые должны быть выполнены для завершения внесения изменений]
1.2.2 Инструментарий, особые ресурсы
<INSERT>
[Здесь указывается необходимый инструментарий и прочие особые ресурсы]

1.1 Описание объектов проекта, затрагиваемых данным измененияем
<INSERT>
[Этот раздел рассказывает об объектах проекта, на которые повлияет данное изменение.]

1.2 Интеграционные эффекты
<INSERT>
[Влияние изменения на прочие системы.]

1.3 Технические риски
<INSERT>
[Описать риски, связанные с внесением изменения.]

1.4 Причина и правомерность
<INSERT>
[Этот раздел рассказывает о том, почему запрашивается данное изменение и приводятся подтверждения его правомерности.]

1.5 Предполагаемые последствия
<INSERT>
[Здесь описываются предположения подателя запроса относительно последствий данного изменения.]

1.6 Альтернативы
<INSERT>
[Мнение подателя запроса относительно наличия альтернатив данному изменению.]

1.7 Приоритет для подателя запроса
<INSERT>
[Обычно приоритет, приписываемый подателем запроса определенной работе оценивается по пятибалльной шкале.]

4. Стоимостная оценка

<INSERT>
[Этот раздел содержит стоимостную оценку внесения запрашиваемого изменения, включая оценку времени и усилий, которые должны быть потрачены.]

5. Рекомендации и выводы

<INSERT>
[Этот раздел представляет рекомендации в отношении изменения, его внутренний приоритет, и окончательные выводы в отношении запроса.]

1.1 Рекомендации
<INSERT>
[Должны ли вноситься эти изменения?]

1.2 Внутренний приоритет
<INSERT>
[Насколько важно это изменение в свете продолжающихся работ, и прочих аспектов бизнеса и продукта?]

1.3 Вывод
<INSERT>
[Будет ли сделано изменение и если да, то когда?]

6. Изменения проектной документации

<INSERT>
[Этот раздел содержит описание изменений в проектной документации, которые необходимо внести.]

7. Требования к проверке

<INSERT>
[В данном разделе необходимо дать описание деятельности SQA (Software Quality Assurance) и методов тестирования, необходимых для обеспечения гарантий того, что изменение не вызовет побочных эффектов.]

1.1 План пересмотра/переоценки
<INSERT>
[Здесь необходимо указать все пересмотры и переоценки, которые могут быть проведены.]

1.2 Тест-план
<INSERT>
[Описать план повторного тестирования и новых тестов, которые понадобяться]

8. Изменения

Person NameTitleApproval DateSignature
----


История изменений

Person NameTitleApproval DateStatus
----



Posted By: vga    142 Comments    С уважением, vga

Trackbacks (0) Permalink


Blog Owner: vga
Contributors: (none)
Blog: View All Entries
Friends
Go: Back/Forward

Calendar

 «   <   »   >  November 2024
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


Contact vga

Email
Send Email
Private Message
Send private message
MSN Messenger


Yahoo Messenger

AIM Address

ICQ Number

About vga

Joined
Thu Oct 04, 2007 8:22 pm

Location
Санкт-Петербург
Occupation

Interests

Blog

Blog Started
Thu Jan 24, 2008 10:11 am
Total entries
13
Blog Age
6148 days
Total replies
8
Visits
1910064

RSS

RSS Feed
Powered by phpBB © 2001, 2002 phpBB Group & by Hyperion Blog MOD & Template by emo_boy