1.what is bugtracking tool ?

A tool used to track the defect/issues/concerns logged by tester. This is very much required in any testing
environment.Some common features of any bug tracking tool allow you to priortize the defects ,keep track of
bug status (like open/close/verified) ,date logged etc..
This is also a Software Application that helps the Test team in end-to-end Defect Life Cycle Management. The
advantage of this tool is that all the stake holders of the Testing Project can keep track of the latest Status of all
the Bugs logged in by the Test team.
Also, it will be help in the following:

1. Defect Categorization based on Priority, Severity.

2. Generating a variety of Bug reports such as Daily & Weekly and also Application wise and Module wise Bug lists.

3. Also the tool can be configured for sending automated mail messages to all the concerned people whenever a
Bug is logged in the tool and change occurs to the same.

4. Some tools have more features such as generating Graphical reports based on the Bug Data.

2.What is the difference between verification and Validation in software testing

Verification ensures the product is designed to deliver all functionality to the customer; it typically involves
reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done
with checklists, issues lists, and walkthroughs and inspection meetings.

Validation ensures that functionality, as defined in requirements, is the intended behavior of the product;
validation typically involves actual testing and takes place after verifications are completed

Verification is a process in which information is checked using accurate measures. E.g. when you enter a new
password you are asked to retype it to verify that the password supplied is correct.

Validation however is the automatic process in which rules are applied in order to make information correct,e.g.
if the right type of data is entered in a certain cell in a database.

3.what do u mean by Testing plan?in software development life...

A software project test plan is a document that describes the objectives, scope, approach, and focus of a
software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed
to validate the acceptability of a software product. The completed document will help people outside the test
group understand the 'why' and 'how' of product validation
For a application or product to be success....testing phase or plan is a must.
Testing plan explains the scope of testing, Objectives, Test strategies(what are the kind of testing to be
conducted to find the bugs), Acceptance Criteria(At what point the testing should be stopped to adhere for the
bugs) and test case procedure which explains how the testing should be conducted.
"All the above put together makes a testing plan"

TestPlan is an roadmap to acheive your testing activity.ie what are the process that u are going to follow in ur
testing.

4.How do I test web-related applications?

First u have to test
web tier testing
1.browser compatible
2.compatible testing.
middle tier testing
1.security testing
2.performence testing
database tier
1.data integrity
2.database

web testing is done in three tiers

1. first tier of testing check is on look and feel,colors,fonts, evrrything.
2.secnd tier comes database testing,perfrmance testing
3.third tier comes security like network
security,transaction security
all other tests which are common for all

5.stress testing?
Just try some extreme conditions for your system : unplug the net cable, shut down the DB Server, kill a running
process of the system,.
Stress testing is subjecting the system under
heavy load but, denying the required resources for the system to perform (like RAM,Disc..etc).
Even if the system fails, it is not cause of worry.
The Idea is basically to confirm that the system does not fail in Improper manner.
The system should not Corrupt the data / Lose the existing data when it Fails.

Stress Testing is nothing but testing the software/product with resources.

That is Stress testing is a type of software Testing where we test the software with minimum and Maximum
condition.
Here we reduce the software Resources.
For Ex:
One software is recommended condition is 64 MB RAM.
For this software we will run it is 32 MB RAM,in this environment software should run.IT shouldn't crash the
system,it should have a Graceful exit.

6.what is stub & driver in intgration testing ?

Stub is a piece of code emulating a called function, a driver is a piece of code emulating a calling function
Stub: A piece of code that simulates the activity of missing component.

Driver: A piece of code that passes test case to another piece of code.

7.What is BVT in Testing field?

BVT is nothing but a build verification Test and will be done , after the integration of all modules/components
with the corresponding backend has been completed taken from the repository using some perl
scripts(usually).Also it can be considered to be given for alpha/beta testing.

8.difference between load and stress testing

Load testing is stressing within maximum limits - focus is on Performance Criteria..

Stress testing is stressing beyond maximum limits - focus is to know failure behavior of the system.
Load Testing is a process to check where exactly the system/server starts to degrade.
Stress testing is negative testing.eg.if a system can response properly for say 100 users.Bulk of users will be
accessed to check the systems performance,there by reducing the no. of users if the system degrades.

9.Exact difference bet Bug, Error & Defect?

Error : Is an undesirable deviation from requirements

Bug : Is an error found BEFORE the application goes into production

Defect :Is an error found AFTER the application goes into production
Error : Deviation for actual and the expected/theoritical value .

Bug : An Error found in the development environment before the product is shipped to the customer .

Defect : An Error found in the product itself after it is shipped to the customer .

10.What weaknesses within a computer network can have direct effect on the functionality of the system
The weakness may be from server to installation and unavalaiability and inability to retrieve the required
data or files to the system

11.What is Testing? What is Test Plan? What is Test case?

Testing: Executeing a program with a intent of finding bugs.
TestPlan: It is a roadmap for testing the system
Testcase:To check the behaviour of particular attidue

test plan: A record of the test planning process detailing the degree of tester indedendence, the test
environment, the test case design techniques and test measurement techniques to be used, and the rationale for
their choice.

test case: A set of inputs, execution preconditions, and expected outcomes developed for a particular objective,
such as to exercise a particular program path or to verify compliance with a specific requirement. After
[IEEE,do178b]

Test: The process of executing the system satisfies specific requirements and detecting the errors

Test Plan: Test Plan is a document which gives object,scope,and focus software testing efforts.

Test case: Test case is a document which gives action,event expected results in future that object perfectly
working or not.

12.actually ,what is software testing?

Software testing is nothing but verification and validation of the Software Product / Application.

Verification
============

- to see that the product is built right.

- Here we will determine that the Work Products of a given phase of a Software Development Life Cycle, meets
the requirements established in the previous phase.

- We will also see that the work is complete, correct and consistent enough to support the next phase.

Validation
==========

- to see that the right product is built.

- It is the process of evaluating the Software throughout the Software Development Life Cycle to ensure
compliance to requirements.

- Here we will see that the Actual Results are in conformance with Expected Results when subjected to
anticipated events.

- No unexpected behavior is observed when subjected to unanticipated events.

- Under the given operational conditions the Systems behaves as per the Users Expectations.

13.What is difference between win runner and rational robot.

rational robot deals with functional,regression and performance testing whereas loadrunner is only performance
testing and winrunner is for functional and regression testing
Winrunner is used for testing GUI applications on windows OS mostly.Rational robot can be used for any
application irrespective of OS.In addition Rational Robot is Project management tool.While for Winrunner we
need Test director to prepare test plan,manage test scripts and track defects.
14.what are the stages present in bug life cycle
STATUS RESOLUTION:
The status field indicates the general health of a bug. Only certain status transitions are allowed. The resolution
field indicates what happened to this bug.
UNCONFIRMED:
This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the
"canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and
marked RESOLVED.
NEW:
This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be
accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked
RESOLVED.
ASSIGNED:
This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person
and become NEW, or resolved and become RESOLVED.
REOPENED:
This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is
REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked
ASSIGNED or RESOLVED. No resolution yet. All bugs which are in one of these "open" states have the resolution set
to blank. All other bugs will be marked with one of the following resolutions.
RESOLVED:
A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and
become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
VERIFIED:
QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs
remain in this state until the product they were reported against actually ships, at which point they become
CLOSED.
CLOSED:
The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must
do so by becoming REOPENED.

Bugs can broadly under go following stages:

1)Open stage:A defect originated by a tester

2)Assign :Raised defect assigned to Developer
3)Resolved stage: Developer provides the code fix for the bug and make it resolved
4) Closed stage : Tester re-tests the bug and closes it , if its working.Otherwise he will re-open the defect and it
will go back to stage 1.

There is no standard that bug life cycle should have the above stages. You can define your own sub stages
according to your convenience

15.it possible to record the commands that we type in DOS-prompt?

Test can be executed in dos as analog mode.but re execution of a particular command is not possible.
You can run the dos_system("any dos command"); (qa.com,softwaretest.com,qaform.com)

16. What is test case management? How can effective test cases be written?
Test Case Management is nothing but maintaining the test cases with a process in a storage medium which can be
anything from CVS/RCS database txt file etc.

Any product company would have a defined process and management to maintain their huge numbers of
testcases.

The TC Management also have procedural guidelines to the users while recording the testcases.

17.What is the difference between a Software application and Software product?

It should be Software Project and Software Product.

Software Project is done for a specific clients of your company. For this some of the testing may be done at
client's side. For example, Acceptance Testing..

Software Product is not done for a single client and it is released as a product of the company.

Any doubts, you are welcome at: sdattaramprasad@yahoo.com

Application is more specific for a particular business requirement where as product is more generic.

In other words, application is used for solving particular problem or specific need, where as product looks at
broader sense.

Requirement Phase:

When you build an application you look at particular user/client and understand their requirements. But for
building a product the requirements are gathered not by looking at a single user but one does market survey and
come up with most likely features that cross section
of users will look at.
These requirements are not only functional requirements but also platform/hardware requirements.
Typically product offers set of features then it's up to the organizations to use some or all of them.

In some cases Product don't have all the required features, in such case it is customized to suite the need, in
such case this implementation/customized version of product can be considered as
application.

Testing:
Typically application is supported on single platform, the one that target organization has. For products it's
variety of OS, hardware etc, you must have see typically product matrix. Hence it is necessary to test the
product on all the combinations.

Releases:

Though it is not completely true but in most cases, once application is developed there are few enhancements.
Also bug fixes are typically completed before User Acceptance testing. Since for product there is not a single
customer, there is no UAT as such, once QA certifies product is released to market. Very fact that product is
generic and is suppose to work in different scenarios it's very difficult to exhaust all the scenarios during QA
testing, and as you know the defects are found in released product. The bug fixes for these are handled by patch
releases (Microsoft is very good example for these patch releases, you must have seen SP1, SP2 etc even for OS).
This means configuration management is complex for Products.

Otherwise rest of the software lifecycle stages like specs, development, impact analysis are identical.

18.how to evaluate system testing tools??

System testing is a serious of different test who's primary purpose to execute the system fully exercise computer
based system.each test have different purpose it will work,and properly integrating and allocating fuctions

19.WHAT IS SOFTWARE TESTING?

Testing involves operation of a system or application under controlled conditions and evaluating the results (eg,
'if the user is in interface A of the application while using hardware B, and does C, then D should happen'). The
controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt
to make things go wrong to determine if things happen when they shouldn't or things don't happen when they
should. It is
oriented to 'detection'

20. Basis path testing: To execute every statement in a program at least one time.By using basis path test will
find out the execute path of the statement

Data Flow testing: select statement in a program and uses the variable of the definition

21.What are the parameters for performance testing

Response Time during data retrieval ,calculations, TurnAround time, Bandwidth, Web Page loadtime during
Multiple user logins.

22.Regression test
Regression test is nothing about Retesting the test which is already executed to compare the actual result with
expected result after fixing the bug/

23.can you explain the testing life cycles

Testing LifeCycle
1. Preparation of Testing Project Plan which includes Test Strategy.
2. Preparation of TestScripts which contains Test Scenarios.
3. Preparation of Testing Bed. ie: Setting up the Test Environment
4. Executiong the TestScripts ( Automated as well as Manual Tests). Note: Confidence Testing has to be done to
check whether all the top level functionalities are working fine.
5. Defect Tracking with any bug tracking tools.
6. Preparation of Test Completion Report and Test Incident Report.
7. Preparation of Test Metrics for Continous Process Improvement.

Software Test Life Cycle comprise of following activities:

Test Planning: 1- Plan Test (Prepare a comprehensive Test Plan to define the proposed scope, techniques,
strategies and testing sequence and risk & assumptions)
2- Design Test (Documenting the Test Specifications; identifying Logical Test Scenarios; writing Physical Test-
Cases/Scripts (fully dressed with data) and developing Trace-ability Matrix)
3- Test Scheduling: Effort estimation in terms of Time and Resources.
4- Preparation of the Test Environment.
5- Execution of the Test Cases and Scripts.
6- Bug Reporting.
7- Test Execution and Bug Status Reporting.
8- Documenting experience and conclusions for future reference and process improvements.

24.TEST CASE
Test Case
=========

Test cases should be designed and developed based on the User requirements and System architecture and
Functionality.

Also this varies based on what testing and at what stage the testing is carried out.

If it is Unit Testing then the Test Cases will be developed to test the smallest part of the overall user's
requirements or the small component of the overall system architecture.

If it is an Integration testing then the Test case will be developed to verify a function of the User requirements or
an interface between two modules of the System.

If it is a System Testing then the Test Case will be developed to validate the System as a whole End-to-end, while
combining it with the required HW, Database, Networking and any other connections such as Printers, Fax or any
other external supporting SW application. Here, while an input is given to the System, the System's behavior to
handle the input data and its final expected out put will be verified.

And finally if it is User Acceptance Testing, then the Test Cases will be developed from the User's requirements
perspective.
Sanity Testing
=============

It is to test the basic required functionality of the developed system.

Verification and Validation

===========================

Verification is basically to see that the "Right product is built".

Validation is to see that the "Product is built right".

Test case: test case is a document which describes action,event,expected result,in future that object is perfectly
working or not.

Test case should be developed based on to the input requirement,and to check that object perfectly working or
not.

Test plan: Test plan is a document which describes object,scope and focus on the software testing efforts.

Test plan should be developed whenever requirement is getting at the time test plan should developed.

Sanity testing: sanity testing is a cursor testing it is performed whenever the cursor testing is sufficient to prove
the application is functioning according to the specification.

Verification: verification refers set of activities that ensure built into traceable to the customer requirement.

Validation:Validation refers different set of activities that ensure software is correctly implement or not.

25.When does software-testing finish?

Depends on the software being tested, the purpose of the software, and the complexity of the software. The
time of year can also affect the testing phase (software often has its testing time cut in November-December in
order to have the software available for Christmas).

On-line Games, for example, are very complex and difficult to make. Testing can sometimes take around a year.
Simple word processors may take a week to test, however. It all depends on how many things can go wrong (the
more complex, the more things to test). It's always possible that testing times will get cut short, as well.

Furthermore, it's impossible to find every bug in the program no matter how much testing you do. In that sense,
the testing phase never really ends.
26.tell me about v model

'V' shape model describes about the process about the construting the application at a time all the Analysing,
designing, coding and testing will be done at a time. i.e once coding finishes it'll go to tester to test for bugs if
we got OK form tester we can immediately start coding after coding again send to tester he'll check for BUGS and
will send back to programmer then he,programmer can finish up by implementing the project.
it is the model what is using by most of the companies.

27.how test dircter is used

Test Director is a management tool that gives systematic control over the testing process.

if your using win runner,you can integrated to test director by using tools menu you can click test director
command,otherwise you can going directly to test director you can built the automated tool which you want to
use.

28.What is E-Learning Content testing?

the orderly areanging the e-learning process by the way of some rules& regulations are predefined are verified
and to validate the task

29.what is traceability phase matrix?were it has been used and what is need for it?
It can be used to trace the functionality of the module. It is created before writing the test cases. Then the test
case ids can be added

Typically, in test situations, traceability matrices are used to trace requirements to test cases in order to ensure
that there are test cases for all the requirements. Some tools, such as Rational Suite Enterprise, will help
analysts trace requirements and then allow the tester to trace from the use cases and/or requirements to test
cases.

Of course, many types of traceability matrices may be created or reverse engineered. For example, you may
back trace defects-->test cases-->use cases and vice versa. The default term likely applies to tracing
requirements to test cases though

30.what is the difference between REGRESSION TESTING AND RETESTING. Why regression testing is vital in object
oriented programing
after retesting only we can for regression testing.
retesting is the process of testing of application after fixing the bugs.

regession testing is the process of reexecuting the application whether it affects the other parts of application or
not.

Regression testing is verifing that previously passed tests are still OK after any change to the software or the
environment, usually to verify that a change in one area doesn't affect other or unrelated areas. Retesting? just
running the same tests and conditions over and over again, to verify reproducability (precision)

31.What are the tools and techniques of black box testing?

Black Box Testing has 5 types of techniques like:
1. Decision Table
2. Equivalence Partitioning
3. Boundary Value Analysis
4. Cause & Effect Method
5. State Transition Method

32.What is traceability metrics

Its a mapping document that maps defects with test cases and test cases with functional specifications and
functional specifications with business requirements.In order trace back the defects
The Traceability Matrix is a very good document that gives us the complete overview / confidence on the end-to-
end activities of the SDLC. But it needs to be done carefully as we need to capture a lot of complex data at all
stages of an SDLC

Using the Traceability Matrix we will be able to confidently say that all the User Requirements are properly
documented and respectively addressed well in the following also:

1. Functional Requirements Document

2. Design Documents (HLDD and LLDD)
3. Coding and Unit Testing
4. System Test Plans
5. Test Execution Reports

So precisely, a Traceability Matrix gives us the end-to-end visibility of the Requirements.

33.How pass word testing is performed.

1)Check for Null values
2)Check for Alpha characters only(small and caps letters)
3)Check for numeric characters only
4)Check for alphanumeric values.(small and caps letters)
5)Check for sniffing of password when the user enters his/her username , password and clicks the submit button,
The password should be displayed in encrpyted/hash format when viewed by external user.
6)Check for password entry in the database
it should be displayed in encrypted/decrypted format based on the requirement of the user

34.what do u test for in database testing

other than data integrity(insert, delete, update...)
This will not be exact Testing but can be done as verification.
Field size validation with the Front End or with the Design.
Field size validation, if application is having data for multiple language.
Return type of each function and Out Parameter for each procedure.
If Data base is any file Generation routine that can be tested.
In DB testing we need to check for
1. The field size validation
2. Check constraints.
3. Indexes are done or not (for performance related issues)
4. Stored procedures
5. The field size defined in the application is matching with that in the db.

35.When should a Test to be Automated ?

Automation is carried out of based on the following conditions

1. Regression testing

2. when there is a need of working with large

input.

3. Batch testing

4. Frequently changing requirements

36. BlockBoxTest: Testing process is done without knowing internal process is BlockBox testing

WhiteBox Test: Testing process is done with knowing internal process is whitebox testing

37.Describe the fundamental difference between Quality Assurance and Quality Control?
quality assurance meant for developing,organising the best quality process.
quality control meant for implementing the process developed by former team

38.What is smoke test?Can u send me a case study of smoke test

Smoke Test is covering all the functionality in less time to make sure that the application works fine in the
normal condition. Smoke test is done during the daily build
It verifies the major functionality at high level in order to determine if further testing is possible. The Smoke test
scenarios should emphasize breadth more than depth. All components should be touched, and every major
feature should be tested briefly. If test fails, the build is returned to developers un-tested

39.how do we assign priority and seviority levels

seviority is assigned based on the impact on the risk.The risk may be human life or huge amount of money
business specific. example
If a bug in financial application wrong calculation of interest which may cause the bank to suffer huge financial
losses(legal and may need the bank to close) then sevority is given as 1 (highest) and need to be fixed.the bug
may be related to printing first name first and last name second.which willl have less impact on the business
seviority is less say 4.

Priority comes when we are fixing the bug which one needs to be taken first for fixing.This decision is taken by
the schedule of the project.

If you take the above case if additional information is required for interest calculation and the delivery got
enough time then priority can be given to less seviority bug then high seviority bug

40.A bug is raised by the tester and it was told that it is not a bug by the programmer. What to do?
Its a tester who has to say if that is a bug..a programmer would never accept it a bug though in all probability he
would sneakily fix it. The tester needs to take a call. If there is a disagreement by the programmer after posting
the bug, then he should discuss it through the manager

41.what is 'front end testing' and 'back end testing'

This isn't a textbook answer but in casual environments, I've found that people mean black box functional,and
interface testing when they refer to the front end.

Backend testing seems to be used to refer to any number of things such as white box testing, or simply lower
level testing sans GUI if applicable.

These terms aren't formalized and should not be used in test plans. Refer to a good template to find the proper
terms to use in place of "front-end" and "back-end" testing

Front end testing is testing GUI and functionality

Back-end focuses on data stored in the database

QATester he knowing about the testing process,at the same time evaluation is also performed

42.What are the different testing methodologies

Object Oriented Software Testing Methodologies
Top to bottom Software Testing Methodologies
Bottom to Top Software Testing Methodologies
Heuristic Software Testing Methodologies

43.What is the difference between user acceptance testing and beta testing
By User acceptance testing we mean validating
whether all the user requirements specified in SRS is met after code freeze. Beta Testing is done at 90-95% of
code freeze. Any modifications to be done at this stage is a high level decision

44.What are the types of Test cases?

Negative, Positive and GUI related

45.whether it is possible to test strees by winrunner howit is done
stress tests cannot be performed on win runner as the tool is particularly meant for the functionality of the
application
Winrunner does support stress testing. To create test conditions for determining the limits of your application,
use the 'looping' concept. Create TSL tests using the 'for', 'while' and 'do/while'

46.what are the importance of software verification

verification involves checking the application in terms of papers, means reviewing the requirements, test cases
reports so that it works as per the specifications.
(experience people might found odd in this solution)
whereas in validation real time testing is done on the application

47.What is testing? __
Testing is the process of identifying defects, where a defect is any variance between actual and expected results

48.How to Write a Fully Effective Bug Report

One of the most important (and most common) things an SQA Engineer does is to write "bug reports". How well
you report a bug directly affects how likely the programmer is to fix it. You should spend a minimum of time
needed to describe a problem in a way that maximizes the probability that it will be fixed. The content and
manner of your reports affect that probability

To write a fully effective report you must:

- Explain how to reproduce the problem - Analyze the error so you can describe it in a minimum number of steps.

- Write a report that is complete and easy to understand.

Write bug reports immediately; the longer you wait between finding the problem and reporting it, the more
likely it is the description will be incomplete, the problem not reproducible, or simply forgotten.

Writing a one-line report summary (Bug's report title) is an art. You must master it. Summaries help everyone
quickly review outstanding problems and find individual reports. The summary line is the most frequently and
carefully read part of the report. When a summary makes a problem sound less severe than it is, managers are
more likely to defer it. Alternatively, if your summaries make problems sound more severe than they are, you will
gain a reputation for alarmism. Don't use the same summary for two different reports, even if they are similar.
The summary line should describe only the problem, not the replication steps. Don't run the summary into the
description (Steps to reproduce) as they will usually be printed independently of each other in reports.
Ideally you should be able to write this clearly enough for a developer to reproduce and fix the problem, and
another QA engineer to verify the fix without them having to go back to you, the author, for more information. It
is much better to over communicate in this field than say too little. Of course it is ideal if the problem is
reproducible and you can write down those steps. But if you can't reproduce a bug, and try and try and still can't
reproduce it, admit it and write the report anyway. A good programmer can often track down an irreproducible
problem from a careful description.
The most controversial thing in a bug report is often the bug Impacts: Low, Medium, High, and Urgent. Report
should show the priority which you, the bug submitter, believes to be appropriate and does not get changed.
Bug Impacts __________________________________________
Low impact
This is for Minor problems, such as failures at extreme boundary conditions that are unlikely to occur in normal
use, or minor errors in layout/formatting. These problems do not impact use of the product in any substantive
way.

Medium impact
This is a problem that a) Effects a more isolated piece of functionality. b) Occurs only at certain boundary
conditions. c) Has a workaround (where "don't do that" might be an acceptable answer to the user). d) Occurs
only at one or two customers. or e) Is very intermittent

High impact
This should be used for only serious problems, effecting many sites, with no workaround. Frequent or
reproducible crashes/core dumps/GPFs would fall in this category, as would major functionality not working.

Urgent impact
This should be reserved for only the most catastrophic of problems. Data corruption, complete inability to use
the product at almost any site, etc. For released products, an urgent bug would imply that shipping of the
product should stop immediately, until the problem is resolved.

Black-Box testing basic practical hints:

Editable Fields Checking and Validation:
Valid/invalid characters/strings data in all editable fields
Valid minimum/maximum/mid range values in fields
Null strings (or no data ) in required fields
Record length (character limit)in text/memo fields
Cut/copy/paste into/from fields when possible

Not Editable Fields Checking:

Check for all test/spelling in warnings and error messages/dialogs
Invoke/check all menu items and their options

Application Usability:
Appearance an outlook (Placement an alignment of objects on screen)
User Interface Test (open all menus, check all items)
Basic functionality checking (File+Open+Save, etc..)
Right mouse clicking sensitivity
Resize/min/max/restore app, windows (check min app size)
Scrollability when applicable (scrollbars, keyboard, autoscrolling)
Keyboard and mouse navigation, highlighting, dragging, drag/drop
Print in landscape an portrait modes
Check F1, What's This , Help menu
Short-cut and Accelerator keys
Tab Key order and Navigation in all dialog boxes and menus

Basic compatibility:
16 bit OS (Win 3.x, Win95, OS/2, WinNT3.x)
32 bit OS (Win95, Win98, Win200, WinNT4.x) UNIX

How to create a Test Plan without docs?

1. Try to break up your huge application into modules that are functionally independent.
2. Within each module you start with the functions one by one.
3. For a simple function write all possible test cases that arise to be tested, while using the application as there
are no specs.
4. In this way you could complete one function and in turn whole application.
5. To prepare test cases or plan make use of Excel sheet. Each sheet will define each function within the module.
This is best way to organize the test cases.

Important areas of "black box" when QA engineer write test plans:

* Acceptance test (into testing)
* Data flow and integrity
* Configuration and compatibility
* Stress test
* Regressions
* Performance
* Potential bugs
* Beta tests
* Release tests
* Utility
* User interfaces

11:14 PM