Wednesday, January 28, 2009

LoadRunner FAQ

1. What is load testing?
Ans. Load testing is to test that if the application works fine with the loads that result from large number of simultaneous users, transactions and to determine weather it can handle peak usage periods.

2. What is Performance testing?
Ans. Timing for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable timeframe. This should be done standalone and then in a multi user environment to determine the effect of multiple transactions on the timing of a single transaction.

3. Explain the Load testing process?
Ans. Following are the steps involved in the Load testing process:

Step 1: Planning the test - Here, we develop a clearly defined test plan to ensure the test scenarios we develop will accomplish load-testing objectives.

Step 2: Creating Vusers - Here, we create Vuser scripts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions.

Step 3: Creating the scenario - scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. We create scenarios using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.

Step 4: Running the scenario - We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.

Step 5: Monitoring the scenario - We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.

Step 6: Analyzing test results - During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner’s graphs and reports to analyze the application’s performance.

4. When do you do load and performance Testing?
Ans. We perform load testing once we are done with interface (GUI) testing. Modern system architectures are large and complex. Whereas single user testing primarily on functionality and user interface of a system component, application testing focuses on performance and reliability of an entire system. For example, a typical application-testing scenario might depict 1000 users logging in simultaneously to a system. This gives rise to issues such as what is the response time of the system, does it crash, will it go with different software applications and platforms, can it hold so many hundreds and thousands of users, etc. This is when we set do load and performance testing.

5. What are the components of LoadRunner?
Ans. The components of LoadRunner are The Virtual User Generator, Controller, and the Agent process, LoadRunner Analysis and Monitoring, LoadRunner Books Online.

Thursday, January 15, 2009

Bug Severity Criteria

Richard Martin
Experienced Software Developer and Quality Engineering Manager

I tend to use a pretty standard definition.
Severity
---------------
1. Bug causes system crash or data loss.
2. Bug causes major functionality or other severe problems; product crashes in obscure cases.
3. Bug causes minor functionality problems, may affect "fit anf finish".
4. Bug contains typos, unclear wording or error messages in low visibility fields.

Priority
---------------
1. Must fix as soon as possible. Bug is blocking further progress in this area.
2. Should fix soon, before product release.
3. Fix if time; somewhat trivial. May be postponed.
Posted 1 day ago

Andrey Konushin
President at RSTQB
We use the following severity classification for some years already:

0. Customer Bug (Can be found only at customer's side)
- Any defect found by end user/customer in the release of the product.

1. Critical
- Inaccessible system functionality (user cannot perform the job), no workaround to perform the job;
- Application cannot run (buzzing);
- OS automatically closes the application;
- System security violation.
2. Major
- Inaccessible system functionality but workaround accessible;
- Unhandled exception.
3. Average
- System error message (handled exception).
4. Minor
- Non-business logic defect (defect of little significant that not leads to corruption or loss user data);
- Application GUI defect.

Defect priority:
1- Resolve immediately;
2- Give high attention;
3- Normal queue;
4- Low priority.
Posted 1 day ago
Martin Orlando
Senior QA Engineer
We used two fields for priority – when creating a bug, the Original priority field is filled in, and the Assigned priority is copied. After review by QA and/or Dev management – the Assigned priority field can be modified. When designing a bug writing course, I suggested that within the contents of the bug, you should describe why you are assigning it a certain priority.

Here are the priority levels:

Urgent – The complete inability to use the product at all on multiple platforms. The product cannot ship on any platform with any Urgent open issues. Urgent issues would result in a customer call to support. Unable to install or use the product at all fall into Urgent issues.

High – An issue that greatly affects the product, but is limited to specific platforms. System crashes, memory leaks or other major problems that would be found in normal, everyday activity. Cannot ship the product on a given platform with a High open issue. High issues would result in a customer call to support.

Medium – An issue that occurs at an extreme boundary condition and not likely to be found with normal use of the product. Medium bugs should not generate support calls, but may be seen as more annoying.

Low – Cosmetic bug that doesn’t affect end usability. Low bugs will not generate support calls.


Along with priority - we have a menu driven field called Blocking Status. If the issue is considered to be blocking someone from doing and/or completing their job this field is used to raise the fixing priority.

Some of the blocking
QA
Applications
Support
Customer

Along with that, there are some binary fields used:

Regression Status: - Setting to Yes means that this issue was found/fixed or working with a previous version and is now not working.

Repeatable: Some issues can be timing related – so if you ran the test several times, but were not able to repeat the result every time, set this to no…

There is also a field that Development used to assign the fix order priority – so if an engineer has 10 High bugs assigned, they can see which ones that management wanted them to fix first.
Posted 1 day ago

Brian Masinick
Project Manager at Fidelity Investments
The categorizations provided by Richard, Andrey, and Martin are quite common, based on what I have seen on a variety of projects across multiple businesses and industries. Priority, severity, reproducibility, and whether the defect has a work around or if it is a show stopper are among the factors that I have seen present in most defect tracking systems.

In my current job, most of the organizations use a common severity code system, where a Sev. 1 issue matches the Critical category mentioned by Andrey and the Urgent priority mentioned by Martin. Sev. 1 issues are tracked by senior management and they require an open network bridge to keep all interested parties informed of the current status and the steps being taken to resolve the issue.

Once there is at least a workaround, a Sev. 1 defect can be lowered to the next category, Sev. 2, which represents major defects, but where there does exist a work around.

Sev. 3 issues represent a significant defect, but there are work arounds available, potential alternatives, and there is no imminent business impact.

Sev. 4 issues represent minor issues that do not meet the functional requirements completely.

All of these categorizations contain elements that have been discussed in each of the previous set of comments.
Posted 1 day ago
Diane Miller
Sr. QA Analyst Consultant
For the most part I've worked under the same guidelines as Richard describes, and if the priority was anything over a 2, it never got fixed and we got to deal with it with every release.

In the bug review meetings, many times the developer would assign the priority but the QA lead would give the prospective of the QA team. The managers had the last word. And it would greatly depend on who the manager was and what the product was. If the product was likely to go in great numbers to 1 particular customer to where the customer would likely see the issue multiple times over their order, the priority would go up. If the product was likely to go out in one or two unit orders, the priority would go down.

Diane
Posted 1 day ago

Martin Orlando
Senior QA Engineer
It is rather funny - you will find a medium level bug that gets closed as being "as designed" with no actual fix involved - then the product goes to a Beta site and a Beta user complains about the same thing...and suddenly it is priority number 1 and needs to be fixed yesterday, with the question of "Why didn't you find that one?" comes up.
Posted 23 hours ago
Diane Miller
Sr. QA Analyst Consultant
Quote>>It is rather funny - you will find a medium level bug that gets closed as being "as designed" with no actual fix involved - then the product goes to a Beta site and a Beta user complains about the same thing...and suddenly it is priority number 1 and needs to be fixed yesterday, with the question of "Why didn't you find that one?" comes up

That's why even as designed or previously defined bugs get documented every time, to cover yourself from those type of questions.


Diane
Posted 21 hours ago
Fin Nugent
ICT Professional
Yshai - Are you looking for bug priority & severity criteria for a specific phase of testing or a "catch-all" set of definitions for all phases in the SDLC? I ask because what may be relevant for Unit Test may not necessarily suit for Business Acceptance Test, for example. Feel free to contact me to dicscuus your exact requirements.
Posted 20 hours ago
Richard Martin
Experienced Software Developer and Quality Engineering Manager
Diane raises a good point but I didn't think we were covering defect management here; just the classification based on severity & priority. There is a constant need to re-prioritize the bug backlog. At one company, when we scheduled minor releases we would set aside a fixed level of effort, say 20% of the release to address the backlog. If the backlog grew too high, we would adjust the % of effort up. The bugs scheduled in as part of the work-down of the backlog were selected in large part by the customer support and field service staff with input from QA.
Posted 19 hours ago
Shai Nadel
QA TEAM LEADER in Nice Systems
we use set two separate categories one is the Bug severity decided by the QA according to the following standards:
Low
* GUI ‘cosmetics’
* General minor issues
Medium
* Missing\wrong messages
* Not perfect functionality
* GUI friendliness
* GUI - Spelling errors
* Documentation errors
High
* Feature malfunction
* ‘Bad’ errors messages
* Fields validation
* Translation problems
* Missing Install Shied
* Missing documentation
* Wrong version
Show Stopper
* System\Component Crash
* Data loss
* Missing Feature
* Security intrusion
* Performance failures
* Customer determination
QA Stopper
* Stops Testing progress
================================
Next is Bug Priority which is determined according to the urgency of the fix in respect to the related costumer
Posted 9 hours ago
Fin Nugent
ICT Professional
Yshai:

I would generally expect that there would be some bug threshold-levels set in the exit criteria for was test phase.
For example, the Acceptance Test exit criteria would state that the following maximum level of bugs would be acceptable to exit the test phase:
Severity 1 - 0
Severity 2 - 5
Severity 3 - 10
Severity 4 - 25

The Severity definitions already provided by Richard in the first reply above would be those that I would generally use myself. The Priority applied to each bug should be reviewed on a regular basis between the Test Manager & the Development Manager. The PM being called upon to mediate in any disputed bug priorities

Tuesday, January 13, 2009

SQL Interview questions

How would you find out the total number of rows in a table?
Use SELECT COUNT(*) … in query

How do you eliminate duplicate values in SELECT?
Use SELECT DISTINCT … in SQL query

How you insert records into a table
Using SQL INSERT statement

How do you delete record from a table?
Using DELETE statement
Example : DELETE FROM EMP

How do you select a row using indexes?
Specify the indexed columns in the WHERE clause of query.

How do you find the maximum value in a column?
Use SELECT MAX(…) .. in query

How do you retrieve the first 5 characters of FIRSTNAME column of table EMP ?
SELECT SUBSTR(FIRSTNAME,1,5) FROM EMP

My SQL statement SELECT AVG(SALARY) FROM EMP yields inaccurate results. Why?
Because SALARY is not declared to have NULLs and the employees for whom the salary is not known are also counted.

How do you concatenate the FIRSTNAME and LASTNAME from EMP table to give a complete name?
SELECT FIRSTNAME || ‘ ‘ || LASTNAME FROM EMP

What is UNION,UNION ALL in SQL?
UNION : eliminates duplicates
UNION ALL: retains duplicates
Both these are used to combine the results of different SELECT statements.

Suppose I have five SQL SELECT statements connected by UNION/UNION ALL, how many times should I specify UNION to eliminate the duplicate rows?
Once.

In the WHERE clause what is BETWEEN and IN?
BETWEEN supplies a range of values while IN supplies a list of values.

Is BETWEEN inclusive of the range values specified?
Yes.

What is ‘LIKE’ used for in WHERE clause? What are the wildcard characters?
LIKE is used for partial string matches. ‘%’ ( for a string of any character ) and ‘_’ (for any single character ) are the two wild card characters.

When do you use a LIKE statement?
To do partial search e.g. to search employee by name, you need not specify the complete name; using LIKE, you can search for partial string matches.

Example SQL : SELECT EMPNO FROM EMP
WHERE EMPNAME LIKE ‘RAMESH%’

% is used to represent remaining all characters in the name.
This query fetches all records contains RAMESH in six characters.

What do you accomplish by GROUP BY … HAVING clause?
GROUP BY partitions the selected rows on the distinct values of the column on which you group by. HAVING selects GROUPs which match the criteria specified

Consider the employee table with column PROJECT nullable. How can you get a list of employees who are not assigned to any project?
SQL : SELECT EMPNO
FROM EMP
WHERE PROJECT IS null;

What are the large objects supported by oracle and db2?
Blob , Clob ( Binary Large Objects, Character Large Objects)

What’s the difference between a primary key and a unique key?
Primary key wont allow nulls, unique key allow nulls. Both Primary key and Unique key enforce the uniqueness of the column on which they are defined.

What is a join and explain different types of joins?
INNER JOIN
OUTER JOIN
LEFT OUTER JOIN
RIGHT OUTER JOIN
FULL OUTER JOIN
INNER JOIN

What is a self join?
Joining two instances of a same table.
Sample SQL : SELECT A.EMPNAME , B.EMPNAME
FROM EMP A, EMP B
WHERE A.MGRID = B.EMPID

What is a transaction and ACID?
Transaction - A transaction is a logical unit of work. All steps must be committed or rolled back.
ACID - Atomicity, Consistency, Isolation and Durability, these are properties of a transaction.

Materialized Query Tables in db2 ( This feature might not be available in oracle)?
Materialized Query Tables or MQTs are also known as automatic summary tables. A materialized query table (MQT) is a table whose definition is based upon the result of a query. The data that is contained in an MQT is derived from one or more tables on which the materialized query table definition is based. MQT improve the query performance.

Sample SQL to creat MQT.
CREATE TABLE CUSTOMER_ORDER AS
(SELECT SUM(AMOUNT) AS TOTAL_SUM,
TRANS_DT,
STATUS
FROM DB2INST2.CUSTOMER_ORDER
WHERE TRANS_DT BETWEEN ‘1/1/2001′ AND ‘12/31/2001′
GROUP BY TRANS_DT,
STATUS)
DATA INITIALLY DEFERRED REFRESH DEFERRED;

Monday, January 12, 2009

QA Effert Estimation

I would say that it vary a lot depending on the way the code was done. Depending also on your definition of "done". At Microsoft, they done some testings on whether "done" should be "code complete" or a little more than that. They figured out that it pays a lot doing more testing up-front than later on. That being said... I think that something like 15% analysis, 10% architecture, 50% code, 15% QA and 10% project management / release management etc. would be pretty much accurent.

Some factors includes hardware environment which will influence the QA/Dev hour ratio are:

Maturity of the product,
Quality of the requirements,
Level of domain knowledge of the Dev/Business/ QA team members,
Development model followed (waterfall, agile, etc.),
Breakdown of roles and responsibilities between the teams (different companies have different expectations between Dev and QA) ,
Physical proximity of the Dev/Business/ QA teams (people are more efficient when they work together)
Level of quality needed (Banking and health care industries have much stricter quality requirements than an entertainment application)
Team Sizes (Smaller teams are more efficient than larger ones)
Effectiveness of Change Control Procedures
Scale of the project (Defects increase exponentially with the scale of the project, more defects means more QA time and therefore a higher ratio of QA hrs to dev hrs)
Quality of the Code (The single largest factor)
Quality of Documentation
Availability of test data (only applies to some projects)
Quality of the QA team (actually a much more minor factor than you'd think)

Here are a few rules for effective testing estimation:
Rule 1: Estimation shall be always based on the software requirements
Rule 2: Estimation shall be based on experience of the team
Rule 3: Estimation shall be based on previous projects
Rule 4: Estimation shall be recorded
Rule 5: Estimation shall be supported by tools
Rule 6: Estimation shall always be verified

Testing estimation vs Development time
- simple problems : same as 20-30% of time spent for development
- normal problems : 40-80%
- complex problems : 100-130% (test should start even before devt)
- very complex problems : devt should be done according to tests, and breakdown to smaller problems if possible with robust framework and QA guidelines.

Friday, January 2, 2009

Photo Album of Grand Canyon and US national parks

Photo Album of Grand Canyon and US national parks
Click Grand Canyon