bug testing

7/27/2019 Bug Testing

1/64

Defect Life Cycle (Bug Life cycle) is the journey of a defect from itsidentification to its closure. The Life Cycle varies from organization to

organization and is governed by the software testing process the Uorganization

or project follows and/or the Defect tracking tool being Used.

Status Alternative Status

NEW

ASSIGNED OPEN

DEFERRED

DROPPED REJECTED

COMPLETED FIXED, RESOLVED, TEST

REASSIGNED REOPENED

CLOSED VERIFIEDDefect Status Explanation

NEW: Tester finds a defect and posts it with the status NEW. This defect isyet to be studied/approved. The fate of a NEW defect is one of ASSIGNED,DROPPED and DEFERRED.

ASSIGNED / OPEN: Test / Development / Project lead studies the NEWdefect and if it is found to be valid it is assigned to a member of theDevelopment Team. The assigned Developers responsibility is now to fixthe defect and have it COMPLETED. Sometimes, ASSIGNED and OPEN

can be different statuses. In that case, a defect can be open yet unassigned.DEFERRED: If a valid NEW or ASSIGNED defect is decided to be fixed in

upcoming releases instead of the current release it is DEFERRED. Thisdefect is ASSIGNED when the time comes.

DROPPED / REJECTED: Test / Development/ Project lead studies theNEW defect and if it is found to be invalid, it is DROPPED / REJECTED.Note that the specific reason for this action needs to be given.COMPLETED / FIXED / RESOLVED / TEST: Developer fixes the defect

that is ASSIGNED to him or her. Now, the fixed defect needs to be

verified by the Test Team and the Development Team assigns the defectback to the Test Team. A COMPLETED defect is either CLOSED, if fine, orREASSIGNED, if still not fine.

If a Developer cannot fix a defect, some organizations may offer thefollowing statuses:Wont Fix / Cant Fix: The Developer will not or cannot fix the defect

due to some reason.


2/64

Cant Reproduce: The Developer is unable to reproduce the defect.Need More Information: The Developer needs more information on

the defect from the Tester.REASSIGNED / REOPENED: If the Tester finds that the fixed defect is in

fact not fixed or only partially fixed, it is reassigned to the Developer whofixed it. A REASSIGNED defect needs to be COMPLETED again.

CLOSED / VERIFIED: If the Tester / Test Lead finds that the defect isindeed fixed and is no more of any concern, it is CLOSED / VERIFIED.This is the happy ending.

Defect Life Cycle Implementation Guidelines-

Make sure the entire team understands what each defect status exactlymeans. Also, make sure the defect life cycle is documented.

Ensure that each individual clearly understands his/her responsibility as

regards each defect.Ensure that enough detail is entered in each status change. For example, do

not simply DROP a defect but provide a reason for doing so.If a defect tracking tool is being used, avoid entertaining any defect related

requests without an appropriate change in the status of the defect in the tool.Do not let anybody take shortcuts. Or else, you will never be able to get up-to-date defect metrics for analysis.

The duration or time span between the first time that the bug is found is called

'New' and closed successfully (status: 'Closed'), rejected, postponed or deferred iscalled 'Bug/Error Life Cycle'.

Right from the first time any bug is detected till the point when the bug is fixed andclosed, it is assigned various statuses which are New, Open, Postpone, PendingRetest, Retest, Pending Reject, Reject, Deferred, and Closed.

There are seven different life cycles that a bug can pass through:

Cycle I

A tester finds a bug and reports it to the Test Lead.The test lead verifies if the bug is valid or not.Test lead finds that the bug is not valid and the bug is 'Rejected'.

Cycle II


3/64

A tester finds a bug and reports it to the Test Lead.The test lead verifies if the bug is valid or not.The bug is verified and reported to the development team with status as 'New'.The development leader and team verify if it is a valid bug. The bug is invalid andis marked with a status of 'Pending Reject' before passing it back to the testingteam.After getting a satisfactory reply from the development side, the test leader marksthe bug as 'Rejected'.

Cycle III

A tester finds a bug and reports it to the Test Lead.The test lead verifies if the bug is valid or not.The bug is verified and reported to the development team with status as 'New'.

The development leader and team verify if it is a valid bug. The bug is valid andthe development leader assigns a developer to it, marking the status as 'Assigned'.The developer solves the problem and marks the bug as 'Fixed' and passes it backto the Development leader.The development leader changes the status of the bug to 'Pending Retest' andpasses it on to the testing team for retest.The test leader changes the status of the bug to 'Retest' and passes it to a tester forretest.The tester retests the bug and if it is working fine, the tester closes the bug and

marks it as 'Closed'.

Cycle IV

A tester finds a bug and reports it to the Test Lead.The test lead verifies if the bug is valid or not.The bug is verified and reported to the development team with status as 'New'.The development leader and team verify if it is a valid bug. If the bug is valid, thedevelopment leader assigns a developer for it, marking the status as 'Assigned'.The developer solves the problem and marks the bug as 'Fixed' and passes it back

to the Development leader.The development leader changes the status of the bug to 'Pending Retest' andpasses it on to the testing team for retest.The test leader changes the status of the bug to 'Retest' and passes it to a tester forretest.The tester retests the bug and the same problem persists, so the tester afterconfirmation from test leader reopens the bug and marks it with a 'Reopen' status.


4/64

And then, the bug is passed back to the development team for fixing.

Cycle V

A tester finds a bug and reports it to the Test Lead.The test lead verifies if the bug is valid or not.The bug is verified and reported to the development team with status as 'New'.The developer tries to verify if the bug is valid but fails to replicate the samescenario as it was at the time of testing, and asks for help from the testing team.The tester also fails to regenerate the scenario in which the bug was found. Andfinally, the developer rejects the bug marking it as 'Rejected'.

Cycle VI

After confirmation that the data is unavailable or certain functionality isunavailable, the solution and retest of the bug is postponed for indefinite time andit is marked as 'Postponed'.

Cycle VII

If the bug does not stand importance and needs to be postponed, then it is given astatus as 'Deferred'.This was about the various life cycles that a bug goes through in software testing.

And in the ways mentioned above, any bug that is found ends up with a status ofClosed, Rejected, Deferred or Postponed.

Question- What are stage in a Bug Life Cycle


5/64

Answer1.New-when tester finds the defect 1sttime it will be innew status.

2.Open-when the TL finds it to begenuine defect/bug then hemakes it as open status.

3.Assign-the TL assign the bug to thedeveloper to fix it ifhe finds it to be genuine he ll fix it.

4.Test-after fixing the bug it is sent to

tester to doregression & retesting of thatfixed/changed module.

5.verified-after testing it is been verifiedto no if anybug still there.

6.Reject-if the developer think bug is not

genuine and noteffecting the application then he willreject it.

7.Differed-if the bug is found and fixedin next release ifseverity and priority is low /because ofless time then itturn out to be differed status.

8.duplicate-if same bug's r found then itis made as duplicate.

9.Closed-when the bug is fixed andtested if no further bugis foung then it given as closed status


6/64

Answer-

1-NEW- Whenever the defect is newly identified for the first

time then the testengineer will set the status as new.

2-OPEN-Whenever the developer accepts the defect then he willset the status as open.

3-FIXED- whenever the developer rectifies the defect beforereleasing the next build he will set the status fixed.

4-CLOSED-Whenever the next build is released the testers willcheck whether the defects are properly rectified or not.if at all they feel defect

is properly rectified thenthey set status as close.

5-REOPEN- once the next build is released the testers willcheck whether the defect is properly rectified ornot.if at all they feel derct is not rectifiedproperly then they will set status as reopen.

6-HOLD- Whenever the developer is confused to accept or reject

the defect then he will set the status as hold.

7-REJECT- whenever the developer feels it is not at all adefect then he will set status as reject.

8-ASPERDESIGN- Whenever the developer feels the tester hasraised the defect without knowing the latestrequirements then he will set the status asasperdesing.

9-DEFFERED- Whenever the defect is accepted by the developerand he requires some extra time to rectify thatdefect then he will set the status as deffered.


7/64

STLC consists of six (generic) phases:

Test Planning, Test Analysis, Test Design,

Construction and verification, Testing Cycles, Final Testing and Implementation and Post Implementation.

Test PlanningThis is the phase where Project Manager has to decide whatthings need to be tested, do I have the appropriate budgetetc. Naturally proper planning at this stage would greatlyreduce the risk of low quality software. This planning will

be an ongoing process with no end point.Activities at this stage would include preparation of highlevel test plan-(according to IEEE test plan template TheSoftware Test Plan (STP) is designed to prescribe thescope, approach, resources, and schedule of all testingactivities. The plan must identify the items to be tested,the features to be tested, the types of testing to beperformed, the personnel responsible for testing, theresources and schedule required to complete testing, and

the risks associated with the plan.). Almost all of theactivities done during this stage are included in thissoftware test plan and revolve around a test plan.Test AnalysisOnce test plan is made and decided upon, next step is todelve little more into the project and decide what types oftesting should be carried out at different stages of SDLC,do we need or plan to automate, if yes then when theappropriate time to automate is, what type of specificdocumentation I need for testing.

Proper and regular meetings should be held between testingteams, project managers, development teams, BusinessAnalysts to check the progress of things which will give afair idea of the movement of the project and ensure thecompleteness of the test plan created in the planningphase, which will further help in enhancing the righttesting strategy created earlier. We will start creating


8/64

test case formats and test cases itself. In this stage weneed to develop Functional validation matrix based onBusiness Requirements to ensure that all systemrequirements are covered by one or more test cases,identify which test cases to automate, begin review ofdocumentation, i.e. Functional Design, BusinessRequirements, Product Specifications, Product Externalsetc. We also have to define areas for Stress andPerformance testing.Test Design

Test plans and cases which were developed in the analysisphase are revised. Functional validation matrix is alsorevised and finalized. In this stage risk assessmentcriteria is developed. If you have thought of automation

then you have to select which test cases to automate andbegin writing scripts for them. Test data is prepared.Standards for unit testing and pass / fail criteria aredefined here. Schedule for testing is revised (ifnecessary) & finalized and test environment is prepared.Construction and verificationIn this phase we have to complete all the test plans, testcases, complete the scripting of the automated test cases,Stress and Performance testing plans needs to be completed.

We have to support the development team in their unittesting phase. And obviously bug reporting would be done aswhen the bugs are found. Integration tests are performedand errors (if any) are reported.Testing CyclesIn this phase we have to complete testing cycles until testcases are executed without errors or a predefined conditionis reached. Run test cases --> Report Bugs --> revise testcases (if needed) --> add new test cases (if needed) -->bug fixing --> retesting (test cycle 2, test cycle 3.).

Final Testing and ImplementationIn this we have to execute remaining stress and performancetest cases, documentation for testing is completed /updated, provide and complete different matrices fortesting. Acceptance, load and recovery testing will also beconducted and the application needs to be verified underproduction conditions.


9/64

Currently role is performing Specialty based testing (i.e.)FUNCTIONALITY TESTING.Post ImplementationIn this phase, the testing process is evaluated and lessonslearnt from that testing process are documented. Line ofattack to prevent similar problems in future projects isidentified. Create plans to improve the processes. Therecording of new errors and enhancements is an ongoingprocess. Cleaning up of test environment is done and testmachines are restored to base lines in this stage.

Bug Life Cycle & Guidelines

In this tutorial you will learn about Bug Life Cycle & Guidelines, Introduction,Bug Life Cycle, The different states of a bug, Description of Various Stages,Guidelines on deciding the Severity of Bug, A sample guideline for assignment ofPriority Levels during the product test phase and Guidelines on writing BugDescription.

Introduction:

Bug can be defined as the abnormal behavior of the software . No software existswithout a bug. The elimination of bugs from the software depends upon theefficiency of testing done on the software. A bug is a specific concern about the

quality of the Application under Test (AUT).

Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should gothrough the life cycle to be closed. A specific life cycle ensures that the process isstandardized. The bug attains different states in the life cycle. The life cycle of thebug can be shown diagrammatically as follows:

The different states of a bug can be summarized as follows:

1. New2. Open3. Assign4. Test5. Verified6. Deferred

Theimagecan


10/64

7. Reopened8. Duplicate9. Rejected and10. Closed

Description of Various Stages:

1. New: When the bug is posted for the first time, its state will be NEW. Thismeans that the bug is not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester approves that thebug is genuine and he changes the state as OPEN.

3. Assign: Once the lead changes the state as OPEN, he assigns the bug tocorresponding developer or developer team. The state of the bug now is changed toASSIGN.

4. Test: Once the developer fixes the bug, he has to assign the bug to the testingteam for next round of testing. Before he releases the software with bug fixed, hechanges the state of bug to TEST. It specifies that the bug has been fixed and isreleased to testing team.

5. Deferred: The bug, changed to deferred state means the bug is expected to befixed in next releases. The reasons for changing the bug to this state have manyfactors. Some of them are priority of the bug may be low, lack of time for therelease or the bug may not have major effect on the software.

6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug.Then the state of the bug is changed to REJECTED.

7. Duplicate: If the bug is repeated twice or the two bugs mention the sameconcept of the bug, then one bug status is changed to DUPLICATE.

8. Verified: Once the bug is fixed and the status is changed to TEST, the testertests the bug. If the bug is not present in the software, he approves that the bug isfixed and changes the status to VERIFIED.

9. Reopened: If the bug still exists even after the bug is fixed by the developer, thetester changes the status to REOPENED. The bug traverses the life cycle once

again.

10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels thatthe bug no longer exists in the software, he changes the status of the bug toCLOSED. This state means that the bug is fixed, tested and approved.

While defect prevention is much more effective and efficient in reducing thenumber of defects, most organization conducts defect discovery and removal.


11/64

Discovering and removing defects is an expensive and inefficient process. It ismuch more efficient for an organization to conduct activities that prevent defects.

Guidelines on deciding the Severity of Bug:

Indicate the impact each defect has on testing efforts or users and administratorsof the application under test. This information is used by developers andmanagement as the basis for assigning priority of work on defects.

A sample guideline for assignment of Priority Levels during the product test phaseincludes:

1. Critical / Show Stopper An item that prevents further testing of theproduct or function under test can be classified as Critical Bug. Noworkaround is possible for such bugs. Examples of this include a missingmenu option or security permission required to access a function under test.

.2. Major / High A defect that does not function as expected/designed or

cause other functionality to fail to meet requirements can be classified asMajor Bug. The workaround can be provided for such bugs. Examples ofthis include inaccurate calculations; the wrong field being updated, etc..

3. Average / Medium The defects which do not conform to standards andconventions can be classified as Medium Bugs. Easy workarounds exists toachieve functionality objectives. Examples include matching visual and textlinks which lead to different end points..

4. Minor / Low Cosmetic defects which does not affect the functionality ofthe system can be classified as Minor Bug.

Guidelines on writing Bug Description:

Bug can be expressed as Result followed by the action. That means, theunexpected behavior occurring when a particular action takes place can be given asbug description.

1. Be specific. State the expected behavior which did not occur - such as afterpop-up did not appear and the behavior which occurred instead.

2. Use present tense.3. Dont use unnecessary words.4. Dont add exclamation points. End sentences with a period.5. DONT USE ALL CAPS. Format words in upper and lower case (mixed

case).


12/64

6. Mention steps to repr

Integrati

Introduction:As we covered in various artesting:

Unit Testing, Integration Te

Each level of testing builds

Unit testing focuses on teIntegration testing is thetesting the integration of u

How does Integration Test

Even if a software componedistributed application it issuccessfully integrated with

Once unit tested componentThese integrated componto the integration. This is aCycle.

It is possible that different p

A lot of bugs emerge durin

In most cases a dedicated te

Prerequisites for Integrati

Before we begin Integrationbeen successfully unit teste

Integration Testing Steps:

Integration Testing typicallStep 1: Create a Test PlanStep 2: Create Test Cases aStep 3: If applicable createStep 4: Once the componenStep 5: Fix the bugs if any

duce the bug compulsorily.

on Testing: Why? What? & How?

ticles in the Testing series there are vario

sting, System Testing

on the previous level.

ting a unit of the code.ext level of testing. This level of testingits of code or components.

ing fit into the Software Developmen

nt is successfully unit tested, in an enterf little or no value if the component canthe rest of the application.

s are delivered we then integrate them tonts are tested to weed out errors and bugery important step in the Software Deve

rogrammers developed different compon

the integration step.

sting team focuses on Integration Testin

on Testing:

Testing it is important that all the comp.

involves the following Steps:

d Test Datascripts to run test casests have been integrated execute the test cnd re test the code

us levels of

focuses on

Life Cycle?

rise n-tierot be

ether.s caused dueopment Life

ents.

.

nents have

ases


13/64

Step 6: Repeat the test cycle until the components have been successfullyintegrated

What is an Integration Test Plan?

As you may have read in the other articles in the series, this document typicallydescribes one or more of the following:- How the tests will be carried out- The list of things to be Tested- Roles and Responsibilities- Prerequisites to begin Testing- Test Environment- Assumptions- What to do after a test is successfully carried out- What to do if test fails

- Glossary

How to write an Integration Test Case?

Simply put, a Test Case describes exactly how the test should be carried out.The Integration test cases specifically focus on the flow of data/information/controlfrom one component to the other.

So the Integration Test cases should typically focus on scenarios where onecomponent is being called from another. Also the overall application functionalityshould be tested to make sure the app works when the different components are

brought together.

The various Integration Test Cases clubbed together form an Integration Test SuiteEach suite may have a particular focus. In other words different Test Suites may becreated to focus on different areas of the application.

As mentioned before a dedicated Testing Team may be created to execute theIntegration test cases. Therefore the Integration Test Cases should be as detailed aspossible.

Sample Test Case Table:

TestCase

ID

Test CaseDescription

InputData

ExpectedResult

ActualResult

Pass/Fail Remarks


14/64


15/64

System Testing: Why? W

Introduction:Unit testing focuses on te

Integration testing focuscomponents.Each level of testing builds

System Testing is the nexwhole.

How does System Testing

In a typical Enterprise, unitthe individual components asuccessful integration of allof code).

Once the components are intested to ensure that it meet

Thus the System testing buiand Integration Testing.

Usually a dedicated testing

Why System Testing is im

System Testing is a crucial

........- In the Software Devewhere...........the System is tested........- The System is tested...........requirements

........- The application/Systethe...........production environm........- The System Testing e...........requirements as well

at? & How?

ting each unit of the code.

s on testing the integration of units of c

on the previous level.

t level of testing. It focuses on testing th

it into the Software Development Li

testing is done by the programmers. Thre working OK. The Integration testingthe individual pieces of software (comp

egrated, the system as a whole needs tothe Quality Standards.

ds on the previous levels of testing nam

eam is responsible for doing System Te

ortant?

tep in Quality Management Process.

opment Life cycle System Testing is th

s a wholeo verify if it meets the functional and tec

m is tested in an environment that closel

nt where the application will be finallynables us to test, verify and validate botas the Application Architecture

ode or

system as a

e Cycle?

is ensures thatfocuses on

nents or units

e rigorously

ly unit testing

sting.

e first level

hnical

resembles

eployedthe Business


16/64

Prerequisites for System Testing:

The prerequisites for System Testing are:........- All the components should have been successfully Unit Tested........- All the components should have been successfully integrated and Integration

..........Testing should be completed

........- An Environment closely resembling the production environment should be

...........created.

When necessary, several iterations of System Testing are done in multipleenvironments.

Steps needed to do System Testing:

The following steps are important to perform System Testing:........Step 1: Create a System Test Plan

........Step 2: Create Test Cases

........Step 3: Carefully Build Data used as Input for System Testing

........Step 3: If applicable create scripts to

..................- Build environment and

..................- to automate Execution of test cases

........Step 4: Execute the test cases

........Step 5: Fix the bugs if any and re test the code

........Step 6: Repeat the test cycle as necessary

What is a System Test Plan?

As you may have read in the other articles in the testing series, this documenttypically describes the following:.........- The Testing Goals.........- The key areas to be focused on while testing.........- The Testing Deliverables.........- How the tests will be carried out.........- The list of things to be Tested.........- Roles and Responsibilities.........- Prerequisites to begin Testing

.........- Test Environment

.........- Assumptions

.........- What to do after a test is successfully carried out

.........- What to do if test fails

.........- Glossary


17/64

How to write a System Test Case?

A Test Case describes exactly how the test should be carried out.

The System test cases help us verify and validate the system.The System Test Cases are written such that:

........- They cover all the use cases and scenarios

........- The Test cases validate the technical Requirements and Specifications

........- The Test cases verify if the application/System meet the Business &Functional...........Requirements specified........- The Test cases may also verify if the System meets the performancestandards

Since a dedicated test team may execute the test cases it is necessary that SystemTest Cases. The detailed Test cases help the test executioners do the testing as

specified without any ambiguity.

The format of the System Test Cases may be like all other Test cases as illustratedbelow:

Test Case IDTest Case Description:

What to Test?How to Test?

Input DataExpected ResultActual Result

Sample Test Case Format:

Test

Case

ID

What

To

Test?

How to

Test?

Input

Data

Expected

Result

Actual

Result

Pass/Fail

. . . . . . .

Additionally the following information may also be captured:........a) Test Suite Name

........b) Tested By

........c) Date

........d) Test Iteration (The Test Cases may be executed one or more times)

Working towards Effective Systems Testing:

There are various factors that affect success of System Testing:


18/64

1) Test Coverage: System Testing will be effective only to the extent of thecoverage of Test Cases. What is Test coverage? Adequate Test coverage impliesthe scenarios covered by the test cases are sufficient. The Test cases shouldcover all scenarios, use cases, Business Requirements, Technical Requirements,and Performance Requirements. The test cases should enable us to verify andvalidate that the system/application meets the project goals and specifications.

2) Defect Tracking: The defects found during the process of testing should betracked. Subsequent iterations of test cases verify if the defects have been fixed.

3) Test Execution: The Test cases should be executed in the manner specified.Failure to do so results in improper Test Results.

4) Build Process Automation: A Lot of errors occur due to an improper build.Build is a compilation of the various components that make the applicationdeployed in the appropriate environment. The Test results will not be accurate if

the application is not built correctly or if the environment is not set up asspecified. Automating this process may help reduce manual errors.

5) Test Automation: Automating the Test process could help us in many ways:

a. The test can be repeated with fewer errors of omission or oversight

b. Some scenarios can be simulated if the tests are automated for instancesimulating a large number of users or simulating increasing large amountsof input/output data

6) Documentation: Proper Documentation helps keep track of Tests executed. It

also helps create a knowledge base for current and future projects. Appropriatemetrics/Statistics can be captured to validate or verify the efficiency of thetechnical design /architecture.

What is Regression Testing?

Introduction:

This article attempts to take a close look at the process and techniques inRegression Testing.

What is Regression Testing?If a piece ofSoftware- is modified for any reason testing needs to be done toensure that it works as specified and that it has not negatively impacted anyfunctionality that it offered previously. This is known as Regression Testing.

Regression Testing attempts to verify: - That the application works as specifiedeven after the changes/additions/modification were made to it


19/64

- The original functionality continues to work as specified even afterchanges/additions/modification to the software application

- The changes/additions/modification to the software application have notintroduced any new bugs

When is Regression Testing necessary?

Regression Testing plays an important role in any Scenario where a change hasbeen made to a previously tested software code. Regression Testing is hence animportant aspect in various Software Methodologies where software changesenhancements occur frequently.

Any Software Development Project is invariably faced with requests for changingDesign, code, features or all of them.

Some Development Methodologies embrace change.

For example Extreme Programming Methodology advocates applying smallincremental changes to the system based on the end user feedback.

Each change implies more Regression Testing needs to be done to ensure that theSystem meets the Project Goals.

Why is Regression Testing important?

Any Software change can cause existing functionality to break.Changes to a Software component could impact dependent Components.

It is commonly observed that a Software fix could cause other bugs.All this affects the quality and reliability of the system. Hence Regression Testing,since it aims to verify all this, is very important.

Making Regression Testing Cost Effective:

Every time a change occurs one or more of the following scenarios may occur:- More Functionality may be added to the system- More complexity may be added to the system- New bugs may be introduced

- New vulnerabilities may be introduced in the system- System may tend to become more and more fragile with each change

After the change the new functionality may have to be tested along with all theoriginal functionality.

With each change Regression Testing could become more and more costly.


20/64

To make the Regression Testing Cost Effective and yet ensure good coverage oneor more of the following techniques may be applied:

- Test Automation: If the Test cases are automated the test cases may be executedusing scripts after each change is introduced in the system. The execution of test

cases in this way helps eliminate oversight, human errors,. It may also result infaster and cheaper execution of Test cases. However there is cost involved inbuilding the scripts.

- Selective Testing: Some Teams choose execute the test cases selectively. Theydo not execute all the Test Cases during the Regression Testing. They test onlywhat they decide is relevant. This helps reduce the Testing Time and Effort.

Regression Testing What to Test?

Since Regression Testing tends to verify the software application after a change

has been made everything that may be impacted by the change should be testedduring Regression Testing. Generally the following areas are covered duringRegression Testing:

- Any functionality that was addressed by the change

- Original Functionality of the system

- Performance of the System after the change was introduced

Regression Testing How to Test?Like any other Testing Regression Testing Needs proper planning.For an Effective Regression Testing to be done the following ingredients arenecessary:

Create a Regression Test Plan: Test Plan identified Focus Areas, Strategy, TestEntry and Exit Criteria. It can also outline Testing Prerequisites, Responsibilities,etc.

Create Test Cases: Test Cases that cover all the necessary areas are important.They describe what to Test, Steps needed to test, Inputs and Expected Outputs.

Test Cases used for Regression Testing should specifically cover the functionalityaddressed by the change and all components affected by the change. TheRegression Test case may also include the testing of the performance of thecomponents and the application after the change(s) were done.

Defect Tracking: As in all other Testing Levels and Types It is important Defectsare tracked systematically, otherwise it undermines the Testing Effort.


21/64

What is User Acceptance

Introduction:

This article attempts to explOnce the application is reaTesting.

In this step a group represeThe user acceptance testingrelevant to the end users.

What is User Acceptance

User Acceptance Testing is

Usually the end users whoaccepting the application.

This type of testing gives thdelivered to them meets the

This testing also helps nail

User Acceptance Testing

Before the User Acceptance

Various levels of testing (Ubefore User Acceptance Tecompleted most of the tech

User Acceptance Testing

To ensure an effective UserThese Test cases can be creRequirements definition staThe Test cases ensure prope

During this type of testing tapplication. The Testing isenvironment.The Test cases are written u

esting?

in the process of User Acceptance Testidy to be released the crucial step is User

ting a cross section of end users tests theis done using real world scenarios and p

esting?

often the final step before rolling out the

ill be using the applications test the appl

end users the confidence that the applicr requirements.

ugs related to usability of the applicatio

Prerequisites:

testing can be done the application is ful

it, Integration and System) are already cting is done. As various levels of testingical bugs have already been fixed before

What to Test?

Acceptance Testing Test cases are creatted using various use cases identified due.

r coverage of all the scenarios during tes

e specific focus is the exact real world uone in an environment that simulates the

sing real world scenarios for the applicat

g.Acceptance

application.rceptions

application.

ication before

ation being

.

ly developed.

ompletedhave beenUAT.

d.ring the

ing.

sage of theproduction

on


22/64

User Acceptance Testing How to Test?

The user acceptance testing is usually a black box type of testing. In other words,the focus is on the functionality and the usability of the application rather than thetechnical aspects. It is generally assumed that the application would have already

undergone Unit, Integration and System Level Testing.However, it is useful if the User acceptance Testing is carried out in anenvironment that closely resembles the real world or production environment.

The steps taken for User Acceptance Testing typically involve one or more of thefollowing:.......1) User Acceptance Test (UAT) Planning.......2) Designing UA Test Cases.......3) Selecting a Team that would execute the (UAT) Test Cases.......4) Executing Test Cases

.......5) Documenting the Defects found during UAT

.......6) Resolving the issues/Bug Fixing

.......7) Sign Off

User Acceptance Test (UAT) Planning:As always the Planning Process is the most important of all the steps. This affectsthe effectiveness of the Testing Process. The Planning process outlines the UserAcceptance Testing Strategy. It also describes the key focus areas, entry and exitcriteria.

Designing UA Test Cases:The User Acceptance Test Cases help the Test Execution Team to test theapplication thoroughly. This also helps ensure that the UA Testing providessufficient coverage of all the scenarios.The Use Cases created during the Requirements definition phase may be used asinputs for creating Test Cases. The inputs from Business Analysts and SubjectMatter Experts are also used for creating.

Each User Acceptance Test Case describes in a simple language the precise stepsto be taken to test something.

The Business Analysts and the Project Team review the User Acceptance TestCases.

Selecting a Team that would execute the (UAT) Test Cases:Selecting a Team that would execute the UAT Test Cases is an important step.The UAT Team is generally a good representation of the real world end users.The Team thus comprises of the actual end users who will be using the application.


23/64

Executing Test Cases:The Testing Team executesTests relevant to them

Documenting the Defects

The Team logs their commeResolving the issues/BugThe issues/defects found duSubject Matter Experts andmutual consensus and to the

Sign Off:

Upon successful completioissues the team generally in

important in commercial soSoftware delivered they ind

The users now confident ofpaid for the same.

Ads

What are the key delivera

In the Traditional Software

Acceptance Testing is a sigThe Key Deliverables typic

1) The Test Plan- This outli

2) The UAT Test cases Tapplication

3) The Test Log This is a

4) User Sign Off This inditheir satisfaction

Summary:

In this article we studied the

the Test Cases and may additional perfo

ound during UAT:

nts and any defects or issues found durinixing:ing Testing are discussed with the Proje

Business Analysts. The issues are resolvsatisfaction of the end users.

of the User Acceptance Testing and resicates the acceptance of the application.

tware sales. Once the User Acate that the software meets their require

the software solution delivered and the v

les of User Acceptance Testing?

evelopment Lifecycle successful compl

ificant milestone.lly of User Acceptance Testing Phase ar

es the Testing Strategy

e Test cases help the team to effectively

og of all the test cases executed and the

cates that the customer finds the product

process of User Acceptance Testing.

m random

g testing.

t Team,d as per the

lution of theThis step is

ccept thements.

ndor can be

etion of User

e:

test the

ctual results.

delivered to


24/64

Unit

Author : Exforsys Inc. Pu2010

Unit Testing: Why? What

In this tutorial you will leartypes of testing based upon

Software Develois a Unit Test Plan? What isUnit Testing.

There are various levels of t

Unit Testing Integration TestingSystem Testing

There are various types of t

Acceptance TestingPerformance TestingLoad TestingRegression Testing

Based on the testing Techni

Black box TestingWhite box Testing

How does Unit Testing fit

This is the first and the mosdevelops a unit of code the

built it is much more econoUnit Testing is the most im

progresses ahead it become

In most cases it is the devel

Unit Testing Tasks and StStep 1: Create a Test PlanStep 2: Create Test Cases aStep 3: If applicable createStep 4: Once the code is rea

Testing: Why? What? & How?

blished on: 8th Jan 2006 | Last Updat

& How?

about unit testing, various levels of testhe intent of testing, How does Unit Test

ment Life Cycle? Unit Testing Tasks ana Test Case? and Test Case Sample, Ste

esting:

sting based upon the intent of testing su

ues testing can be classified as:

nto the Software Development Life

important level of testing. As soon as thnit is tested for various scenarios. As thical to find and eliminate the bugs early

ortant of all the testing levels. As the somore and more costly to find and fix th

pers responsibility to deliver Unit Test

ps:

d Test Datacripts to run test casesy execute the test cases

d on: 8th Dec

ng, variousng fit into the

Steps, Whats to Effective

h as:

ycle?

e programmerapplication ison. Hencetware projectbugs.

d Code.


25/64

Step 5: Fix the bugs if any and re test the codeStep 6: Repeat the test cycle until the unit is free of all bugs

What is a Unit Test Plan?

This document describes the Test Plan in other words how the tests will be carriedout.This will typically include the list of things to be Tested, Roles andResponsibilities, prerequisites to begin Testing, Test Environment, Assumptions,what to do after a test is successfully carried out, what to do if test fails, Glossaryand so on

What is a Test Case?

Simply put, a Test Case describes exactly how the test should be carried out.For example the test case may describe a test as follows:

Step 1: Type 10 characters in the Name FieldStep 2: Click on Submit

Test Cases clubbed together form a Test Suite

Test Case Sample

Test

Case

ID

Test Case

Description

Input

Data

Expected

Result

Actual

Result

Pass/Fail Remarks

Additionally the following information may also be captured:a) Unit Name and Version Being testedb) Tested Byc) Dated) Test Iteration (One or more iterations of unit testing may be performed)

Steps to Effective Unit Testing:

1) Documentation: Early on document all the Test Cases needed to test your code.

A lot of times this task is not given due importance. Document the Test Cases,actual Results when executing the Test Cases, Response Time of the code for eachtest case. There are several important advantages if the test cases and the actualexecution of test cases are well documented.

a. Documenting Test Cases prevents oversight.b. Documentation clearly indicates the quality of test cases


26/64

c. If the code needs to be retested we can be sure that we did not miss anythingd. It provides a level of transparency of what was really tested during unit testing.This is one of the most important aspects.e. It helps in knowledge transfer in case of employee attritionf. Sometimes Unit Test Cases can be used to develop test cases for other levels oftesting

2) What should be tested when Unit Testing: A lot depends on the type ofprogram or unit that is being created. It could be a screen or a component or a webservice. Broadly the following aspects should be considered:

a. For a UI screen include test cases to verify all the screen elements that need toappear on the screensb. For a UI screen include Test cases to verify the spelling/font/size of all thelabels or text that appears on the screen

c. Create Test Cases such that every line of code in the unit is tested at least once ina test cycled. Create Test Cases such that every condition in case of conditional statementsis tested oncee. Create Test Cases to test the minimum/maximum range of data that can beentered. For example what is the maximum amount that can be entered or themax length of string that can be entered or passed in as a parameterf. Create Test Cases to verify how various errors are handledg. Create Test Cases to verify if all the validations are being performed

3) Automate where Necessary: Time pressures/Pressure to get the job done mayresult in developers cutting corners in unit testing. Sometimes it helps to writescripts, which automate a part of unit testing. This may help ensure that thenecessary tests were done and may result in saving time required to perform thetests.

Ads

Summary:

Unit Testing is the first level of testing and the most important one. Detectingand fixing bugs early on in the Software Lifecycle helps reduce costly fixes lateron. An Effective Unit Testing Process can and should be developed to increase theSoftware Reliability and credibility of the developer. The Above article explainshow Unit Testing should be done and the important points that should beconsidered when doing Unit Testing.


27/64

Many new developers take tof Unit Testing further dowarticle serves as a starting p

Author : Exforsys Inc. P

This article explains aboutIntegration Test, FunctionalTest.

Introduction:

The development process iaddresses a specific testinginvolved in the developmen

Unit Test. System Test Integration Test Functional Test Performance Test Beta Test Acceptance Test.

Unit TestThe first test in the developnormally divided into moduunits. These units have speccalled unit test. Unit test dedeveloped. Unit tests ensureaccurately to the documenteexpected results.

System Test

Several modules constitutedevelopers write the modulmay arise. The testing done

System testing ensures thatrequirements. It tests a conf

he unit testing tasks lightly and realize tthe road if they are still part of the proj

int for laying out an effective (Unit) Tes

blished on: 17th May 2005 | Last Up

Mar 2011ifferent testing types Unit Test. SystemTest, Performance Test, Beta Test and

nvolves various types of testing. Each teequirement. The most common types ofprocess are:

ent process is the unit test. The source cles, which in turn are divided into smalleific behavior. The test done on these unitends upon the language on which the prthat each unique path of the project perf

d specifications and contains clearly defi

project. If the project is long-term projes. Once all the modules are integrated, sat this stage is called system test.

he entire integratedsoftware system mguration to ensure known and predictabl

e importancect. Thisting Strategy.

ated on: 15th

est,cceptance

t typetesting

ode isr units calleds of code isject isormsned inputs and

ct, severalveral errors

etsresults.


28/64

System testing is based on process descriptions and flows, emphasizing pre-drivenprocess links and integration points.

Testing a specific hardware/software installation. This is typically performed on aCOTS (commercial off the shelf) system or any other system comprised of

disparent parts where custom configurations and/or unique installations are thenorm.

Functional Test

Functional test can be defined as testing two or more modules together with theintent of finding defects, demonstrating that defects are not present, verifying thatthe module performs its intended functions as stated in the specification andestablishing confidence that a program does what it is supposed to do.

Acceptance Testing

Testing the system with the intent of confirming readiness of the product andcustomer acceptance.

Ad Hoc Testing

Testing without a formal test plan or outside of a test plan. With some projects thistype of testing is carried out as an adjunct to formal testing. If carried out by askilled tester, it can often find problems that are not caught in regular testing.Sometimes, if testing occurs very late in the development cycle, this will be theonly kind of testing that can be performed. Sometimes ad hoc testing is referred to

as exploratory testing.

Alpha Testing

Testing after code is mostly complete or contains most of the functionality andprior to users being involved. Sometimes a select group of users are involved.More often this testing will be performed in-house or by an outside testing firm inclose cooperation with the software engineering department.

Ads

Automated Testing

Software testing that utilizes a variety of tools to automate the testing process andwhen the importance of having a person manually testing is diminished.Automated testing still requires a skilled quality assurance professional withknowledge of the automation tool and the software being tested to set up the tests.


29/64

Beta Testing

Testing after the product is code complete. Betas are often widely distributed oreven distributed to the public at large in hopes that they will buy the final productwhen it is released.

Black Box Testing

Testing software without any knowledge of the inner workings, structure orlanguage of the module being tested. Black box tests, as most other kinds of tests,must be written from a definitive source document, such as a specification orrequirements document.

Compatibility Testing

Testing used to determine whether other system software components such asbrowsers, utilities, and competing software will conflict with the software beingtested.

Configuration Testing

Testing to determine how well the product works with a broad range ofhardware/peripheral equipment configurations as well as on different operatingsystems and software.

Independent Verification & Validation

The process of exercising software with the intent of ensuring that the softwaresystem meets its requirements and user expectations and doesn't fail in anunacceptable manner. The individual or group doing this work is not part of thegroup or organization that developed the software. A term often applied togovernment work or where the government regulates the products, as in medicaldevices.

Installation Testing

Testing with the intent of determining if the product will install on a variety ofplatforms and how easily it installs.

Integration Testing

Testing two or more modules or functions together with the intent of findinginterface defects between the modules or functions. Testing completed at as a partof unit or functional testing, and sometimes, becomes its own standalone test


30/64

phase. On a larger level, integration testing can involve a putting together ofgroups of modules and functions with the goal of completing and verifying that thesystem meets the system requirements. (see system testing)

Load Testing

Testing with the intent of determining how well the product handles competitionfor system resources. The competition may come in the form of network traffic,CPU utilization or memory allocation.

Performance Testing

Testing with the intent of determining how quickly a product handles a variety ofevents. Automated test tools geared specifically to test and fine-tune performanceare used most often for this type of testing.

Pilot Testing

Testing that involves the users just before actual release to ensure that usersbecome familiar with the release contents and ultimately accept it. Often isconsidered a Move-to-Production activity for ERP releases or a beta test forcommercial products. Typically involves many users, is conducted over a shortperiod of time and is tightly controlled. (see beta testing).

Regression Testing

Ads

Testing with the intent of determining if bug fixes have been successful and havenot created any new problems. Also, this type of testing is done to ensure that nodegradation of baseline functionality has occurred.

Security Testing

Testing of database and network software in order to keep company data andresources secure from mistaken/accidental users, hackers, and other malevolentattackers.

Software TestingThe process of exercising software with the intent of ensuring that the softwaresystem meets its requirements and user expectations and doesn't fail in anunacceptable manner. The organization and management of individuals or groupsdoing this work is not relevant. This term is often applied to commercial productssuch as internet applications. (contrast with independent verification andvalidation)


31/64

Stress Testing

Testing with the intent of determining how well a product performs when a load isplaced on the system resources that nears and then exceeds capacity.

User Acceptance TestingSee Acceptance Testing.

White Box Testing

Testing in which the software tester has knowledge of the inner workings, structureand language of the software, or at least its purpose.

RACH Home : www.sharetechnote.com

What is the most tricky part in device troubleshooting ? My experience says "If aproblem happens in the middle of doing something, it is relatively easy to find theroot cause and troubleshoot it (probably I might have over-simplified the situation-:), but if something happened before anything started, it would be a nightmare."For example, you set the all the parameters at the network emulator for a UE youwant to test and then turned on the UE. In a several second UE start booting andthen in a couple of second you see a couple of antenna bars somewhere at the topof UE screen.. and then in several seconds you see 'SOS' or 'Service Not Available'in stead of your network operator name displayed on your screen and normalAntenna bars. This is what I mean by "problem in the middle of doing something".In this case, if you collect UE log and equipment log, at least you can easily pinpoint out the location the problem happens and start from there for further details.But what if you are in this situation ? you set the all the parameters at the networkemulator side and turn on the UE.. UE start booting up .. showing the messagesaying "Searching Network ...." and got stuck there.. with no Antenna bars .. noteven 'SOS' .. just saying "No service". And I collected UE side log and NetworkEmulator side log, but no signalling message. This is where our headache starts.

As examples,

i) What if you don't see 'RRC Connection Request' when your turned on theWCDMA UE ?


32/64

ii) What if you don't see 'Channel Request' when your turned on the GSM UE ?

iii) What if you don't see 'RACH Preamble' when your turned on the LTE UE ?

First thing you have to do is to understand the every details of this procedure notonly in the higher signaling layer, but also all the way down to the physical layersrelated to these first step. And also you have to use proper equipment which canshow these detailed process. If you have an equipment that does not provide thelogging or it provides log but only higher layer singnaling log, it will be extremlydifficult to troubleshoot. Given that you have the proper tools, the next thing youhave to be ready is to understand the detailed knowledge of these process. Withoutthe knowledge, however good tools I have it doesn't mean anything to me. So ? Iwant to teach myself here about the first step of LTE signaling which is RACHprocess. (Somebody would say there are many of other steps even before the

RACH, like frequency Sync, Time Sync, MIB/SIB decoding.. but it put these asidefor now.. since it is more like baseband processing).

When RACH Process occurs ?

It would be helpful to understand if you think about when 'RRC Connection'happens (or when PRACH process happens if you are interested in lower layerstuffs) in WCDMA. It would also be helpful if you think about when 'ChannelRequest' happens in GSM UE.

My impression of LTE RACH process is like the combination of PRACH process(WCDMA) and Channel Request (GSM). It may not be 100% correct analogy.. butanyway I got this kind of impression. In LTE, RACH process happens in followingsituation (3GPP specification, 10.1.5 Random Access Procedure of 36.300 )

i) Initial access from RRC_IDLE

ii) RRC Connection Re-establishment procedure

iii) Handover

iv) DL data arrival during RRC_CONNECTED requiring random accessprocedure

E.g. when UL synchronisation status is non-synchronised


33/64

v) UL data arrival during RRC_CONNECTED requiring random accessprocedure

E.g. when UL synchronisation status is "non-synchronised" or there are noPUCCH resources for SR available.

vi) For positioning purpose during RRC_CONNECTED requiring randomaccess procedure;

E.g. when timing advance is needed for UE positioning

Two types of RACH process : Contention-based and Contention-free

When a UE transmit a PRACH Preamble, it transmits with a specific pattern and

this specific pattern is called a "Signature". In each LTE cell, total 64 preamblesignatures are available and UE select randomly one of these signatures.

UE select "Randomly" one of these signatures ?

Does this mean that there is some possibility that multiple UEs send PRACH withidentical signatures ?

Yes.

There is such a possibility. It means the same PRACH preamble from multipe UEreaches the NW at the same time.. this kind of PRACH collision is called"Contention" and the RACH process that allows this type of "Contention" is called"Contention based" RACH Process. In this kind of contention based RACHprocess, Network would go through additional process at later step to resolve thesecontention and this process is called "Contention Resolution" step.

But there is some cases that these kind of contention is not acceptable due to somereason (e.g, timing restriction) and these contention can be prevented. Usually inthis case, the Network informs each of the UE of exactly when and whichpreamble signature it has to use. Of course, in this case Network will allocate thesepreamble signature so that it would not collide. This kind of RACH process is


34/64

called "Contention Free" RACH procedure. To initiate the "Contention Free"RACH process, UE should be in Connected Mode before the RACH process as inHandover case.

Typical 'Contention Based' RACH Procedure is as follows :

i) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)

ii) UE NW : L2/L3 message iv) Message for early contention resolution

Now let's assume that a contention happened at step i). For example, two UEs sentPRACH. In this case, both of the UE will recieve the same T_C-RNTI andresource allocation at step ii). And as a result, both UE would send L2/L3 messagethrough the same resource allocation(meaning with the same time/frequencylocation) to NW at step iii). What would happen when both UE transmit the exactsame information on the exact same time/frequency location ? One possibility isthat these two signal act as interference to each other and NW decode neither ofthem. In this case, none of the UE would have any response (HARQ ACK) fromNW and they all think that RACH process has failed and go back to step i). Theother possibility would be that NW could successfully decode the message fromonly one UE and failed to decode it from the other UE. In this case, the UE withthe successful L2/L3 decoding on NW side will get the HARQ ACK fromNetwork. This HARQ ACK process for step iii) message is called "contentionresolution" process.

Typical 'Contention Free' RACH Procedure is as follows :

i) UE NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)

iii) UE


35/64

Exactly when and Where a UE transmit RACH ?

To answer to this question, you need to refer to 3GPP specification TS36.211 -Table 5.7.1-2.

Did you open the specification now ? It shows exactly when a UE is supposed tosend RACH depending on a parameter called "PRACH Configuration Index".

Theimagecannot bedisplayed. Your computer may nothaveenough memory to open theimage, or theimagemay havebeen corrupted. Restartyour computer, and then open thefileagain. Ifthered xstillappears, you may haveto deletetheimage and then insertitagain.


36/64

For example, if the UE is using "PRACH Configuration Idex 0", it should transmitthe RACH only in EVEN number SFN(System Frame Number). Is this goodenough answer ? Does this mean that this UE can transmit the RACH in any time

within the specified the SFN ? The answer to this question is in "Sub FrameNumber" colulmn of the table. It says "1" for "PRACH Configuration Idex 0". Itmeans the UE is allowed to transmit RACH only at sub frame number 1 of everyeven SFN.

Checking your understanding of the table, I will give you one question. Withwhich "PRACH Configuration Idex", it would be the easiest for the Network todetect the RACH from UE ? and Why ?

The answer would be 14, because UE can send the RACH in any SFN and anyslots within the frame.

In a big picture, you should know all the dimmensions in the following diagram.(The Red rectangle is PRACH signal).

The R_Slot is determined by PRACH Configuration Index and R_length isdetermined by Premable format. F_offset is dermined by the following equation

Theimagecannot bedisplayed. Your computer may nothaveenough memory to open theimage, or theimagemay havebeen corrupted. Restartyour computer, and then open thefileagain. Ifthered xstill appears, you may haveto deletetheimage and then insertitagain.


37/64

when the preamble format is 0~3. n_RA_PRBoffset in this equation is specified byprach-FreqOffset in SIB2.

What is preamble format ?

If you see the table 5.7.1-1 show above, you see the column titled as "PreambleFormat". What is the preamble format ? It is defined as following diagram.

You would see that the length of PRACH preamble varies depending on thepreamble format. For example, the length of PRACH with preamble format is(3186 + 24567) Samples. (As you know, one sample (Ts) is 1/30.072 us).



38/64

You may ask "Why we need this kind of multiple preamble format ?", especially"Why we need various PRACH format with different length in time ?".

One of the main reason would be that they use different preamble formatdepending on cell radius, but this is oversimplified answer.

I want to recommend a book titled "LTE : The UMTS From Theory to Practice"Section 19.4.2 The PRACH Structure. This is the material that describes thePRACH in the most detailed level I have ever read.

How does Network knows exactly when UE will transmit the RACH ?

It is simple. Network knows when UE will send the RACH even before UE sendsit because Network tells UE when the UE is supposed to transmit the RACH. (IfUE fails to decode properly the network information about the RACH, Networkwill fail to detect it even though UE sends RACH).

Following section will describe network informaton on RACH.



39/64

Which RRC Message contains RACH Configuration ?

It is in SIB2 and you can find the details in 3GPP 36.331.Theimagecannot bedisplayed. Your computer may nothaveenough memory to open theimage, or theimagemay havebeen corrupted. Restartyour computer, and then open thefileagain. Ifthered xstillappears, you may haveto deletetheimage and then insertitagain.



40/64

numberOfRA-Preambles : There are total 64 RA preambles that UE can randomlychoose from. But usually a cell reserve several Preambles for 'Non-contentionbased' PRACH procedure and let UE use the rest of Preambles randomly(contention based). numberOfRA-Preambles indicates how many RA preambles(RA sequences) is available for the contention based RACH process.

PRACH Signal Structure

Following figure shows the PRACH Premable signal structure in comparison withnormal Uplink subframe. A couple of points to be specially mentioned are

Preamble Length in Frequency Domain is amount to 6 RBs of UL Subframe,

which is 1.08 MhzOne sub carrier of PRACH Preamble is 1.25 Khz whereas 1 sub carrier of

UL subframe is 15 Khz. It means that 12 preamble sub carrier is amount to 1UL Subframe subcarrier.



41/64

How to generate RACH Signal ?

You don't have to know the details of this procedure unless you are the DSP orFPGA engineer implementing LTE PHY. Just as a common sense about LTE, let's

know that PRACH is a kind ofZaddOff Chu Sequence generated by the followingequation.

, where u = physical root sequence index




42/64

There are 64 preambles available for each cell and UE has to be able to generatethe 64 preambles for the cell it want to camp on.

You can easily generate 64 different preambles just by cyclically shifting anexisting sequence, but there is a condition for this. All the preamle sequences

should be authogonal to each other. Otherwise, various preambles from multipleUEs within the same cell can interfere each other. So we have to shift thegenerated sequence by a specifically designed value and this value is called Cv(Cyclic Shift Value) and it is defined as follows. (I think determining the Cv is oneof the most complicated process in PRACH preamble generation because it getsinvolved with so many different parameters in cascading manner).

First, you would notice that we use different process to calculate Cv depending onwhether we use 'unrestricted sets' or 'restricted sets'. This decision is made by'Highspeedflag' information elements in SIB2. If Highspeedflag is set to be TRUE,we have to use 'restricted sets' and if Highspeedflag is false, we have to use'unrestricted sets'.

N_cs is specified by zeroCorrelationZoneConfig information elements in SIB2. Asyou see in this mapping, N_cs values also gets different depending on whether weuse 'restricted sets' or 'unrestricted sets'.



43/64

Now let's look at how we get Nzc. This is pretty straightforward. Nzc isdetermined by the following table.

If the Preamble is using the unrestricted sets, it is pretty simple. You only have toknow Nzc, Ncs to figure out Cv.

The problem is when the Preamble is using the 'restricted sets'. As you see theequation above, you need to know the following 4 values to figure out Cv in'restricted sets'.

Theimagecannot bedisplayed. Your computer may nothaveenough memory to open theimage, or theimagemay havebeen corrupted. Restartyour computer, and then open thefileagain. Ifthered xstill appears, you may haveto deletetheimageand then insertitagain.


Theimagecannot bedisplayed. Your computer may nothaveenough memory to open theimage, or theimagemay havebeen corrupted. Restartyour computer, and then open thefileagain. Ifthe red xstillappears, you

may haveto deletetheimageand then insertitagain.


44/64

The problem is that the calculation of these four variable is very complicated asshown below.

You would noticed that you need another value to calculate to determine which ofthe three case we have to use. It is du. So we need another process to determine du.

We went through a complicated procedure just to determin one number (Cv). Oncewe get Cv, we can generate multiple preambles using the following function.



Theimagecannot bedisplayed. Your computer may nothaveenough memory to open theimage, or theimagemay havebeen corrupted. Restartyour computer, and then open thefileagain. Ifthe red xstillappears, you may haveto deletetheimage and then insertitagain.


45/64

Anyway, now we got a PRACH Preamble sequence in hand, but this is not all. Inorder to transmit this data. We have to convert this data into a time domainsequence and this conversion is done by the following process.

For the whole PRACH generation procedure, please refer to 5.7.2/5.7.3 of TS36.211.

Exactly when and where Network transmit RACH Response

We all knows that Network should transmit RACH Response after it recieved

RACH Preamble from UE, but do we know exactly when, in exactly whichsubframe, the network should transmit the RACH Response ? The following iswhat 3GPP 36.321 (section 5.1.4) describes.

Once the Random Access Preamble is transmitted and regardless of the possible

occurrence of a measurement gap, the UE shall monitor the PDCCH for Random



46/64

Access Response(s) identified by the RA-RNTI defined below, in the RA Responsewindow which starts at the subframe that contains the end of the preamble

transmission [7] plus three subframes and has length ra-ResponseWindowSizesubframes.

It means the earliest time when the network can transmit the RACH response is 3subframe later from the end of RACH Preamble. Then what is the latest time whenthe network can transmit it ? It is determined by ra-ResponseWindowSize. Thiswindow size can be the number between 0 and 10 in the unit of subframes. Thismeans that the maximum time difference between the end of RACH preamble andRACH Response is only 12 subframes (12 ms) which is pretty tight timingrequirement.

PRACH Parameters and Physical Meaning

< prach-ConfigIndex >


47/64

< zeroCorrelationZoneConfig and Highspeedflag >



48/64

< prach-FreqOffset >




49/64

< rootSequenceIndex >

RACH Procedure during Initial Registration - RACH Procedure Summary

Follwing is an example of RACH procedure which happens during the initiail

registration. If you will be an engineer who is working on protocol stackdevelopment or test case development, you should be very familiar with all thedetails of this process.



50/64

Again, we have to know every details of every step without missing anything to bea developer, but of course it is not easy to understand everything at a single shot.So, let's start with something the most important part, which I think is the details ofRACH response. Following diagram shows one example of RACH Response with5 Mhz bandwidth. We don't have to memorize the detailed value itself but shouldbe familiar with the data format and understand which part of this bit string meanswhat.




51/64

If you decode UL Grant part, you will get the following result. You will notice thatthe information it carries would be very similar to DCI format 0 which carriesResource Allocation for uplink data. This information in UL Grant in RACH

Response message is the resource allocation for msg3 (e.g, RRC ConnectionRequest).Note : This is example of RAR for System BW 5 Mhz. If the sytem BWgets different, you should have different RIV values (if you want to have the sameStart_RB, N_RB as in this example) or you will have different Start_RB, N_RB (ifyou keep RIV as below and just change the system BW)

Let me describe this procedure in verbal form again.

i) UE initiate a Random Access Procedure on the (uplink) Random AccessChannel (RACH).(The location of RACH in the frequency/time resource grid theRACH is known to the mobile via the (downlink) Broadcast Channel (BCH). Therandom access message itself only consists of 6 bits and the main content is arandom 5 bit identity)



52/64

ii) Network sends a Random Access Response Message(RARM) at a time andlocation on the Physical Downlink Shared Channel (PDSCH) (The time andlocation of RARM on PDSCH can be calculated from the time and location therandom access message was sent. This message contains the random identity sentby the device, a Cell Radio Network Temporary ID (T_C-RNTI) which will beused for all further bandwidth assignments, and an initial uplink bandwidthassignment)

iii) The mobile device then uses the bandwidth assignment to send a short (around80 bits) RRC Connection Request message which includes it's identity which haspreviously been assigned to it by the core network

Only the step i) uses physical-layer processing specifically designed for randomaccess. The remaining steps utilizes the same physical layer processing as used fornormal uplink and downlink data transmission

How can we get RA RNTI ?

5.1.4 Random Access Response reception" in "TS36.321 says how to calculate

RA=RNTI as follows.

The RA-RNTI associated with the PRACH in which the Random Access Preamble

is transmitted, is computed as:

RA-RNTI = 1 + t_id + 10 * f_id

Where t_id is the index of the first subframe of the specified PRACH (0 t_id


53/64

It means that UE specifies RA_RNTI by the sending timing (SubFrame) ofPRACH Preamble.

An Example of Full RACH Process

Following is an example of Full RACH process with a commercialized LTE deviceand LTE Network Emulator. I would not explain anything in detail. Just check ifthe following diagram make any sense to you. If it does, I would say youunderstand all the details that I explained above.



54/64

PRACH Retransmission

Most part of previous section was about the ideal RACH process, which meansthat UE send PRACH and Network send RACH Response at the first trial andwent through all the way to the end of process at the first trial.

What if UE does not receive RACH Response at the first trial ? What is UEsupposed to do in this case ?

The answer is simple. Just retry (resend) PRACH.

Then you would have more question. ("I" in the following description is "UE")

i) When do I have to retry ? (What should be the time delay between theprevious transmission and the next transmission ?)



55/64

ii) Do I have to retransmit the PRACH with the same power as previous one? Or try with a little bit higher power ? If I have to try with a little bit higher

power, how much power do I have to increase ?

iii) If I keep failing to receive RACH response, how many time I have to

retry ? Do I have to retry until the battery runs out ? or retry only severaltimes and give up ? If I have to give up after a certain amount of retry,exactly how many times do I have to retry ?

The answers to all of these questions are provided by the network.

The answer (instruction) to question i) is provided by Network via a special RARMAC PDU called "Backoff Indicator". (I will explain about Backoff Indicator laterin more detail).

The answer to question ii) and iii) are provided by Network via SIB2 as follows.powerRampingStep is the answer to question ii) and preambleTransMax is theanswer to question iii).

In the following example, powerRampingStep = dB2. It means UE has to increasePRACH power by 2 dB everytime it retries.

preambleTransMax = n6. It means UE retries PRACH retransmit only 6 times andthen give up.

| +-radioResourceConfigCommon ::= SEQUENCE| | +-rach-Config ::= SEQUENCE| | | +-preambleInfo ::= SEQUENCE [0]| | | | +-numberOfRA-Preambles ::= ENUMERATED [n52]| | | | +-preamblesGroupAConfig ::= SEQUENCE OPTIONAL:Omit| | | +-powerRampingParameters ::= SEQUENCE| | | | +-powerRampingStep ::= ENUMERATED [dB2]| | | | +-preambleInitialReceivedTargetPower ::= ENUMERATED [dBm-

104]| | | +-ra-SupervisionInfo ::= SEQUENCE| | | | +-preambleTransMax ::= ENUMERATED [n6]

| | | | +-ra-ResponseWindowSize ::= ENUMERATED [sf10]| | | | +-mac-ContentionResolutionTimer ::= ENUMERATED [sf48]| | | +-maxHARQ-Msg3Tx ::= INTEGER (1..8) [4]

RACH Process Overview In Diagrams


56/64

I have explained long about the RACH process. Now you may ask "What is thetrigger that let UE initiate the RACH process ?". You will see various triggers in3GTS 36.300 (10.1.5) : Overall description of RACH Process.

"Turning on UE" is one of the trigger for sure. And following is another trigger forthis process.

< RACH Procedure on Initial Registration >

This is basically the same sequence that I explained in previous sections, but I

simplified the diagram in previous sections to let reader focused more onmessaging part of RACH procedure. In this diagram, you see some additional stepslike HARQ ACK, DCI 0 (UL Grant). This flow is more similar to real live networkprocedure.


57/64

< RACH Procedure on Handover - Contention Based >



58/64

< RACH Procedure on Handover - NonContention Based >



59/64



60/64



61/64



62/64



63/64

PRACH RF Snapshot



64/64

3GPP Standard for RACH Process

3GTS 36.300 (10.1.5) : Overall description of RACH Process. Read this first.

3GTS 36.211 (5.7) : RRC Messages and IE (Information Elements) which areinvolved in RACH process.

3GTS 36.213 (6) : MAC Layer Procedure related to RACH Process.


bug testing

Documents