Defect Life Cycle (Bug Life cycle) is the journey of a defect from its

identification 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 VERIFIED Defect Status Explanation NEW: Tester finds a defect and posts it with the status NEW. This defect is yet 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 NEW defect and if it is found to be valid it is assigned to a member of the Development Team. The assigned Developers responsibility is now to fix the 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. This defect is ASSIGNED when the time comes. DROPPED / REJECTED: Test / Development/ Project lead studies the NEW 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 defect back to the Test Team. A COMPLETED defect is either CLOSED, if fine, or REASSIGNED, if still not fine. If a Developer cannot fix a defect, some organizations may offer the following statuses: Wont Fix / Cant Fix: The Developer will not or cannot fix the defect due to some reason.

 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 who fixed it. A REASSIGNED defect needs to be COMPLETED again. CLOSED / VERIFIED: If the Tester / Test Lead finds that the defect is indeed 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 exactly means. 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 upto-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 is called 'Bug/Error Life Cycle'. Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned various statuses which are New, Open, Postpone, Pending Retest, 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

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 and is marked with a status of 'Pending Reject' before passing it back to the testing team. After getting a satisfactory reply from the development side, the test leader marks the 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 and the 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 back to the Development leader. The development leader changes the status of the bug to 'Pending Retest' and passes 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 for retest. 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, the development 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' and passes 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 for retest. The tester retests the bug and the same problem persists, so the tester after confirmation from test leader reopens the bug and marks it with a 'Reopen' status.

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 same scenario 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. And finally, the developer rejects the bug marking it as 'Rejected'. Cycle VI After confirmation that the data is unavailable or certain functionality is unavailable, the solution and retest of the bug is postponed for indefinite time and it is marked as 'Postponed'. Cycle VII If the bug does not stand importance and needs to be postponed, then it is given a status 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 of Closed, Rejected, Deferred or Postponed.

Question- What are stage in a Bug Life Cycle

Answer 1.New-when tester finds the defect 1st time it will be in new status. 2.Open-when the TL finds it to be genuine defect/bug then he makes it as open status. 3.Assign-the TL assign the bug to the developer to fix it if he finds it to be genuine he ll fix it. 4.Test-after fixing the bug it is sent to tester to do regression & retesting of that fixed/changed module. 5.verified-after testing it is been verified to no if any bug still there. 6.Reject-if the developer think bug is not genuine and not effecting the application then he will reject it. 7.Differed-if the bug is found and fixed in next release if severity and priority is low /because of less time then it turn out to be differed status. 8.duplicate-if same bug's r found then it is made as duplicate. 9.Closed-when the bug is fixed and tested if no further bug is foung then it given as closed status

Answer1-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 will set the status as open. 3-FIXED- whenever the developer rectifies the defect before releasing the next build he will set the status fixed. 4-CLOSED-Whenever the next build is released the testers will check whether the defects are properly rectified or not.if at all they feel defect is properly rectified then they set status as close. 5-REOPEN- once the next build is released the testers will check whether the defect is properly rectified or not.if at all they feel derct is not rectified properly 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 a defect then he will set status as reject. 8-ASPERDESIGN- Whenever the developer feels the tester has raised the defect without knowing the latest requirements then he will set the status as asperdesing. 9-DEFFERED- Whenever the defect is accepted by the developer and he requires some extra time to rectify that defect then he will set the status as deffered.

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 Planning This is the phase where Project Manager has to decide what things need to be tested, do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce 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 high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan. Test Analysis Once test plan is made and decided upon, next step is to delve little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing. Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating

test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance testing. Test Design Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared. Construction and verification In this phase we have to complete all the test plans, test cases, 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 unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported. Testing Cycles In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3.). Final Testing and Implementation In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.

Currently role is performing Specialty based testing (i.e.) FUNCTIONALITY TESTING. Post Implementation In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process. Cleaning up of test environment is done and test machines 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 of Priority Levels during the product test phase and Guidelines on writing Bug Description. Introduction: Bug can be defined as the abnormal behavior of the software . No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of the Application under Test (AUT).
The imag e can

Bug Life Cycle: In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows: The different states of a bug can be summarized as follows: 1. New 2. Open 3. Assign 4. Test 5. Verified 6. Deferred

7. Reopened 8. Duplicate 9. Rejected and 10. Closed Description of Various Stages: 1. New: When the bug is posted for the first time, its state will be NEW. This means that the bug is not yet approved. 2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as OPEN. 3. Assign: Once the lead changes the state as OPEN, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to ASSIGN. 4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to TEST. It specifies that the bug has been fixed and is released to testing team. 5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release 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 same concept 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 tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to VERIFIED. 9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester 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 that the bug no longer exists in the software, he changes the status of the bug to CLOSED. This state means that the bug is fixed, tested and approved. While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal.

Discovering and removing defects is an expensive and inefficient process. It is much 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 administrators of the application under test. This information is used by developers and management as the basis for assigning priority of work on defects. A sample guideline for assignment of Priority Levels during the product test phase includes: 1. Critical / Show Stopper An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu 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 as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc. . 3. Average / Medium The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points. . 4. Minor / Low Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bug. Guidelines on writing Bug Description: Bug can be expressed as Result followed by the action. That means, the unexpected behavior occurring when a particular action takes place can be given as bug description. 1. Be specific. State the expected behavior which did not occur - such as after pop-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).

6. Mention steps to reproduce the bug compulsorily. Integration Testing: Why? What? & How? Introduction: As we covered in various articles in the Testing series there are various levels of testing: Unit Testing, Integration Testing, System Testing Each level of testing builds on the previous level. Unit testing focuses on testing a unit of the code. Integration testing is the next level of testing. This level of testing focuses on testing the integration of units of code or components. How does Integration Testing fit into the Software Development Life Cycle? Even if a software component is successfully unit tested, in an enterprise n-tier n distributed application it is of little or no value if the component cannot be successfully integrated with the rest of the application. Once unit tested components are delivered we then integrate them together. These integrated components are tested to weed out errors and bugs caused due to the integration. This is a very important step in the Software Development Life Cycle. It is possible that different programmers developed different components. A lot of bugs emerge during the integration step. In most cases a dedicated testing team focuses on Integration Testing. Prerequisites for Integration Testing: Before we begin Integration tegration Testing it is important that all the components have been successfully unit tested. Integration Testing Steps: Integration Testing typically involves the following Steps: Step 1: Create a Test Plan Step 2: Create Test Cases and Test Data Step 3: If applicable create scripts to run test cases Step 4: Once the components have been integrated execute the test cases Step 5: Fix the bugs if any and re test the code

Step 6: Repeat the test cycle until the components have been successfully integrated What is an Integration Test Plan? As you may have read in the other articles in the series, this document typically describes 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/control from one component to the other. So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should 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 Suite Each suite may have a particular focus. In other words different Test Suites may be created to focus on different areas of the application. As mentioned before a dedicated Testing Team may be created to execute the Integration test cases. Therefore the Integration Test Cases should be as detailed as possible. Sample Test Case Table: Test Test Case Input Case Description Data ID Expected Result Actual Result Pass/Fail Remarks

Additionally the following information may also be captured: a) Test Suite Name b) Tested By c) Date d) Test Iteration (One or more iterations of Integration testing may be performed) Working towards Effective Integration Testing: There are various factors that affect Software Integration and hence Integration Testing: 1) Software Configuration Management: Since Integration Testing focuses on Integration of components and components can be built by different developers and even different development teams, it is important the right version of components are tested. This may sound very basic, but the biggest problem faced in n-tier development is integrating the right version of components. Integration testing may run through several iterations and to fix bugs components may undergo changes. Hence it is important that a good Software Configuration Management (SCM) policy is in place. We should be able to track the components and their versions. So each time we integrate the application components we know exactly what versions go into the build process. 2) Automate Build Process where Necessary: A Lot of errors occur because the wrong version of components were sent for the build or there are missing components. If possible write a script to integrate and deploy the components this helps reduce manual errors. 3) Document: Document the Integration process/build process to help eliminate the errors of omission or oversight. It is possible that the person responsible for integrating the components forgets to run a required script and the Integration Testing will not yield correct results. 4) Defect Tracking: Integration Testing will lose its edge if the defects are not tracked correctly. Each defect should be documented and tracked. Information should be captured as to how the defect was fixed. This is valuable information. It can help in future integration and deployment processes. Summary: Integration testing is the most crucial steps in Software Development Life Cycle. Different components are integrated together and tested. This can be a daunting task in enterprise applications where diverse teams build different modules and components. In this article you learned the steps needed to perform Integration Testing.

System Testing: Why? What? & How? Introduction: Unit testing focuses on testing each unit of the code. Integration testing focuses on testing the integration of units of code or components. Each level of testing builds on the previous level. System Testing is the next level of testing. It focuses on testing the system as a whole. How does System Testing fit into the Software Development Life Cycle? In a typical Enterprise, unit testing is done by the prog programmers. rammers. This ensures that the individual components are working OK. The Integration testing focuses on successful integration of all the individual pieces of software (components or units of code). Once the components are integrated, the system as a who whole le needs to be rigorously tested to ensure that it meets the Quality Standards. Thus the System testing builds on the previous levels of testing namely unit testing and Integration Testing. Usually a dedicated testing team is responsible for doing System Testing. Why System Testing is important? System Testing is a crucial step in Quality Management Process. ........- In the Software Development Life cycle System Testing is the first level where ...........the the System is tested as a whole ........- The System is tested to verify if it meets the functional and technical ...........requirements ........- The application/System is tested in an en environment vironment that closely resembles the ...........production production environment where the application will be finally deployed ........- The System Testing enables us to test, verify and validate both the Business ...........requirements requirements as well as the Applicati Application Architecture

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 multiple environments. 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 document typically 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

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 performance standards Since a dedicated test team may execute the test cases it is necessary that System Test 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 illustrated below: Test Case ID Test Case Description: What to Test? How to Test? Input Data Expected Result Actual Result Sample Test Case Format: Expected Actual Pass/Fail Test What How to Input Case To Test? Data Result Result ID Test? . . . . . . . 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:

1) Test Coverage: System Testing will be effective only to the extent of the coverage of Test Cases. What is Test coverage? Adequate Test coverage implies the scenarios covered by the test cases are sufficient. The Test cases should cover all scenarios, use cases, Business Requirements, Technical Requirements, and Performance Requirements. The test cases should enable us to verify and validate that the system/application meets the project goals and specifications. 2) Defect Tracking: The defects found during the process of testing should be tracked. 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 application deployed 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 as specified. 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 instance simulating a large number of users or simulating increasing large amounts of 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. Appropriate metrics/Statistics can be captured to validate or verify the efficiency of the technical design /architecture. What is Regression Testing? Introduction: This article attempts to take a close look at the process and techniques in Regression Testing. What is Regression Testing? If a piece of Software- is modified for any reason testing needs to be done to ensure that it works as specified and that it has not negatively impacted any functionality that it offered previously. This is known as Regression Testing. Regression Testing attempts to verify: - That the application works as specified even after the changes/additions/modification were made to it

- The original functionality continues to work as specified even after changes/additions/modification to the software application - The changes/additions/modification to the software application have not introduced any new bugs When is Regression Testing necessary? Regression Testing plays an important role in any Scenario where a change has been made to a previously tested software code. Regression Testing is hence an important aspect in various Software Methodologies where software changes enhancements occur frequently. Any Software Development Project is invariably faced with requests for changing Design, code, features or all of them. Some Development Methodologies embrace change. For example Extreme Programming Methodology advocates applying small incremental changes to the system based on the end user feedback. Each change implies more Regression Testing needs to be done to ensure that the System 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 the original functionality. With each change Regression Testing could become more and more costly.

To make the Regression Testing Cost Effective and yet ensure good coverage one or more of the following techniques may be applied: - Test Automation: If the Test cases are automated the test cases may be executed using 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 in faster and cheaper execution of Test cases. However there is cost involved in building the scripts. - Selective Testing: Some Teams choose execute the test cases selectively. They do not execute all the Test Cases during the Regression Testing. They test only what 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 tested during Regression Testing. Generally the following areas are covered during Regression 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 are necessary: Create a Regression Test Plan: Test Plan identified Focus Areas, Strategy, Test Entry 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 functionality addressed by the change and all components affected by the change. The Regression Test case may also include the testing of the performance of the components and the application after the change(s) were done. Defect Tracking: As in all other Testing Levels and Types It is important Defects are tracked systematically, otherwise it undermines the Testing Effort.

What is User Acceptance Testing? Introduction: This article attempts to explain the process of User Acceptance Testing. Once the application is ready to be released the crucial step is User Acceptance Testing. In this step a group representing a cross section of end users test tests s the application. The user acceptance testing is done using real world scenarios and perceptions relevant to the end users. What is User Acceptance Testing? User Acceptance Testing is often the final step before rolling out the application. Usually the e end users who will be using the applications test the application before accepting the application. This type of testing gives the end users the confidence that the application being delivered to them meets their requirements. This testing also helps nail bugs related to usability of the application. User Acceptance Testing Prerequisites: Before the User Acceptance testing can be done the application is fully developed. Various levels of testing (Unit, Integration and Syste System) m) are already completed before User Acceptance Testing is done. As various levels of testing have been completed most of the technical bugs have already been fixed before UAT. User Acceptance Testing What to Test? To ensure an effective User Acceptanc Acceptance e Testing Test cases are created. These Test cases can be created using various use cases identified during the Requirements definition stage. The Test cases ensure proper coverage of all the scenarios during testing. During this type of testing the spe specific cific focus is the exact real world usage of the application. The Testing is done in an environment that simulates the production environment. The Test cases are written using real world scenarios for the application

 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 the technical 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 an environment that closely resembles the real world or production environment. The steps taken for User Acceptance Testing typically involve one or more of the following: .......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 affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria. Designing UA Test Cases: The User Acceptance Test Cases help the Test Execution Team to test the application thoroughly. This also helps ensure that the UA Testing provides sufficient coverage of all the scenarios. The Use Cases created during the Requirements definition phase may be used as inputs for creating Test Cases. The inputs from Business Analysts and Subject Matter Experts are also used for creating. Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something. The Business Analysts and the Project Team review the User Acceptance Test Cases. 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.

Executing Test Cases: The Testing Team executes the Test Cases and may additional perform random Tests relevant to them Documenting the Defects found during UAT: The Team logs their comments and any defects or issues found during testing. Resolving the issues/Bug Fixing: The issues/defects found during Testing are discussed with the Project Team, Subject Matter Experts and Business Analysts. The issues are resolved as per the mutual consensus and to the satisfaction of the end users. Sign Off: Upon successful completion of the User Acceptance Testing and resolution of the issues the team generally indicates the acceptance of the application. This step is important in commercial software sales. Once the User Accept the Software delivered they indicate that the software meets their requirements. The users now confident of the software solution delivered and th the e vendor can be paid for the same. Ads What are the key deliverables of User Acceptance Testing? In the Traditional Software Development Lifecycle successful completion of User Acceptance Testing is a significant milestone. The Key Deliverables typically of User Acceptance Testing Phase are: 1) The Test Plan- This outlines the Testing Strategy 2) The UAT Test cases The Test cases help the team to effectively test the application 3) The Test Log This is a log of all the test cases executed and the actual results. 4) User Sign Off This indicates that the customer finds the product delivered to their satisfaction Summary: In this article we studied the process of User Accepta Acceptance Testing.

Unit Testing: Why? What? & How? Author : Exforsys Inc. Published on: 8th Jan 2006 | Last Updated on: 8th Dec 2010 Unit Testing: Why? What? & How? In this tutorial you will learn about unit testing, various levels of testing, various vario types of testing based upon the intent of testing, How does Unit Testing fit into the Software Development Life Cycle? Unit Testing Tasks and Steps, What is a Unit Test Plan? What is a Test Case? and Test Case Sample, Steps to Effective Unit Testing. There are various levels of testing: Unit Testing Integration Testing System Testing There are various types of testing based upon the intent of testing such as: Acceptance Testing Performance Testing Load Testing Regression Testing Based on the testing Techniques testing can be classified as: Black box Testing White box Testing How does Unit Testing fit into the Software Development Life Cycle? This is the first and the most important level of testing. As soon as the programmer develops a unit of code the unit is tested for va various rious scenarios. As the application is built it is much more economical to find and eliminate the bugs early on. Hence Unit Testing is the most important of all the testing levels. As the software project progresses ahead it becomes more and more costly to find and fix the bugs. In most cases it is the developers responsibility to deliver Unit Tested Code. Unit Testing Tasks and Steps: Step 1: Create a Test Plan Step 2: Create Test Cases and Test Data Step 3: If applicable create scripts to run test c cases Step 4: Once the code is ready execute the test cases

Step 5: Fix the bugs if any and re test the code Step 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 carried out. This will typically include 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 and 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 Field Step 2: Click on Submit Test Cases clubbed together form a Test Suite Test Case Sample Test Test Case Input Case Description Data ID Expected Result Actual Result Pass/Fail Remarks

Additionally the following information may also be captured: a) Unit Name and Version Being tested b) Tested By c) Date d) 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 each test case. There are several important advantages if the test cases and the actual execution of test cases are well documented. a. Documenting Test Cases prevents oversight. b. Documentation clearly indicates the quality of test cases

c. If the code needs to be retested we can be sure that we did not miss anything d. 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 attrition f. Sometimes Unit Test Cases can be used to develop test cases for other levels of testing 2) What should be tested when Unit Testing: A lot depends on the type of program or unit that is being created. It could be a screen or a component or a web service. Broadly the following aspects should be considered: a. For a UI screen include test cases to verify all the screen elements that need to appear on the screens b. For a UI screen include Test cases to verify the spelling/font/size of all the labels 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 in a test cycle d. Create Test Cases such that every condition in case of conditional statements is tested once e. Create Test Cases to test the minimum/maximum range of data that can be entered. For example what is the maximum amount that can be entered or the max length of string that can be entered or passed in as a parameter f. Create Test Cases to verify how various errors are handled g. Create Test Cases to verify if all the validations are being performed 3) Automate where Necessary: Time pressures/Pressure to get the job done may result in developers cutting corners in unit testing. Sometimes it helps to write scripts, which automate a part of unit testing. This may help ensure that the necessary tests were done and may result in saving time required to perform the tests. Ads Summary: Unit Testing is the first level of testing and the most important one. Detecting and fixing bugs early on in the Software Lifecycle helps reduce costly fixes later on. An Effective Unit Testing Process can and should be developed to increase the Software Reliability and credibility of the developer. The Above article explains how Unit Testing should be done and the important points that should be considered when doing Unit Testing.

Many new developers take the unit testing tasks lightly and realize the importance of Unit Testing further down the road if they are still part of the project. This article serves as a starting point for laying out an effective (Unit) Testing Strategy. Published on: 17th May 2005 | Last Updated on: 15th Mar 2011 This article explains about different testing types Unit Test. System Test, P Integration Test, Functional Test, Performance Test, Beta Test and Acceptance Acceptanc a Test. g e Introduction: 1 The development process involves various types of testing. Each test type addresses a specific testing requirement. The most common types of testing te o involved in the development process are: f Unit Test. System Test Integration Test Functional Test Performance Test Beta Test Acceptance Test. Unit Test The first test in the development process is the unit test. The source code is normally divided into modules, which in turn are divided into smaller units called units. These units have specific behavior. The test done on these units of code is called unit test. Unit test depends upon the language on which the project is developed. . Unit tests ensure that each unique path of the project performs accurately to the documented specifications and contains clearly defined inputs and expected results. System Test Several modules constitute a project. If the project is long long-term term project, several developers write the modules. Once all the modules are integrated, several errors may arise. The testing done at this stage is called system test. System testing ensures that the entire integrated software system meets requirements. It tests a configuration to ensure known and predictable results. 2 Author : Exforsys Inc.

System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points. Testing a specific hardware/software installation. This is typically performed on a COTS (commercial off the shelf) system or any other system comprised of disparent parts where custom configurations and/or unique installations are the norm. Functional Test Functional test can be defined as testing two or more modules together with the intent of finding defects, demonstrating that defects are not present, verifying that the module performs its intended functions as stated in the specification and establishing 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 and customer acceptance. Ad Hoc Testing Testing without a formal test plan or outside of a test plan. With some projects this type of testing is carried out as an adjunct to formal testing. If carried out by a skilled 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 the only 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 and prior 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 in close cooperation with the software engineering department. Ads Automated Testing Software testing that utilizes a variety of tools to automate the testing process and when the importance of having a person manually testing is diminished. Automated testing still requires a skilled quality assurance professional with knowledge of the automation tool and the software being tested to set up the tests.

Beta Testing Testing after the product is code complete. Betas are often widely distributed or even distributed to the public at large in hopes that they will buy the final product when it is released. Black Box Testing Testing software without any knowledge of the inner workings, structure or language 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 or requirements document.

Compatibility Testing Testing used to determine whether other system software components such as browsers, utilities, and competing software will conflict with the software being tested. Configuration Testing Testing to determine how well the product works with a broad range of hardware/peripheral equipment configurations as well as on different operating systems and software. Independent Verification & Validation The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The individual or group doing this work is not part of the group or organization that developed the software. A term often applied to government work or where the government regulates the products, as in medical devices. Installation Testing Testing with the intent of determining if the product will install on a variety of platforms and how easily it installs. Integration Testing Testing two or more modules or functions together with the intent of finding interface defects between the modules or functions. Testing completed at as a part of unit or functional testing, and sometimes, becomes its own standalone test

phase. On a larger level, integration testing can involve a putting together of groups of modules and functions with the goal of completing and verifying that the system meets the system requirements. (see system testing) Load Testing Testing with the intent of determining how well the product handles competition for 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 of events. Automated test tools geared specifically to test and fine-tune performance are used most often for this type of testing. Pilot Testing Testing that involves the users just before actual release to ensure that users become familiar with the release contents and ultimately accept it. Often is considered a Move-to-Production activity for ERP releases or a beta test for commercial products. Typically involves many users, is conducted over a short period 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 have not created any new problems. Also, this type of testing is done to ensure that no degradation of baseline functionality has occurred. Security Testing Testing of database and network software in order to keep company data and resources secure from mistaken/accidental users, hackers, and other malevolent attackers. Software Testing The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The organization and management of individuals or groups doing this work is not relevant. This term is often applied to commercial products such as internet applications. (contrast with independent verification and validation)

Stress Testing Testing with the intent of determining how well a product performs when a load is placed on the system resources that nears and then exceeds capacity. User Acceptance Testing See Acceptance Testing. White Box Testing Testing in which the software tester has knowledge of the inner workings, structure and 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 a problem happens in the middle of doing something, it is relatively easy to find the root 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 you want to test and then turned on the UE. In a several second UE start booting and then in a couple of second you see a couple of antenna bars somewhere at the top of 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 normal Antenna 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 pin point 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 network emulator side and turn on the UE.. UE start booting up .. showing the message saying "Searching Network ...." and got stuck there.. with no Antenna bars .. not even 'SOS' .. just saying "No service". And I collected UE side log and Network Emulator 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 the WCDMA UE ?

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 not only in the higher signaling layer, but also all the way down to the physical layers related to these first step. And also you have to use proper equipment which can show these detailed process. If you have an equipment that does not provide the logging or it provides log but only higher layer singnaling log, it will be extremly difficult to troubleshoot. Given that you have the proper tools, the next thing you have to be ready is to understand the detailed knowledge of these process. Without the knowledge, however good tools I have it doesn't mean anything to me. So ? I want to teach myself here about the first step of LTE signaling which is RACH process. (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 aside for 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 layer stuffs) in WCDMA. It would also be helpful if you think about when 'Channel Request' 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.. but anyway I got this kind of impression. In LTE, RACH process happens in following situation (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 access procedure E.g. when UL synchronisation status is non-synchronised

v) UL data arrival during RRC_CONNECTED requiring random access procedure E.g. when UL synchronisation status is "non-synchronised" or there are no PUCCH resources for SR available. vi) For positioning purpose during RRC_CONNECTED requiring random access 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 preamble signatures 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 with identical signatures ? Yes. There is such a possibility. It means the same PRACH preamble from multipe UE reaches 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 RACH process, Network would go through additional process at later step to resolve these contention and this process is called "Contention Resolution" step. But there is some cases that these kind of contention is not acceptable due to some reason (e.g, timing restriction) and these contention can be prevented. Usually in this case, the Network informs each of the UE of exactly when and which preamble signature it has to use. Of course, in this case Network will allocate these preamble signature so that it would not collide. This kind of RACH process is

called "Contention Free" RACH procedure. To initiate the "Contention Free" RACH process, UE should be in Connected Mode before the RACH process as in Handover 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 : Random Access Response (Timing Advance, T_C-RNTI, UL grant for L2/L3 message) iii) 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 sent PRACH. In this case, both of the UE will recieve the same T_C-RNTI and resource allocation at step ii). And as a result, both UE would send L2/L3 message through the same resource allocation(meaning with the same time/frequency location) to NW at step iii). What would happen when both UE transmit the exact same information on the exact same time/frequency location ? One possibility is that these two signal act as interference to each other and NW decode neither of them. In this case, none of the UE would have any response (HARQ ACK) from NW and they all think that RACH process has failed and go back to step i). The other possibility would be that NW could successfully decode the message from only one UE and failed to decode it from the other UE. In this case, the UE with the successful L2/L3 decoding on NW side will get the HARQ ACK from Network. This HARQ ACK process for step iii) message is called "contention resolution" process. Typical 'Contention Free' RACH Procedure is as follows : i) UE <--NW : RACH Preamble Assignment ii) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size) iii) UE <--NW : Random Access Response (Timing Advance, C-RNTI, UL grant for L2/L3 message)

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.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

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

For example, if the UE is using "PRACH Configuration Idex 0", it should transmit the RACH only in EVEN number SFN(System Frame Number). Is this good enough 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 Frame Number" colulmn of the table. It says "1" for "PRACH Configuration Idex 0". It means the UE is allowed to transmit RACH only at sub frame number 1 of every even SFN. Checking your understanding of the table, I will give you one question. With which "PRACH Configuration Idex", it would be the easiest for the Network to detect the RACH from UE ? and Why ? The answer would be 14, because UE can send the RACH in any SFN and any slots within the frame. In a big picture, you should know all the dimmensions in the following diagram. (The Red rectangle is PRACH signal).
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

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

when the preamble format is 0~3. n_RA_PRBoffset in this equation is specified by prach-FreqOffset in SIB2.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

What is preamble format ? If you see the table 5.7.1-1 show above, you see the column titled as "Preamble Format". What is the preamble format ? It is defined as following diagram. You would see that the length of PRACH preamble varies depending on the preamble 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).

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

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 format depending 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 the PRACH 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 sends it because Network tells UE when the UE is supposed to transmit the RACH. (If UE fails to decode properly the network information about the RACH, Network will fail to detect it even though UE sends RACH). Following section will describe network informaton on RACH.

Which RRC Message contains RACH Configuration ? It is in SIB2 and you can find the details in 3GPP 36.331.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

numberOfRA-Preambles : There are total 64 RA preambles that UE can randomly choose from. But usually a cell reserve several Preambles for 'Non-contention based' 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 with normal 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 Mhz One 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 1 UL Subframe subcarrier.

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

How to generate RACH Signal ? You don't have to know the details of this procedure unless you are the DSP or FPGA engineer implementing LTE PHY. Just as a common sense about LTE, let's know that PRACH is a kind of ZaddOff Chu Sequence generated by the following equation.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

, where u = physical root sequence index

There are 64 preambles available for each cell and UE has to be able to generate the 64 preambles for the cell it want to camp on. You can easily generate 64 different preambles just by cyclically shifting an existing sequence, but there is a condition for this. All the preamle sequences should be authogonal to each other. Otherwise, various preambles from multiple UEs within the same cell can interfere each other. So we have to shift the generated 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 one of the most complicated process in PRACH preamble generation because it gets involved with so many different parameters in cascading manner).
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

First, you would notice that we use different process to calculate Cv depending on whether 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. As you see in this mapping, N_cs values also gets different depending on whether we use 'restricted sets' or 'unrestricted sets'.

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

Now let's look at how we get Nzc. This is pretty straightforward. Nzc is determined by the following table.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

If the Preamble is using the unrestricted sets, it is pretty simple. You only have to know Nzc, Ncs to figure out Cv. The problem is when the Preamble is using the 'restricted sets'. As you see the equation above, you need to know the following 4 values to figure out Cv in 'restricted sets'.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may hav e to delete the image and then insert it again.

The problem is that the calculation of these four variable is very complicated as shown below.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

You would noticed that you need another value to calculate to determine which of the three case we have to use. It is du. So we need another process to determine du.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

We went through a complicated procedure just to determin one number (Cv). Once we get Cv, we can generate multiple preambles using the following function.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

Anyway, now we got a PRACH Preamble sequence in hand, but this is not all. In order to transmit this data. We have to convert this data into a time domain sequence and this conversion is done by the following process.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

For the whole PRACH generation procedure, please refer to 5.7.2/5.7.3 of TS 36.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 which subframe, the network should transmit the RACH Response ? The following is what 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

Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes. It means the earliest time when the network can transmit the RACH response is 3 subframe later from the end of RACH Preamble. Then what is the latest time when the network can transmit it ? It is determined by ra-ResponseWindowSize. This window size can be the number between 0 and 10 in the unit of subframes. This means that the maximum time difference between the end of RACH preamble and RACH Response is only 12 subframes (12 ms) which is pretty tight timing requirement.

PRACH Parameters and Physical Meaning < prach-ConfigIndex >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

< zeroCorrelationZoneConfig and Highspeedflag >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

< prach-FreqOffset >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

< rootSequenceIndex >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

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 stack development or test case development, you should be very familiar with all the details of this process.

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

Again, we have to know every details of every step without missing anything to be a 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 of RACH response. Following diagram shows one example of RACH Response with 5 Mhz bandwidth. We don't have to memorize the detailed value itself but should be familiar with the data format and understand which part of this bit string means what.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

If you decode UL Grant part, you will get the following result. You will notice that the information it carries would be very similar to DCI format 0 which carries Resource Allocation for uplink data. This information in UL Grant in RACH Response message is the resource allocation for msg3 (e.g, RRC Connection Request). Note : This is example of RAR for System BW 5 Mhz. If the sytem BW gets different, you should have different RIV values (if you want to have the same Start_RB, N_RB as in this example) or you will have different Start_RB, N_RB (if you keep RIV as below and just change the system BW)
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

Let me describe this procedure in verbal form again. i) UE initiate a Random Access Procedure on the (uplink) Random Access Channel (RACH).(The location of RACH in the frequency/time resource grid the RACH is known to the mobile via the (downlink) Broadcast Channel (BCH). The random access message itself only consists of 6 bits and the main content is a random 5 bit identity)

ii) Network sends a Random Access Response Message(RARM) at a time and location on the Physical Downlink Shared Channel (PDSCH) (The time and location of RARM on PDSCH can be calculated from the time and location the random access message was sent. This message contains the random identity sent by the device, a Cell Radio Network Temporary ID (T_C-RNTI) which will be used for all further bandwidth assignments, and an initial uplink bandwidth assignment) iii) The mobile device then uses the bandwidth assignment to send a short (around 80 bits) RRC Connection Request message which includes it's identity which has previously been assigned to it by the core network Only the step i) uses physical-layer processing specifically designed for random access. The remaining steps utilizes the same physical layer processing as used for normal 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 <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0 f_id< 6). For FDD, f_id is fixed as 0. Therefore, RA_RNTI is decided by the sending timing (SubFrame) of PRACH Preamble by UE.

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

An Example of Full RACH Process Following is an example of Full RACH process with a commercialized LTE device and LTE Network Emulator. I would not explain anything in detail. Just check if the following diagram make any sense to you. If it does, I would say you understand all the details that I explained above.
The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

PRACH Retransmission Most part of previous section was about the ideal RACH process, which means that UE send PRACH and Network send RACH Response at the first trial and went 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 UE supposed 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 the previous transmission and the next transmission ?)

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 several times 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 RAR MAC PDU called "Backoff Indicator". (I will explain about Backoff Indicator later in 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 the answer to question iii). In the following example, powerRampingStep = dB2. It means UE has to increase PRACH power by 2 dB everytime it retries. preambleTransMax = n6. It means UE retries PRACH retransmit only 6 times and then give up. | | | | | | | | 104] | | | | | | | +-ra-SupervisionInfo ::= SEQUENCE | | | +-preambleTransMax ::= ENUMERATED [n6] | | | +-ra-ResponseWindowSize ::= ENUMERATED [sf10] | | | +-mac-ContentionResolutionTimer ::= ENUMERATED [sf48] | | +-maxHARQ-Msg3Tx ::= INTEGER (1..8) [4] +-radioResourceConfigCommon ::= SEQUENCE | +-rach-Config ::= SEQUENCE | | +-preambleInfo ::= SEQUENCE [0] | | | +-numberOfRA-Preambles ::= ENUMERATED [n52] | | | +-preamblesGroupAConfig ::= SEQUENCE OPTIONAL:Omit | | +-powerRampingParameters ::= SEQUENCE | | | +-powerRampingStep ::= ENUMERATED [dB2] | | | +-preambleInitialReceivedTargetPower ::= ENUMERATED [dBm-

RACH Process Overview In Diagrams

I have explained long about the RACH process. Now you may ask "What is the trigger that let UE initiate the RACH process ?". You will see various triggers in 3GTS 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 for this 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 on messaging part of RACH procedure. In this diagram, you see some additional steps like HARQ ACK, DCI 0 (UL Grant). This flow is more similar to real live network procedure.

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

< RACH Procedure on Handover - Contention Based >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

< RACH Procedure on Handover - NonContention Based >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

<RACH Procedure on DL Data Arrival when Out-of-Sync - Non Contention Based >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

<RACH Procedure on DL Data Arrival when Out-of-Sync - Contention Based >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

<RACH Procedure on UL Data Arrival when Out-of-Sync >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

<RACH Procedure on RRC Connection Re-establishment when Out-of-Sync >

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

PRACH RF Snapshot

The image cannot be display ed. Your computer may not hav e enough memory to open the image, or the image may hav e been corrupted. Restart your computer, and then open the file again. If the red x still appears, y ou may hav e to delete the image and then insert it again.

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 are involved in RACH process. 3GTS 36.213 (6) : MAC Layer Procedure related to RACH Process.