- "Describe yourself!", This question is almost invariably asked in the majority of interviews, and just as invariably answered dismally!. What does one say and why do we always seem so flustered by the question?. Because we have always been taught by our parents and respected elders not to boast or talk about ourselves.
With a childhood full of such repressive advice, its not surprising that the majority of us begin the answer with a stammer and a blush, almost instantly changing from flash to foolish and ruining our chances of employment.
So what do we say? Frankly, just answer the question as it comes. Most disconcerted candidates dread this question and begin with a silly "Basically, my name is ...". Why don't we realize that our CV is there right in front of the interviewer, and he knows this already.
By repeating the stuff that fills our CV, we just demonstrate that we are an 'in-the-box' kind of person, with little if any skill in innovation and presentation.
Actually, a question of this kind is an ideal way to plug in everything we want to say about ourselves that we had leave out of the CV. If you have attended a premier institution, say that the institution taught you much more than the degree it awarded o, mention people who influenced o, talk about the books you like reading, your hobbies and your other interests.
Talk about your strengths; perhaps mention an instance when you used your conflict resolution skills or selling skills or whatever. But make certain that it does not sound like blowing your trumpet. Mention these instances as learning.
Tall about your weaknesses, but make sure that they are 'positive' weaknesses. For instance you could say that that you sometimes pay more attention to detail than is warranted. You can openly confess a tendency to be impatient with team members who cannot carry their own weight, or who cannot contribute sufficiently.
But first, think today what you want to say and practice. Remember, if you hesitate about yourself, your interviewers will doubt whether you fit their bill of requirements. After all, if you don't know about you, who does?
Tuesday, December 14, 2010
Types of Testing
Q. What kinds of testing should be considered?
A. Black box testing - not based on any knowledge of internal design or code.
Tests are based on requirements and functionality.
White box testing - based on knowledge of the internal logic of an application's code.
Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing - the most 'micro' scale of testing; to test particular functions or code modules.
Typically done by the programmer and not by testers, as it requires detailed knowledge of the
internal program design and code. Not always easily done unless the application has a well-designed
architecture with tight code; may require developing test driver modules or test harnesses.
Incremental integration testing - continuous testing of an application as new functionality is added;
requires that various aspects of an application's functionality be independent enough to work separately
before all parts of the program are completed, or that test drivers be developed as needed; done by
programmers or by testers.
Integration testing - testing of combined parts of an application to determine if they function together
correctly. The 'parts' can be code modules, individual applications, client and server applications on a
network, etc. This type of testing is especially relevant to client/server and distributed systems.
Functional testing - black-box type testing geared to functional requirements of an application; this type
of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their
code works before releasing it (which of course applies to any stage of testing.)
System testing - black-box type testing that is based on overall requirements specifications; covers all
combined parts of a system.
End-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of
a complete application environment in a situation that mimics real-world use, such as interacting with
a database, using network communications, or interacting with other hardware, applications, or systems
if appropriate.
Sanity testing - typically an initial testing effort to determine if a new software version is performing
well enough to accept it for a major testing effort. For example, if the new software is crashing systems
every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a
'sane' enough condition to warrant further testing in its current state.
Regression testing - re-testing after fixes or modifications of the software or its environment.
It can be difficult to determine how much re-testing is needed, especially near the end of the
development cycle. Automated testing tools can be especially useful for this type of testing.
Acceptance testing - final testing based on specifications of the end-user or customer, or based on use
by end-users/customers over some limited period of time.
Load testing - testing an application under heavy loads, such as testing of a web site under a range of
loads to determine at what point the system's response time degrades or fails.
Stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to
describe such tests as system functional testing while under unusually heavy loads, heavy repetition
of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
Performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance'
testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the
targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other
techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.
Recovery testing - testing how well a system recovers from crashes, hardware failures, or other
catastrophic problems.
Security testing - testing how well the system protects against unauthorized internal or external access,
willful damage, etc; may require sophisticated testing techniques.
Compatibility testing - testing how well software performs in a particular hardware/software/operating
system/network/etc. environment.
Exploratory testing - often taken to mean a creative, informal software test that is not based on formal
test plans or test cases; testers may be learning the software as they test it.
Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant
understanding of the software before testing it.
User acceptance testing - determining if software is satisfactory to an end-user or customer.
Comparison testing - comparing software weaknesses and strengths to competing products.
Alpha testing - testing of an application when development is nearing completion; minor design changes
may still be made as a result of such testing. Typically done by end-users or others, not by programmers
or testers.
Beta testing - testing when development and testing are essentially completed and final bugs and problems
need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately
introducing various code changes ('bugs') and retesting with the original test data/cases to determine if
the 'bugs' are detected. Proper implementation requires large computational resources.
A. Black box testing - not based on any knowledge of internal design or code.
Tests are based on requirements and functionality.
White box testing - based on knowledge of the internal logic of an application's code.
Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing - the most 'micro' scale of testing; to test particular functions or code modules.
Typically done by the programmer and not by testers, as it requires detailed knowledge of the
internal program design and code. Not always easily done unless the application has a well-designed
architecture with tight code; may require developing test driver modules or test harnesses.
Incremental integration testing - continuous testing of an application as new functionality is added;
requires that various aspects of an application's functionality be independent enough to work separately
before all parts of the program are completed, or that test drivers be developed as needed; done by
programmers or by testers.
Integration testing - testing of combined parts of an application to determine if they function together
correctly. The 'parts' can be code modules, individual applications, client and server applications on a
network, etc. This type of testing is especially relevant to client/server and distributed systems.
Functional testing - black-box type testing geared to functional requirements of an application; this type
of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their
code works before releasing it (which of course applies to any stage of testing.)
System testing - black-box type testing that is based on overall requirements specifications; covers all
combined parts of a system.
End-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of
a complete application environment in a situation that mimics real-world use, such as interacting with
a database, using network communications, or interacting with other hardware, applications, or systems
if appropriate.
Sanity testing - typically an initial testing effort to determine if a new software version is performing
well enough to accept it for a major testing effort. For example, if the new software is crashing systems
every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a
'sane' enough condition to warrant further testing in its current state.
Regression testing - re-testing after fixes or modifications of the software or its environment.
It can be difficult to determine how much re-testing is needed, especially near the end of the
development cycle. Automated testing tools can be especially useful for this type of testing.
Acceptance testing - final testing based on specifications of the end-user or customer, or based on use
by end-users/customers over some limited period of time.
Load testing - testing an application under heavy loads, such as testing of a web site under a range of
loads to determine at what point the system's response time degrades or fails.
Stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to
describe such tests as system functional testing while under unusually heavy loads, heavy repetition
of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
Performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance'
testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the
targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other
techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.
Recovery testing - testing how well a system recovers from crashes, hardware failures, or other
catastrophic problems.
Security testing - testing how well the system protects against unauthorized internal or external access,
willful damage, etc; may require sophisticated testing techniques.
Compatibility testing - testing how well software performs in a particular hardware/software/operating
system/network/etc. environment.
Exploratory testing - often taken to mean a creative, informal software test that is not based on formal
test plans or test cases; testers may be learning the software as they test it.
Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant
understanding of the software before testing it.
User acceptance testing - determining if software is satisfactory to an end-user or customer.
Comparison testing - comparing software weaknesses and strengths to competing products.
Alpha testing - testing of an application when development is nearing completion; minor design changes
may still be made as a result of such testing. Typically done by end-users or others, not by programmers
or testers.
Beta testing - testing when development and testing are essentially completed and final bugs and problems
need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately
introducing various code changes ('bugs') and retesting with the original test data/cases to determine if
the 'bugs' are detected. Proper implementation requires large computational resources.
What is Erlang?
1. Erlang:
$ dimensionless quantity
$ continuous use of one circuit for one hour.
$ Types of Erlang traffic model:
i. Erlang B
This is the most commonly used traffic model, and is used to work out how many lines are
required if the traffic figure (in Erlangs) during the busiest hour is known. The model
assumes that all blocked calls are immediately cleared.
NOTE: Blocked Calls - call which are not successful due to busy traffic (busy signal)
ii. Extended Erlang B
This model is similar to Erlang B, but takes into account that a percentage of calls are
immediately represented to the system if they encounter blocking (a busy signal). The retry
percentage can be specified.
iii. Erlang C
This model assumes that all blocked calls stay in the system until they can be handled.
This model can be applied to the design of call center staffing arrangements where, if calls
cannot be immediately answered, they enter a queue.
2. Holding Time
3. Blocking Rate
$ The probability of blocking calls out of a specified no.
4. CAPS
$ Call Attempts per second
$ CAPS = Erlangs/Holding Time
5. BHCA
$ Busy Hour Call Attempts
$ BHCA = CAPS * 3600
============
= ERLANG B =
============
1. The Erlang B traffic model is used by telephone system designers to estimate the number of lines
required for PSTN connections (CO trunks) or private wire connections. The three variables involved
are Busy Hour Traffic (BHT), Blocking and Lines:
a. Busy Hour Traffic (in Erlangs) is the number of hours of call traffic there are during the
busiest hour of operation of a telephone system.
b. Blocking is the failure of calls due to an insufficient number of lines being available.
E.g. 0.03 mean 3 calls blocked per 100 calls attempted.
c. Lines is the number of lines in a trunk group.
2. If you know two of the figures, you can work out the third as follows:
a. Click on the Unknown radio button representing the unknown variable.
b. Enter the 2 known figures into their edit boxes.
c. Press Calc and the third figure will be calculated and displayed in the remaining edit box.
3. For example, if from your call logger, you know that the Busy Hour Traffic is 10 Erlangs, and you
want to know how many lines are required in this trunk group if you are prepared to tolerate 2 calls
being blocked in every 100 calls attempted then:
a. Press the Lines Unknown radio button (this is selected by default).
b. Enter 10 in the BHT edit box.
c. Enter 0.02 in the Blocking edit box.
d. When you press the Calc button, 17 will be displayed in the Lines edit box indicating that 17 lines would be required in this trunk group.
$ dimensionless quantity
$ continuous use of one circuit for one hour.
$ Types of Erlang traffic model:
i. Erlang B
This is the most commonly used traffic model, and is used to work out how many lines are
required if the traffic figure (in Erlangs) during the busiest hour is known. The model
assumes that all blocked calls are immediately cleared.
NOTE: Blocked Calls - call which are not successful due to busy traffic (busy signal)
ii. Extended Erlang B
This model is similar to Erlang B, but takes into account that a percentage of calls are
immediately represented to the system if they encounter blocking (a busy signal). The retry
percentage can be specified.
iii. Erlang C
This model assumes that all blocked calls stay in the system until they can be handled.
This model can be applied to the design of call center staffing arrangements where, if calls
cannot be immediately answered, they enter a queue.
2. Holding Time
3. Blocking Rate
$ The probability of blocking calls out of a specified no.
4. CAPS
$ Call Attempts per second
$ CAPS = Erlangs/Holding Time
5. BHCA
$ Busy Hour Call Attempts
$ BHCA = CAPS * 3600
============
= ERLANG B =
============
1. The Erlang B traffic model is used by telephone system designers to estimate the number of lines
required for PSTN connections (CO trunks) or private wire connections. The three variables involved
are Busy Hour Traffic (BHT), Blocking and Lines:
a. Busy Hour Traffic (in Erlangs) is the number of hours of call traffic there are during the
busiest hour of operation of a telephone system.
b. Blocking is the failure of calls due to an insufficient number of lines being available.
E.g. 0.03 mean 3 calls blocked per 100 calls attempted.
c. Lines is the number of lines in a trunk group.
2. If you know two of the figures, you can work out the third as follows:
a. Click on the Unknown radio button representing the unknown variable.
b. Enter the 2 known figures into their edit boxes.
c. Press Calc and the third figure will be calculated and displayed in the remaining edit box.
3. For example, if from your call logger, you know that the Busy Hour Traffic is 10 Erlangs, and you
want to know how many lines are required in this trunk group if you are prepared to tolerate 2 calls
being blocked in every 100 calls attempted then:
a. Press the Lines Unknown radio button (this is selected by default).
b. Enter 10 in the BHT edit box.
c. Enter 0.02 in the Blocking edit box.
d. When you press the Calc button, 17 will be displayed in the Lines edit box indicating that 17 lines would be required in this trunk group.
Friday, August 21, 2009
Code Allocation in UMTS
Code Allocation:
Channelization codes, also called Spreading codes, satisfy two purpose: first, to spread the signal energy evenly over the bandwidth below the noise level ; and second, to separate the transmissions from a single source. These are based on the Orthogonal Variable Spreading Factor (OVSF) technique. Orthogonal codes are the codes that have the property that any two codes in the family, except for those that are connected to it and to the right, when multiplied together bitwise and the results of these multiplication are summed, the result is zero. That is, in mathematical way, codes in the family correlated completely with themselves and have zero crosscorrelation with any of the other codes. However, the zero crosscorrelation property of orthogonal codes works only if the codes are time aligned.
In Uplink, channelization codes are used to distinguish data and control channels from the same UE.
In Downlink, channelization codes are used to distinguish signals for different channels and users within a cell.
Scrambling codes, also called PN scrambling codes, are used to separate users and different base stations. They are used on top of spreading and it does not change the signal bandwidth. Also, scrambling codes are found to have better crosscorrelation property as compared to channelization codes even when codes are not time aligned. PN sequence or Pseudorandom number sequence is a sequence of numbers, algorithmically generated, that are distributed evenly throughout the number space but with no discernible pattern to their distribution.
In Uplink, scrambling codes are used to distinguish UE terminals.
In Downlink, scrambling codes are used to distinguish different cells.
ImportantInformation:
- Each signal is spread with the spreading code, i.e. channelization code x scrambling code
- Uplink codes are not cell specific. Channelization Code is picked by mobile and Scrambling code assigned by RNC. They can be decoded anywhere
- Downlink code is cell specific and UE must decode each of them individually
In Downlink, channelization codes are used to distinguish signals for different channels and users within a cell.
Scrambling codes, also called PN scrambling codes, are used to separate users and different base stations. They are used on top of spreading and it does not change the signal bandwidth. Also, scrambling codes are found to have better crosscorrelation property as compared to channelization codes even when codes are not time aligned. PN sequence or Pseudorandom number sequence is a sequence of numbers, algorithmically generated, that are distributed evenly throughout the number space but with no discernible pattern to their distribution.
In Uplink, scrambling codes are used to distinguish UE terminals.
In Downlink, scrambling codes are used to distinguish different cells.
ImportantInformation:
- Each signal is spread with the spreading code, i.e. channelization code x scrambling code
- Uplink codes are not cell specific. Channelization Code is picked by mobile and Scrambling code assigned by RNC. They can be decoded anywhere
- Downlink code is cell specific and UE must decode each of them individually
Wednesday, August 19, 2009
Power Control in UMTS
Power control is necessary to keep the transmitted signal power level under control so as to minimize the interference and keep the quality of signal to a desired level. The main functions are:
1. Closed-loop power control
· Outer-loop power control
- Uplink outer-loop power control
- Downlink outer-loop power control
· Inner-loop power control
- Uplink inner-loop power control
- Downlink inner-loop power control
2. Open-loop power control
· Uplink open-loop power control
· Downlink open-loop power control
Closed-loop power control is the power control mechanism used in UMTS to solve near-far problem, minimize interference and to keep the signal quality to optimum level. Closed-loop power control is used in uplink (UL) as well as downlink (DL). However, the motive in both the cases are different. In uplink, signals from different UEs reach NodeB with different power strength, thus causing the stronger signal blocking the weaker one, resulting in near-far effect. In downlink, there is no near-far effect, but the UEs near the cell-edge or in high interference region may need extra power to overcome the increased other cell interference and weak signal due to Rayleigh fading.
Closed-loop power control can be divided into outer-loop and inner-loop power control. In case of uplink, the RNC manages the outer-loop and Node B manages the inner-loop and for downlink, UE manages the outer-loop and Node B manages the inner-loop.
Inner-loop power control (also called fast closed-loop power control), operates at 1500 times per sec (1.5 kHz) [From where did this value of 1.5 kHz come from? Answer: A UMTS 10 ms frame consists of 15 TPC commands. This results in a power control frequency of 1500 Hz (15/10ms)] and relies on the feedback information from the opposite end of the link (or channel) to maintain the signal to interference (noise) ratio to a target level set by the outer-loop power control. The transmission power is increased or decreased by a certain fixed step size depending on whether the received SIR is below or above the target SIR. Precise power control can lead to optimum use of bandwidth resulting in increase cell capacity.
The UL inner-loop power control lets the UE adjust its output power in accordance with one or more TPC commands received in the downlink direction. Remember the increase and decrease in power is limited by upper and lower bounds as defined in 3GPP TS 25.101. The upper bound, i.e. UE maximum output power, is set depending on the Power class of UE. This can also be set below the maximum capability of the UE through signaling when the link is established. The lower bound, i.e. UE minimum output power defined as the mean power in one timeslot (TS), and shall be less than -50 dB.
The DL inner-loop power control is used to control the transmission power of downlink channels at Node B as per the TPC commands received from UE. However, in some situations Node B may ignore the increase/decrease these TPC commands. For example, in case of congestion (high load scenario), the Node B can ignore the TPC commands from UE.
Outer-loop power control is used to set the target quality value for inner-loop power control, i.e it adjusts the target SIR in Node B which is used during inner-loop power control. Now the question is why do we need to adjust the target SIR? Outer-loop power control tries to keep the quality of a connection to desired value. Too high quality will waste the resources.
Open-loop power control is used to set the initial power of UE (in random access) and downlink channels. The TPC commands used in inner-loop power control are relative, so it needs a starting point and this is defined by open-loop power control. Also, this is useful in setting the power level in case of common shared channels, where it is difficult to send each UE the necessary TPC commands. In case of uplink, UE and broadcasted cell/system parameters are used to set initial access power on RACH. And in case of downlink, the measurement report of UE is used to set the initial power of downlink channels.
The open loop power control tolerance is ±9dB under normal conditions and ±12dB under extreme conditions.
[References: TS 25.214, TS 25.215, Section 7.2.4.8 of TS 25.401]
Friday, August 14, 2009
Thursday, August 13, 2009
What are the main differences between LAPD and LAPDm in GSM?
LAPDm stands for Link Access Procedure on D channel (modified). This is a modified version of LAPD and is optimized for the GSM Air interface.
This is done in order to judiciously use the scarce radio resource. Some parts of LAPD frame are removed to save the resources. Some differences are:
1. In LAPDm, checksum is not used, as channel coding on layer 1 takes care of it(for error identification and correction).
2. In LAPDm, some of layer 2 control frames, viz. SABM and UA frames carry layer 3 information.
3. LAPDm does not support extended header formats.
4. LAPDm frames (one LAPDm frame carry a maximum of 23 octets) are shorter than LAPD frames (one LAPD frame carry a maximum of 260 octets).
This is done in order to judiciously use the scarce radio resource. Some parts of LAPD frame are removed to save the resources. Some differences are:
1. In LAPDm, checksum is not used, as channel coding on layer 1 takes care of it(for error identification and correction).
2. In LAPDm, some of layer 2 control frames, viz. SABM and UA frames carry layer 3 information.
3. LAPDm does not support extended header formats.
4. LAPDm frames (one LAPDm frame carry a maximum of 23 octets) are shorter than LAPD frames (one LAPD frame carry a maximum of 260 octets).
Subscribe to:
Posts (Atom)
View Pankaj Kumar's profile