What is the advantage of running the virtual user as thread?

VuGen provides the facility to use multithreading. This enables more virtual user to be run per generator. If the Vuser is run as a process, the same driver program is loaded into memory for each Vuser, thus taking up a large amount of memory. This limits the number of virtual user that can be run on a single generator. If the Vuser is run as a thread, only one instance of the driver program is loaded into memory for the given number of virtual user (say 100). Each thread shares the memory of the parent driver program, thus enabling more virtual user to be run per generator

Regarding testing techniques in the field of space research

mmmmmmmmmm, really a different !!!!!!!!!! see we can test operations on different temprature conditions,and we can test it in minus gravitational force. We can test it further by giving different virus(!!) to it. Virus means infected programs that may cause severe damage,atleast there will be such chance in some % atleast.We can do adhoc testing 2 test operation so that we get to know,how they work in chaotic condiotions.By giving stress we can get to know the exactly that what system do exactly??

DbFit 0.92: Better error reporting and easier regression tests

A new release of DbFit is available for download from SourceForge (http://sourceforge. net/project/ showfiles. php?group_ id=191053& package_id= 224326&release_ id=556930).

DbFit is a free extension library for FIT/FitNesse testing framework. It allows developers to manipulate database objects in a relational style, making it much easier to manage and test database objects than with xUnit-style tests. DbFit supports .NET and Java integration tests, and Oracle, SQL Server and MySQL database engines.

Release 0.92 (2007-11-26) brings:

- Better error handling, DbFit now prints out missing column/parameter names and warns if table/procedure could not be found new Inspect fixture to help with regression tests: DatabaseTest has three methods to automate it: InspectQuery, InspectProcedure and InspectTable. These methods will quickly print out entire query results, structure of a procedure or a table/view in a form that can be easily converted to a regression test, or used as a template for
ExecuteProcedure, Insert or Update tables. support for Oracle procedure and package synonyms Type details are read from SqlServer in a more efficient way,
supporting objects with dots in names and fixing few edge cases where
duplicate records were retrieved with 0.91 null keyword handled correctly in Java

For more information on DbFit, see http://gojko. net/fitnesse/ dbfit

QA Time Estimation

There are a great many people who will tell you there is a "standard" ratio of QA hours to Development hours. Don't listen to them. Anyone who makes that claim probably does not know what they are talking about.

Take for example the difference between implementing a new desktop application for internal use and implementing a new web app that is available to the general public.

In the first case, you have to verify that the application works on 1 machine configuration (the weakest CPU/Memory combination with the supported OS in your company), Security testing is restricted to making sure that the user roles are configured (if you even have role based security, there might not need to be any security testing on an internal app). Depending on a myriad of factors the QA hours for a project like this could range anywhere between 30% and 120% of the dev hours.

In the second case you need to verify that the app works on somewhere between 5 and 50 different OS/Browser combinations with several different Hardware configurations thrown in for good measure plus you now need to start throwing in web security testing where you have someone who knows what they are doing validate that your site is protected at least against the most common hacker attacks. Again depending on other factors for a project like this the QA/Dev hour ratio could be anywhere from 2/3 (66%) to 2.5/1 (250%).

This is just looking at the differences between 2 different types of new applications, some other factors that 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)


And I am sure there are several dozen more than I'm not thinking of off the top of my head. I have seen projects the ratio of QA hours to dev hours was as little as 1/10 (10%) and as high as 5/1 (500%) .


Now what you can do is over time develop a set of standard ratios for different types of projects at your company. You do this by first accurately measuring your projects for a year or two, then going back, finding reasonable groupings of similar projects and deriving average ratios between the two sets of time then when the next project comes up you can do a relatively simple analysis of which type of project it was most like and use that average in planning. If you do this you also need to keep measuring all future projects to ensure that the averages hold and do not drift too far over time

Approve or disapprove the release

The same situation mostly happens with most of us. I think the most important thing here is QA setup similar to Production environment. This is the right time to highlight the risk factors which can cause the release unsuccessful b/c of unavailability of proper testing environment. This is only one side which can be seen this time, that you can't test the email sending at the time of order placement. What about in next requirement list or wish list, if an other option is require by user which also contain this auto email sending option. What you will do next time?

If the testing environment can't be setup as production environment
Sit with your project management team (top players)...keep the situation in front of them...get the things document (not only risk factors but your suggestion also)....discuss with them....confirm more about white box testing and/or unit testing for complete order placement code...give your standing and take the mutual decision.... and document them against your (QA) response.

Its definitely better to get things document b/c this can only be your evidence if things goes worse. With my experience I always try t

Test Execution Estimates

Even though you can not estimate exactly, but you can estimate the execution time efforts depending on the Function Points in your Test Cases.

You will have to categorize your test cases in 3 different categories e.g. Critical / Major / Minor and then can check timing for 5 test cases from each group. Take average of that and multiply with number of test cases in respective groups.

This will not give you exact estimate, but it will definitely give estimate near to actual time.

I have tried this in my past projects and could successfully delviered my product within given time frame.

I will also recommend to add 10 to 15 % extra time, so that if you get stuck some where or considering some obstacles in testing, you can deliver product within your estimated time.

QA Time vs. Development Time

Well, if this was an interview question, maybe the interviewer was looking to find out how you would think through the problem. As was stated by the moderator and others, there really isn’t a good formula. Different groups have different methods/processes/ tools/models by which they arrive at their estimates. I think it’s safe to make a statement that those methods/processes/ tools/models take into consideration some of the variables that are outlined below.

Specifically speaking to the models, they should be reviewed periodically based on historical data to see if there are updates that are required. In my current organization, one of the items on our plates is to revisit our current estimation model. We’ve got our first release under our belts and are part way through our second release. We have some data to begin refining our estimation model. This will be an ongoing process where the model is periodically reviewed and updated.

Getting back to the original question, if this was an interview question, then you might want to explore an answer within the context of your current role and explain to the interviewer that this is the context in which you’re answering your question.

Just a different way to explore it

There is no formula.There are too many variables: the maturity of the product, the quality of the developers' work, the skill of the developers, the skill of the
testers, development and test environments, etc.. In the end, there is no formula based on developers' time