Software testing FAQ

Welcome to Software Testing Help!

What is software Testing? A basic to start with:
Software testing is the process used to help identify the correctness, completeness, security, and quality of developed computer software.

Testing is a process of technical investigation, performed on behalf of stakeholders, that is intended to reveal quality-related information about the product with respect to the context in which it is intended to operate.

This includes, but is not limited to, the process of executing a program or application with the intent of finding errors. Quality is not an absolute; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behaviour of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of software quality assurance, which encompasses all business process areas, not just testing.


There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation, not merely a matter of creating and following routine procedure. One definition of testing is “the process of questioning a product in order to evaluate it”, where the “questions” are operations the tester attempts to execute with the product, and the product answers with its behavior in reaction to the probing of the tester.

Although most of the intellectual processes of testing are nearly identical to that of review or inspection, the word testing is connoted to mean the dynamic analysis of the product—putting the product through its paces. The quality of the application can, and normally does, vary widely from system to system but some of the common quality attributes include capability, reliability, efficiency, portability, maintainability, compatibility and usability. A good test is sometimes described as one which reveals an error; however, more recent thinking suggests that a good test is one which reveals information of interest to someone who matters within the project community.

Recommended reading


#1 Hanks

Nice to start with software testing

#2 Swati

would like to know stub & driver

#3 seetha

We will be using stubs abd drivers in intergration testing (bottom up and top down testing)
while we are testing a applciation by intergrating two or modules together, during that if we face any issue so that we are unable to continue testing say top to bottom/bottom to top, during this time you can include drivers/stubs as temprorary program from developers an dcontinue testing.

Once application has been developed completely these drivers and stubs can be removed for system testing

#4 manoj kumar

hi everybody. anybody pls send me sample test cases of any application.

#5 manoj kumar

what is the difference between smoke test and sanity test???????????

#6 suman

Hello eerybody,
i would like to know about testdata with example

#7 Miffy

I would like to know about stubs.

#8 Harnitha

This website is a very good collection regarding the testing. I am a fresher searching a job on Testing.

Thanks a lot.

#9 Saraswathi

Thanks, this is really a good site. I learned lot of things in this web site.

#10 neeharika

This website has a good collection of articles on testing. This informations will be very useful.
Thanks a lot for providing such a good stuff.

#11 Abhijit Deshmukh

I would like to subscribe the latetst news and comments on this forum.

#12 RahulKumar

Test Data–Data that exist b4 the execution of test and/or exist in the database .Test data may change upon execution of Test Cases
suppose we have an edit box which accept 4 integer only then test data are 1,11,323,4545,454545,0,like that
suppose we are inserting some into text box which enters records to database then in this case test data is getting modified..

#13 john

testing is defined as process in which the defects is identify,isolated,subjected for rectification and ensure that the productis defect free in order to provided a good quality to the product and that must satisfy the customer requirements

#14 Beena


#15 sharmi

Stubs and Drivers are dummy modules used in integration testing
Stubs – Stubs are mainly used in Top-Down intergration testing apporach, which is used to replace the low level modules. Stubs usually dont perform any actions. They may just display the meggase that they are called.

Drivers – Drivers are used in Bottom – Up integration testing approach, which will replace high level modules. They usually perform some actions like, calling a low level module or passing a value. These Drivers usually replace High level modules, which are still under development. So these dummy modules will help to drive testing so they are called as drivers.

#16 padmashree


#17 padmashree


#18 ramesh

Very………………………………..helpful for me

#19 ramesh

what is Automation Frame Work

#20 Beena


#21 vipin

A test automation framework is a set of assumptions,
concepts, and practices that provide support for automated
software testing. This article describes and demonstrates
five basic frameworks.

There is no hard and fast rule to use a specific Automation
frame work. It all depends on your project needs, here are
some info on the same.

Data Driven approach is suitable for applications that have
limited functionality but large number of variations in
terms of test data.

Functional Framework is suitable for applications that have
variety of functionality but limited variations in terms of
test data.

Hybrid Test Automation Framework is suitable for
applications that have variety of functionality and larger
number of variations in terms of test data.

Record, enhance and play back methodology is suitable to
convert small to medium size manual scripts into equivalent
automation scripts – one to one basis.

#22 Inder P Singh

Thanks for the post!

#23 SteStuff-Everything That A Test Engineer Needs..!

Great start..!

#24 Deepti

can anybody clarify the difference b/w verification and validation.

#25 Govardhan Reddy M

Dear Ms.Deepti (#24),

Verification: Whether we build the project right?

Validation: Whether we build the right project?


Verification: Inspections, Walk throughs (Process)

Validation: Actual Testing (Whether the application is performing as expected).

Govardhan Reddy M,
Software Test Engineer,
“Law of win says, Lets not do it in my way or your way, But lets do it in the best way”.

#26 penisetty

good… still go for more depth… in the subject..

I feel not so bad..

#27 pavan

i am pavn
This website has a good collection of articles on testing. This informations will be very useful.
Thanks a lot for providing such a good stuff.

Please let me know if any openings on testing. … If you people know any openings on MANUAL TESTING plz inform me on

#28 Subbarao

Wt r the ways of testing a tester.
I mean Developer release a build with an issue to find the tester performance. What is this testing type

#29 Usha

Hi Friends,

What is penatration testing? I am not aware of this.

Can you please explain about this?


#30 H@san

Hi friends Please include me in your loop so that we may discuss the real time Interview question

#31 sujata

its good for me

#32 sujata

plz give me list of type of testing, techniques,level of testing,methodology.

#33 boopathi

could you please advise me what are basic certification has to do for software testing?

#34 ashwini

Can anyone tell me detail difference between verification and validation.

#35 Sridhar.T

Hi Ashwini

verification is checking weather all requirements are covered or not in application in terms of functionalities.

validation is checking the implemented futures(functionalities) are working or not as per expectations.

#36 Moh

can we detect the stub or the driver in integration test automatically(by using tool or special library), what I mean is if we have an integration test can we identify who was the caller and who was the callee, since in an integration test we are testing at least two components.

#37 Vishal N. Metkar

• miscommunication or no communication – as to specifics of what an application should or shouldn’t do (the application’s requirements).
• software complexity – the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Multi-tier distributed systems, applications utilizing multiple local and remote web services applications, data communications, enormous relational databases, security complexities, and sheer size of applications have all contributed to the exponential growth in software/system complexity.
• programming errors – programmers, like anyone else, can make mistakes.
• changing requirements (whether documented or undocumented) – the end-user may not understand the effects of changes, or may understand and request them anyway – redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of coordinating changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control – see’What can be done if requirements are changing continuously?’ in the LFAQ. Also see information about ‘agile’ approaches such as XP, in Part 2 of the FAQ.
• time pressures – scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.
• poorly documented code – it’s tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it’s usually the opposite: they get points mostly for quickly turning out code, and there’s job security if nobody else can understand it (‘if it was hard to write, it should be hard to read’).
• software development tools – visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs

#38 Vishal N. Metkar

What is verification? validation?
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. The term ‘IV & V’ refers to Independent Verification and Validation

Leave a Comment