100 keyboard shortcuts

CTRL+C (Copy)

CTRL+X (Cut)

CTRL+V (Paste)

CTRL+Z (Undo)

DELETE (Delete)

SHIFT+DELETE (Delete the selected item permanently without placing the item in the Recycle Bin)

CTRL while dragging an item (Copy the selected item)

CTRL+SHIFT while dragging an item (Create a shortcut to the selected item)

F2 key (Rename the selected item)

CTRL+RIGHT ARROW (Move the insertion point to the beginning of the next word)

CTRL+LEFT ARROW (Move the insertion point to the beginning of the previous word)

CTRL+DOWN ARROW (Move the insertion point to the beginning of the next paragraph)

CTRL+UP ARROW (Move the insertion point to the beginning of the previous paragraph)

CTRL+SHIFT with any of the arrow keys (Highlight a block of text)

SHIFT with any of the arrow keys (Select more than one item in a window or on the desktop, or select text in a document)

CTRL+A (Select all)

F3 key (Search for a file or a folder)

ALT+ENTER (View the properties for the selected item)

ALT+F4 (Close the active item, or quit the active program)

ALT+ENTER (Display the properties of the selected object)

ALT+SPACEBAR (Open the shortcut menu for the active window)

CTRL+F4 (Close the active document in programs that enable you to have multiple documents open simultaneously)

ALT+TAB (Switch between the open items)

ALT+ESC (Cycle through items in the order that they had been opened)

F6 key (Cycle through the screen elements in a window or on the desktop)

F4 key (Display the Address bar list in My Computer or Windows Explorer)

SHIFT+F10 (Display the shortcut menu for the selected item)

ALT+SPACEBAR (Display the System menu for the active window)

CTRL+ESC (Display the Start menu)

ALT+Underlined letter in a menu name (Display the corresponding menu)

Underlined letter in a command name on an open menu (Perform the corresponding command)

F10 key (Activate the menu bar in the active program)

RIGHT ARROW (Open the next menu to the right, or open a submenu)

LEFT ARROW (Open the next menu to the left, or close a submenu)

F5 key (Update the active window)

BACKSPACE (View the folder one level up in My Computer or Windows Explorer)

ESC (Cancel the current task)

SHIFT when you insert a CD-ROM into the CD-ROM drive (Prevent the CD-ROM from automatically playing)

Dialog Box Keyboard Shortcuts

CTRL+TAB (Move forward through the tabs)

CTRL+SHIFT+TAB (Move backward through the tabs)

TAB (Move forward through the options)

SHIFT+TAB (Move backward through the options)

ALT+Underlined letter (Perform the corresponding command or select the corresponding option)

ENTER (Perform the command for the active option or button)

SPACEBAR (Select or clear the check box if the active option is a check box)

Arrow keys (Select a button if the active option is a group of option buttons)

F1 key (Display Help)

F4 key (Display the items in the active list)

BACKSPACE (Open a folder one level up if a folder is selected in the Save As or Open dialog box)

m*cro$oft Natural Keyboard Shortcuts

Windows Logo (Display or hide the Start menu)

Windows Logo+BREAK (Display the System Properties dialog box)

Windows Logo+D (Display the desktop)

Windows Logo+M (Minimize all of the windows)

Windows Logo+SHIFT+M (Restore the minimized windows)

Windows Logo+E (Open My Computer)

Windows Logo+F (Search for a file or a folder)

CTRL+Windows Logo+F (Search for computers)

Windows Logo+F1 (Display Windows Help)

Windows Logo+ L (Lock the keyboard)

Windows Logo+R (Open the Run dialog box)

Windows Logo+U (Open Utility Manager)

Accessibility Keyboard Shortcuts

Right SHIFT for eight seconds (Switch FilterKeys either on or off)

Left ALT+left SHIFT+PRINT SCREEN (Switch High Contrast either on or off)

Left ALT+left SHIFT+NUM LOCK (Switch the MouseKeys either on or off)

SHIFT five times (Switch the StickyKeys either on or off)

NUM LOCK for five seconds (Switch the ToggleKeys either on or off)

Windows Logo +U (Open Utility Manager)

Windows Explorer Keyboard Shortcuts

END (Display the bottom of the active window)

HOME (Display the top of the active window)

NUM LOCK+Asterisk sign (*) (Display all of the subfolders that are under the selected folder)

NUM LOCK+Plus sign (+) (Display the contents of the selected folder)

NUM LOCK+Minus sign (-) (Collapse the selected folder)

LEFT ARROW (Collapse the current selection if it is expanded, or select the parent folder)

RIGHT ARROW (Display the current selection if it is collapsed, or select the first subfolder)

Shortcut Keys for Character Map

After you double-click a character on the grid of characters, you can move through the grid by using the keyboard shortcuts:

RIGHT ARROW (Move to the right or to the beginning of the next line)

LEFT ARROW (Move to the left or to the end of the previous line)

UP ARROW (Move up one row)

DOWN ARROW (Move down one row)

PAGE UP (Move up one screen at a time)

PAGE DOWN (Move down one screen at a time)

HOME (Move to the beginning of the line)

END (Move to the end of the line)

CTRL+HOME (Move to the first character)

CTRL+END (Move to the last character)

SPACEBAR (Switch between Enlarged and Normal mode when a character is selected)

m*cro$oft Management Console (MMC) Main Window Keyboard Shortcuts

CTRL+O (Open a saved console)

CTRL+N (Open a new console)

CTRL+S (Save the open console)

CTRL+M (Add or remove a console item)

CTRL+W (Open a new window)

F5 key (Update the content of all console windows)

ALT+SPACEBAR (Display the MMC window menu)

ALT+F4 (Close the console)

ALT+A (Display the Action menu)

ALT+V (Display the View menu)

ALT+F (Display the File menu)

ALT+O (Display the Favorites menu)

MMC Console Window Keyboard Shortcuts

CTRL+P (Print the current page or active pane)

ALT+Minus sign (-) (Display the window menu for the active console window)

SHIFT+F10 (Display the Action shortcut menu for the selected item)

F1 key (Open the Help topic, if any, for the selected item)

F5 key (Update the content of all console windows)

CTRL+F10 (Maximize the active console window)

CTRL+F5 (Restore the active console window)

ALT+ENTER (Display the Properties dialog box, if any, for the selected item)

F2 key (Rename the selected item)

CTRL+F4 (Close the active console window. When a console has only one console window, this shortcut closes the console)

Remote Desktop Connection Navigation

CTRL+ALT+END (Open the m*cro$oft Windows NT Security dialog box)

ALT+PAGE UP (Switch between programs from left to right)

ALT+PAGE DOWN (Switch between programs from right to left)

ALT+INSERT (Cycle through the programs in most recently used order)

ALT+HOME (Display the Start menu)

CTRL+ALT+BREAK (Switch the client computer between a window and a full screen)

ALT+DELETE (Display the Windows menu)

CTRL+ALT+Minus sign (-) (Place a snapshot of the active window in the client on the Terminal server clipboard and provide the same functionality as pressing PRINT SCREEN on a local computer.)

CTRL+ALT+Plus sign (+) (Place a snapshot of the entire client window area on the Terminal server clipboard and provide the same functionality as pressing ALT+PRINT SCREEN on a local computer.)

m*cro$oft Internet Explorer Navigation

CTRL+B (Open the Organize Favorites dialog box)

CTRL+E (Open the Search bar)

CTRL+F (Start the Find utility)

CTRL+H (Open the History bar)

CTRL+I (Open the Favorites bar)

CTRL+L (Open the Open dialog box)

CTRL+N (Start another instance of the browser with the same Web address)

CTRL+O (Open the Open dialog box, the same as CTRL+L)

CTRL+P (Open the Print dialog box)

CTRL+R (Update the current Web page)

CTRL+W (Close the current window)

Acceptance Testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria—enables an end user to determine whether or not to accept the system.

Affinity Diagram: A group process that takes large amounts of language data, such as a list developed by brainstorming, and divides it into categories.

Alpha Testing: Testing of a software product or system conducted at the developer’s site by the end user.

Accessibility Testing: Verifying a product is accessible to the people having disabilities.

Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well.

Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm.

Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary forms across different system platforms and environments.

Application Programming Interface (API): A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.

Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve software quality

Audit: An inspection/assessment activity that verifies compliance with plans, policies, and procedures, and ensures that resources are conserved. Audit is a staff function; it serves as the “eyes and ears” of management.

Automated Testing: That part of software testing that is assisted with software tool(s) that does not require operator input, analysis, or evaluation.

Beta Testing: Testing conducted at one or more end user sites by the end user of a delivered software product or system.

Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to design tests.

Black Box Testing: Functional testing based on requirements with no knowledge of the internal program structure or data. Also known as closed-box testing. Black Box testing indicates whether or not a program meets required specifications by spotting faults of omission -- places where the specification is not fulfilled.

Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.

Bottom-up Testing: An integration testing technique that tests the low-level components first using test drivers for those components that have not yet been developed to call the low-level components for test.

Boundary Testing: Testing that focuses on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).

Boundary Value Analysis: A test data selection technique in which values are chosen to lie along data extremes. Boundary values include maximum, mini-mum, just inside/outside boundaries, typical values, and error values.

Brainstorming: A group process for generating creative and diverse ideas.
Branch Coverage Testing: A test method satisfying coverage criteria that requires each decision point at each possible branch to be executed at least once.

Branch Testing: Testing wherein all branches in the program source code are tested at
least once.

Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.

Bug: A design flaw that will result in symptoms exhibited by some object (the object under test or some other object) when an object is subjected to an appropriate test.

Cause-and-Effect (Fishbone) Diagram: A tool used to identify possible causes of a problem by representing the relationship between some effect and its possible cause.

Cause-effect Graphing: A testing technique that aids in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications.

Code Complete: Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.

Code Coverage: An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

Code Inspection: A formal testing technique where the programmer reviews source code with a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.

Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually monitored,
to analyze the programmer's logic and assumptions.

Coding: The generation of source code.
Clear-box Testing: Another term for white-box testing. Structural testing is sometimes referred to as clear-box testing; since “white boxes” are considered opaque and do not really permit visibility into the code. This is also known as glass-box or open-box testing.

Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.

Conformance Testing: The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.

Client: The end user that pays for the product received, and receives the benefit from the use of the product.

Control Chart: A statistical method for distinguishing between common and special cause variation exhibited by processes.

Customer (end user): The individual or organization, internal or external to the producing organization that receives the product.

Cyclomatic Complexity: A measure of the number of linearly independent paths through a program module.

Data Flow Analysis: Consists of the graphical analysis of collections of (sequential) data definitions and reference patterns to determine constraints that can be placed on
data values at various points of executing the source program.

Defect: NOTE: Operationally, it is useful to work with two definitions of a defect:
1) From the producer’s viewpoint: a product requirement that has not been met or a product attribute possessed by a product or a function performed by a product that is not in the statement of requirements that define the product.
2) From the end user’s viewpoint: anything that causes end user dissatisfaction, whether
in the statement of requirements or not.

Defect Analysis: Using defects as data for continuous quality improvement. Defect analysis generally seeks to classify defects into categories and identify possible causes in order to direct process improvement efforts.

Defect Density: Ratio of the number of defects to program length (a relative number).

Desk Checking: A form of manual static analysis usually performed by the originator. Source code documentation, etc., is visually checked against requirements and standards.

Data Flow Diagram: A modeling notation that represents a functional decomposition of a system.

Data Driven Testing: Testing in which the action of a test case is parameterized by
externally defined data values, maintained as a file or spreadsheet.

Debugging: The process of finding and removing the causes of software failures.

Dependency Testing: Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.

Depth Testing: A test that exercises a feature of a product in full detail.

Dynamic Testing: Testing software through executing it.

Dynamic Analysis: The process of evaluating a program based on execution of that program. Dynamic analysis approaches rely on executing a piece of software with
selected test data.

Error: 1) A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition; and
2) a mental mistake made by a programmer that may result in a program fault.

Error-based Testing: Testing where information about programming style, error-prone language constructs, and other programming knowledge is applied to select test data capable of detecting faults, either a specified class of faults or all possible faults.

Evaluation: The process of examining a system or system component to determine the extent to which specified properties are present.

Execution: The process of a computer carrying out an instruction or instructions of a computer.

Endurance Testing: Checks for memory leaks or other problems that may occur with prolonged execution.

End-to-End testing: Testing 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.

Exhaustive Testing: Testing which covers all combinations of input values and preconditions for an element of the software under test.

Failure: The inability of a system or system component to perform a required function within specified limits. A failure may be produced when a fault is encountered.

Failure-directed Testing: Testing based on the knowledge of the types of errors made
in the past that are likely for the system under test.

Fault: A manifestation of an error in software. A fault, if encountered, may cause a failure.

Fault Tree Analysis: A form of safety analysis that assesses hardware safety to provide failure statistics and sensitivity analyses that indicate the possible effect of critical
failures.

Fault-based Testing: Testing that employs a test data selection strategy designed to generate test data capable of demonstrating the absence of a set of pre-specified faults, typically, frequently occurring faults.

Flowchart: A diagram showing the sequential steps of a process or of a workflow around a product or service.

Formal Review: A technical review conducted with the end user, including the types of reviews called for in the standards.

Function Points: A consistent measure of software size based on user requirements. Data components include inputs, outputs, etc. Environment characteristics include data communications, performance, reusability, operational ease, etc. Weight scale: 0 = not present, 1 = minor influence, 5 = strong influence.

Functional Testing: Application of test data derived from the specified functional requirements without regard to the final program structure. Also known as black box testing.

Gorilla Testing: Testing one particular module, functionality heavily.

Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings.

Heuristics Testing: Another term for failure-directed testing.

Histogram: A graphical description of individual measured values in a data set that is organized according to the frequency or relative frequency of occurrence. A histogram illustrates the shape of the distribution of individual values in a data set along with information regarding the average and variation.

Hybrid Testing: A combination of top-down testing combined with bottom-up testing of prioritized or available components.

Incremental Analysis: Incremental analysis occurs when (partial) analysis may be performed on an incomplete product to allow early feedback on the development of that product.

Infeasible Path: Program statement sequence that can never be executed.

Inputs: Products, services, or information needed from suppliers to make a process work.

Inspection: 1) A formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the author to detect faults, violations of development standards, and other problems.
2) A quality improvement process for written material that consists of two dominant

components: product (document) improvement and process improvement (document production and inspection).

Instrument: To install or insert devices or instructions into hardware or software to monitor the operation of a system or component.

Integration: The process of combining software components or hardware components, or both, into an overall system.

Integration Testing: An orderly progression of testing in which software components or hardware components, or both, are combined and tested until the entire system has been integrated.

Interface: A shared boundary. An interface might be a hardware component to link two devices, or it might be a portion of storage or registers accessed by two or more computer programs.

Interface Analysis: Checks the interfaces between program elements for consistency and adherence to predefined rules or axioms.

Intrusive Testing: Testing that collects timing and processing information during program execution that may change the behavior of the software from its behavior in a real environment. Usually involves additional code embedded in the software being tested or additional processes running concurrently with software being tested on the same platform.

Installation Testing: Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

IV&V: Independent verification and validation is the verification and validation of a software product by an organization that is both technically and managerially separate from the organization responsible for developing the product.

Life Cycle: The period that starts when a software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a requirements phase, design phase, implementation (code) phase, test phase, installation and checkout phase, operation and maintenance phase, and a retirement phase.

Localization Testing: This term refers to making software specifically designed for a specific locality.
Loop Testing: A white box testing technique that exercises program loops.

Manual Testing: That part of software testing that requires operator input, analysis, or evaluation.

Mean: A value derived by adding several qualities and dividing the sum by the number of these quantities.

Measurement: 1) The act or process of measuring. A figure, extent, or amount obtained by measuring.

Metric: A measure of the extent or degree to which a product possesses and exhibits a certain quality, property, or attribute.

Monkey Testing: Testing a system or an Application on the fly, i.e. just few tests here and there to ensure the system or an application does not crash out.

Mutation Testing: A method to determine test set thoroughness by measuring the extent to which a test set can discriminate the program from slight variants of the program.

Non-intrusive Testing: Testing that is transparent to the software under test; i.e., testing that does not change the timing or processing characteristics of the software under test from its behavior in a real environment. Usually involves additional hardware that collects timing or processing information and processes that information on another platform.

Negative Testing: Testing aimed at showing software does not work. Also known as "test to fail".

Operational Requirements: Qualitative and quantitative parameters that specify the desired operational capabilities of a system and serve as a basis for deter-mining the operational effectiveness and suitability of a system prior to deployment.

Operational Testing: Testing performed by the end user on software in its normal operating environment.

Outputs: Products, services, or information supplied to meet end user needs.

Path Analysis: Program analysis performed to identify all possible paths through a program, to detect incomplete paths, or to discover portions of the program that are not on any path.

Path Coverage Testing: A test method satisfying coverage criteria that each logical path through the program is tested. Paths through the program often are grouped into a finite set of classes; one path from each class is tested.

Peer Reviews: A methodical examination of software work products by the producer’s peers to identify defects and areas where changes are needed.

Policy: Managerial desires and intents concerning either process (intended objectives) or
products (desired attributes).

Problem: Any deviation from defined standards. Same as defect.

Procedure: The step-by-step method followed to ensure that standards are met.

Process: The work effort that produces a product. This includes efforts of people and equipment guided by policies, standards, and procedures.

Process Improvement: To change a process to make the process produce a given product faster, more economically, or of higher quality. Such changes may require the product to be changed. The defect rate must be maintained or reduced.

Product: The output of a process; the work product. There are three useful classes of

products: manufactured products (standard and custom), administrative/ information
products (invoices, letters, etc.), and service products (physical, intellectual, physiological, and psychological). Products are defined by a statement of requirements; they are produced by one or more people working in a process.
Product Improvement: To change the statement of requirements that defines a product to make the product more satisfying and attractive to the end user (more competitive). Such changes may add to or delete from the list of attributes and/or the list of functions defining a product. Such changes frequently require the process to be changed. NOTE: This process could result in a totally new product.

Path Testing: Testing wherein all paths in the program source code are tested at least once.

Performance Testing: Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".

Positive Testing: Testing aimed at showing software works. Also known as "test to
pass".

Productivity: The ratio of the output of a process to the input, usually measured in the same units. It is frequently useful to compare the value added to a product by a process to the value of the input resources required (using fair market values for both input and output).

Proof Checker: A program that checks formal proofs of program properties for logical correctness.

Prototyping: Evaluating requirements or designs at the conceptualization phase, the requirements analysis phase, or design phase by quickly building scaled-down components of the intended system to obtain rapid feedback of analysis and design decisions.

Qualification Testing: Formal testing, usually conducted by the developer for the end user, to demonstrate that the software meets its specified requirements.

Quality: A product is a quality product if it is defect free. To the producer a product is a quality product if it meets or conforms to the statement of requirements that defines the product. This statement is usually shortened to “quality means meets requirements.
NOTE: Operationally, the work quality refers to products.
Quality Audit: A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.

Quality Circle: A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.

Quality Management: That aspect of the overall management function that determines and implements the quality policy.

Quality Policy: The overall intentions and direction of an organization as regards quality as formally expressed by top management.

Quality System: The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.

Quality Assurance (QA): The set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved in order to produce products that meet specifications and are fit for use.

Quality Control (QC): The process by which product quality is compared with applicable standards; and the action taken when nonconformance is detected. Its focus is defect detection and removal. This is a line function, that is, the performance of these tasks is the responsibility of the people working within the process.

Quality Improvement: To change a production process so that the rate at which defective products (defects) are produced is reduced. Some process changes may require the product to be changed.

Random Testing: An essentially black-box testing approach in which a program is tested by randomly choosing a subset of all possible input values. The distribution may be arbitrary or may attempt to accurately reflect the distribution of inputs in the application environment.

Regression Testing: Selective retesting to detect faults introduced during modification of a system or system component, to verify that modifications have not caused unintended adverse effects, or to verify that a modified system or system component still meets its specified requirements.

Ramp Testing: Continuously raising an input signal until the system breaks down.

Recovery Testing: Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

Reliability: The probability of failure-free operation for a specified period.

Requirement: A formal statement of: 1) an attribute to be possessed by the product or a function to be performed by the product; the performance standard for the attribute or function; or 3) the measuring process to be used in verifying that the standard has been met.

Review: A way to use the diversity and power of a group of people to point out needed improvements in a product or confirm those parts of a product in which improvement is either not desired or not needed. A review is a general work product evaluation technique that includes desk checking, walkthroughs, technical reviews, peer reviews, formal reviews, and inspections.

Run Chart: A graph of data points in chronological order used to illustrate trends or cycles of the characteristic being measured for the purpose of suggesting an assignable cause rather than random variation.

Scatter Plot (correlation diagram): A graph designed to show whether there is a relationship between two changing factors.

Semantics: 1) The relationship of characters or a group of characters to their meanings, independent of the manner of their interpretation and use.
2) The relationships between symbols and their meanings.

Software Characteristic: An inherent, possibly accidental, trait, quality, or property of software (for example, functionality, performance, attributes, design constraints, number of states, lines of branches).

Software Feature: A software characteristic specified or implied by requirements documentation (for example, functionality, performance, attributes, or design constraints).

Software Tool: A computer program used to help develop, test, analyze, or maintain another computer program or its documentation; e.g., automated design tools, compilers, test tools, and maintenance tools.

Standards: The measure used to evaluate products and identify nonconformance. The basis upon which adherence to policies is measured.

Standardize: Procedures are implemented to ensure that the output of a process is maintained at a desired level.

Statement Coverage Testing: A test method satisfying coverage criteria that requires each statement be executed at least once.

Statement of Requirements: The exhaustive list of requirements that define a product. NOTE: The statement of requirements should document requirements proposed and rejected (including the reason for the rejection) during the requirements determination process.

Static Testing: Verification performed without executing the system’s code. Also called static analysis.

Statistical Process Control: The use of statistical techniques and tools to measure an ongoing process for change or stability.

Structural Coverage: This requires that each pair of module invocations be executed at least once.

Structural Testing: A testing method where the test data is derived solely from the program structure.

Stub: A software component that usually minimally simulates the actions of called components that have not yet been integrated during top-down testing.

Supplier: An individual or organization that supplies inputs needed to generate a product, service, or information to an end user.

Syntax: 1) The relationship among characters or groups of characters independent of their meanings or the manner of their interpretation and use.
2) The structure of expressions in a language, and
3) the rules governing the structure of the language.

Sanity Testing: Brief test of major functional elements of a piece of software to determine if it is basically operational.

Scalability Testing: Performance testing focused on ensuring the application under test gracefully handles increases in workload.

Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.

Smoke Testing: A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

Soak Testing: Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.
Software Requirements Specification: A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software/

Software Testing: A set of activities conducted with the intent of finding errors in software.

Static Analysis: Analysis of a program carried out without executing the program.

Static Analyzer: A tool that carries out static analysis.

Static Testing: Analysis of a program carried out without executing the program.

Storage Testing: Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.

Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

Structural Testing: Testing based on an analysis of internal workings and structure of a piece of software.

System Testing: Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.

System: A collection of people, machines, and methods organized to accomplish a set of specified functions.

System Simulation: Another name for prototyping.

Technical Review: A review that refers to content of the technical material being reviewed.

Test Bed: 1) An environment that contains the integral hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test of a logically or physically separate component.
2) A suite of test programs used in conducting the test of a component or system.

Test Development: The development of anything required to conduct testing. This may include test requirements (objectives), strategies, processes, plans, software, procedures, cases, documentation, etc.

Test Executive: Another term for test harness.

Test Harness: A software tool that enables the testing of software components that links test capabilities to perform specific tests, accept program inputs, simulate missing components, compare actual outputs with expected outputs to determine correctness, and report discrepancies.

Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.

Testing: The process of exercising software to verify that it satisfies specified requirements and to detect errors.
The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829). The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.

Test Bed: An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.

Test Case: Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc. 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.

Test Driven Development: Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.

Test Driver: A program or test tool used to execute tests. Also known as a Test Harness.

Test Environment: The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.

Test First Design: Test-first design is one of the mandatory practices of Extreme Programming (XP). It requires that programmers do not write any production code until they have first written a unit test.

Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.

Test Procedure: A document providing detailed instructions for the execution of one or more test cases.

Test Script: Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool.

Test Specification: A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.

Test Suite: A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by what they are intended to test.

Test Tools: Computer programs used in the testing of a system, a component of the system, or its documentation.

Thread Testing: A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.

Top Down Testing: An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.

Total Quality Management: A company commitment to develop a process that achieves high quality product and customer satisfaction.

Traceability Matrix: A document showing the relationship between Test Requirements and Test Cases.

Test Objective: An identified set of software features to be measured under specified conditions by comparing actual behavior with the required behavior described in the software documentation.

Test Plan: A formal or informal plan to be followed to assure the controlled testing of the product under test.

Unit Testing: The testing done to show whether a unit (the smallest piece of software that can be independently compiled or assembled, loaded, and tested) satisfies its functional specification or its implemented structure matches the intended design structure.

Usability Testing: Testing the ease with which users can learn and use a product.

Use Case: The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.

V- Diagram (model): a diagram that visualizes the order of testing activities and their corresponding phases of development

Verification: The process of determining whether or not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.

Volume Testing: Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.

Validation: The process of evaluating software to determine compliance with specified requirements.

Walkthrough: Usually, a step-by-step simulation of the execution of a procedure, as when walking through code, line by line, with an imagined set of inputs. The term has been extended to the review of material that is not procedural, such as data descriptions, reference manuals, specifications, etc.

White-box Testing: Testing approaches that examine the program structure and derive test data from the program logic. This is also known as clear box testing, glass-box or open-box testing. White box testing determines if program-code structure and logic is faulty. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable.

Workflow Testing: Scripted end-to-end testing which duplicates specific workflows, which are expected to be utilized by the end-user.

'Software Quality Assurance'
Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

What is the 'software life cycle'?
The life cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.

Quality Assurance Plan

Version <1.0>

Revision History

Date	Version	Description	Author

Table of Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

1.5 Overview

2. Quality Objectives

3. Management

3.1 Organization

3.2 Tasks and Responsibilities

4. Documentation

5. Standards and Guidelines

6. Metrics

7. Review and Audit Plan

8. Evaluation and Test

9. Problem Resolution and Corrective Action

10. Tools, Techniques, and Methodologies

11. Configuration Management

12. Supplier and Subcontractor Controls

13. Quality Records

14. Training

15. Risk Management

Quality Assurance Plan

1. Introduction

[The introduction of the Quality Assurance Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Quality Assurance Plan.]

1.1 Purpose

[Specify the purpose of this Quality Assurance Plan.]

1.2 Scope

[A brief description of the scope of this Quality Assurance Plan; what Project(s) it is associated with and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Quality Assurance Plan. This information may be provided by reference to the project's Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Quality Assurance Plan. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document. For the Quality Assurance Plan, this should include:

• Documentation Plan

• Measurement Plan

• Test Plan

• Software Development Plan

• Problem Resolution Plan

• Configuration Management Plan

• Subcontractor Management Plan

• Risk Management Plan]

1.5 Overview

[This subsection describes what the rest of the Quality Assurance Plan contains and explains how the document is organized.]

2. Quality Objectives

[This section needs to reference the section of the Software Requirements Specification that deals with quality requirements.]

3. Management

3.1 Organization

[Describe the structure of the organization responsible for Quality Assurance. The Rational Unified Process recommends that the Software Engineering Process Authority (SEPA) be responsible for the process component of Quality Assurance. The Rational Unified Process further recommends that the evaluation of product be done within the project (most notably by an independent test team) and by joint customer/developer review.]

3.2 Tasks and Responsibilities

[Describe the various Quality Assurance tasks that will be carried out for this project and indicate how they are synchronized with the project's major and minor milestones. These tasks will include:

• Joint Reviews

• Process Audits

• Process Reviews

• Customer Audits

For each task, identify the team member responsible for its execution.]

4. Documentation

[Enclose the Documentation Plan artifact by reference.

Also, list the minimum documentation that must be produced during the project to ensure that the software product that is developed satisfies the requirements. The suggested minimum set is:

• Software Development Plan (SDP)

• Test Plan

• Iteration Plans

• Software Requirements Specification (SRS)

• Software Architecture Document

• User Documentation (for example, manuals, guides)

• Configuration Management Plan

Provide pointers to the Development Case to show where in the process the adequacy of these documents is evaluated.]

5. Standards and Guidelines

[This section references any standards and guidelines that are expected to be used on the project, and addresses how compliance with these standards and guidelines is to be determined. The relevant artifacts are enclosed by reference. The suggested set for the Rational Unified Process is:

• Development Case

• Business Modeling Guidelines

• User-Interface Guidelines

• Use-Case Modeling Guidelines

• Design Guidelines

• Programming Guidelines

• Test Guidelines

• Manual Style Guide]

6. Metrics

[This section describes the product, project, and process metrics that are to be captured and monitored for the project. This is usually addressed by enclosing the Measurement Plan artifact by reference.]

7. Review and Audit Plan

[This section contains the Review and Audit Plan. The Review and Audit Plan specifies the schedule, resources, and methods and procedures to be used in conducting project reviews and audits. The plan details the various types of reviews and audits to be carried out during the project, and identifies any external agencies that are expected to approve or regulate the artifacts produced by the project.

This section should identify:

• Review and Audit Tasks

Describe briefly each type of review and audit that will be carried out on the project. For each type, identify the project artifacts that will be the subject of the review or audit. These may include Joint Customer-Developer Technical and Management Reviews, Process Reviews and Audits, Customer Audits, Internal Technical and Management Reviews.

• Schedule

Detail here the schedule for the reviews and audits. This should include reviews and audits scheduled at project milestones, as well as reviews that are triggered by delivery of project artifacts. This subsection may reference the project or iteration plan.

• Organization and Responsibilities

List here the specific groups or individuals to be involved in each of the identified review and audit activities. Describe briefly the tasks and responsibilities of each. Also, list any external agencies that are expected to approve or regulate any product of the project.

• Problem Resolution and Corrective Action

This subsection describes the procedures for reporting and handling problems identified during project reviews and audits. The Problem Resolution Plan may be referenced.

• Tools, Techniques and Methodologies

Describe here any specific tools, techniques or methodologies that are to be used to carry out the review and audit activities identified in this plan. You should describe the explicit process to be followed for each type of review or audit. Your organization may have a standard Review and Audit Procedures Manual, which may be referenced. These procedure descriptions should also address the collection, storage and archiving of the project’s Review Records.

A suggested set of reviews and audits (drawn from the Rational Unified Process) to use as a basis for planning is:

• Requirements Review (maps to the traditional Software Specification Review)

• Architecture Review (maps to the traditional Preliminary Design Review)

• Design Review (maps to the traditional Critical Design Review)

Note that the product-, technique-, criteria-, and metrics- related aspects of these reviews is addressed in the Rational Unified Process itself and instantiated in the Evaluation Plan section of the Software Development Plan. The Review and Audit Plan section of the Quality Assurance Plan will concern itself with the Joint (customer, developer) Review aspects, for example, artifacts required, responsibilities, conduct of the review meeting, pass or fail criteria.

• Functional Configuration audit (to verify all requirements in the SRS have been met)

• Physical configuration audit (to verify that the software and its documentation are complete and ready for delivery)

• Process audits

• Process reviews

• Managerial reviews (Project Approval Review, Project Planning Review, Iteration Plan Review, PRA Project Review)

• Post-mortem reviews (Iteration Acceptance Review, Lifecycle Milestone Review, Project Acceptance Review).]

8. Evaluation and Test

[This section references the Software Development Plan (Evaluation Plan section) and the Test Plan.]

9. Problem Resolution and Corrective Action

[This section references the Problem Resolution Plan.]

10. Tools, Techniques, and Methodologies

[A list of any tools, techniques and methodologies that are to be used when performing Quality Assurance activities.]

11. Configuration Management

[This section references the Configuration Management Plan.]

12. Supplier and Subcontractor Controls

[This section references the Subcontractor Management Plan.]

13. Quality Records

[Descriptions of the various quality records that will be maintained during the project, including how and where each type of record will be stored and for how long.]

14. Training

[List here any training activities necessary for the project team to achieve the needs of the Quality Assurance Plan.]

15. Risk Management

[This section references the Risk Management Plan.]

WHAT HINDUISM SAYS….
Hi Everyone … Here I am going to write about the experience about the Greatest Religion in this world called Hindu. It is not having any founder and it has been appreciated as the best religion in this world to teach culture, knowledge to this world. This religion also teaches and it’s the best in this world to survive from our pains and to become free in bad thoughts. I am going to explain, as I know. If you know more then you can also share with me.
I am starting today with the topic of 10 Avatars by God Vishnu. It is having a very great scientific reason in the Hinduism how the world has been created.

1. Ma’Cha


2. Koor’ma


3. Va’ra’gha


4. Va’mana


5. NaraShima


6. Parasurama


7. Rama


8. Balarama


9. Krishna


10. Kalki

These are the 10 avatars by the God.
Each one explains about the each evolution in this world by the living organism.

WHAT HINDUISM SAYS….
Hi Everyone … Here I am going to write about the experience about the Greatest Religion in this world called Hindu. It is not having any founder and it has been appreciated as the best religion in this world to teach culture, knowledge to this world. This religion also teaches and it’s the best in this world to survive from our pains and to become free in bad thoughts. I am going to explain, as I know. If you know more then you can also share with me.
I am starting today with the topic of 10 Avatars by God Vishnu. It is having a very great scientific reason in the Hinduism how the world has been created.

1. Ma’Cha


2. Koor’ma


3. Va’ra’gha


4. Va’mana


5. NaraShima


6. Parasurama


7. Rama


8. Balarama


9. Krishna


10. Kalki

These are the 10 avatars by the God.
Each one explains about the each evolution in this world by the living organism.

http://www.programmersheaven.com
http://www.codeproject.com/vb/net/
http://www.planetsources.com
http://www.dotnetindex.com
http://www.codersource.net/aspnet_sample_application.html
http://www.computer-mentors.co.uk/messagelist.html
http://www.dbxtra.com/ Crystal reports

--Very useful site for ASP.NET
http://aspalliance.com/
http://aspalliance.com/509 Automatically printing crystal reports in ASP.NET
http://aspalliance.com/crystal/default.aspx
http://aspalliance.com/crystal/redir.aspx?ArticleURL=http://www.codeproject.com/aspnet/crystal_report.asp

Directory of ASP.NET Resources
http://www.123aspx.com/ReadReviews.aspx?res=30160


http://www.businessobjects.com/products/dev_zone/net/default.asp?ref=devzone_main
http://www.crystalreportsbook.com
http://www.dbnetgrid.com/dbnetgrid/default.aspx
http://www.asp.net/IEWebControls/Download.aspx?tabindex=0&tabid=1
http://www.asp.net/Modules/MoreCommunities.aspx?tabindex=0&mid=79

how to export crystal report to pdf format.
http://www.c-sharpcorner.com/Code/2004/May/ExportCrystalReportInASPNET.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/crystlmn/html/crconcrystalreports.asp

Good one to look
http://www.dotnetspider.com/technology/kbpages/842.aspx

http://www.learnxpress.com/modules/index.aspx

ADO.NET
http://www.sitepoint.com/subcat/asp
http://www.sitepoint.com/article/introduction-ado-net
http://www.datadirect.com/developer/net/basics/index.ssp
Resources
■ QTP 5.6 or 6.0 Readme
■ QTP 5.6 or 6.0 Knowledge Base Articles
■ QTP 5.6 or 6.0 Installation Guide
■ QTP 5.6 or 6.0 Tutorial
■ QTP 5.6 or 6.0 Object Model Reference
■ QTP 5.6 or 6.0 Help
■ Microsoft VBScript Reference
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/
vtoriVBScript.asp
■ Microsoft VBScript Users Guide
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/
vtoriVBScript.asp
■ Microsoft MSDN Library: Programming with VBScript
http://msdn.microsoft.com/library/default.asp?URL=/library/partbook/egvb6/
programmingwithvbscript.htm
■ VB & VBA in a Nutshell: The Language by Paul Lomax ISBN: 1-56592-358-8
■ Sun Java Developers Center: http://java.sun.com
■ JavaScript for the Total Non-Programmer
http://www.webteacher.com/javascript/
■ http://www.w3c.org

Testing Links
http://www.perftestplus.com/eval.htm
http://www.testingeducation.org/articles/

http://www.acomtech.com/testdevl.html
http://geekswithblogs.net/dthakur/archive/2004/08/20/9958.aspx
http://geekswithblogs.net/dthakur/articles/10085.aspx
http://geekswithblogs.net/dthakur/articles/6475.aspx


http://www.goau.com/

http://www.ebroadcast.com.au/dir/Computers/Programming/Software_Testing/
Subject: imp link test
http://www.qualitytree.com/links/links.htm
http://www.iso.ch/iso/en/iso9000-14000/iso9000/qmp.html


Interoperability Testing: which measures the ability of your software to communicate across the network on multiple machines from multiple vendors each of whom may have interpreted a design specification critical to your success differently.Inter-operability Testing: True inter-operability testing concerns testing for unforeseen interactions with other packages with which your software has no direct connection. In some quarters, inter-operability testing labor equals all other testing combined. This is the kind of testing that I say shouldn’t be done because it can’t be done.Scalability Testing: is a subtype of performance test where performance requirements for response time, throughput, and/or utilization are tested as load on the SUT is increased over time.
Numerous IT organizations have reported their success with process improvement based on the SEI CMM/CMMI framework. However, the CMM and CMMI models have very little practices addressing the test process. This motivated the software testing community to develop their own TEST process maturity models. Following are the test process assessment and improvement models:TPAM CMM-Companion Test Process Assessment Model;TMM Testing Maturity Model; andTPI Test Process Improvement Model

Some deails about TMM: http://www.stsc.hill.af.mil/consulting/show_ct_article.asp?uri=2002/11/staab.html

http://www.rspa.com/spi/index.htmlhttp://www.w3.org/Security/Faq/index.html#contentshttp://www.iturls.com/English/SoftwareEngineering/WE_d.asp
Pierce Business Systemshttp://www.pb-sys.com/ Software Description Buggit manages bugs and features throughout the software development process. Testers, developers, and managers can all benefit greatly from the use of Buggit. They can enter and edit bugs/features, perform quick lookups of existing issues, print from a wide variety of powerful reports and graphs (see screen shot links at PBSystems webpage), administer new bug project databases, and much more. Buggit provides an unlimited number of central, multi-user databases, each capable of handling mulitple concurrent users across the development team. Platforms Windows Entry updated February 3, 2003.

MantisKind of Tool Bug tracking system (freeware) Organization Mantis projecthttp://mantisbt.sourceforge.net/ Software Description A php/MySQL/web based bug tracking system. Beta status. Platforms Unix, Windows. Entry updated February 3, 2003.Return to Listings

AbukyKind of Tool Bug tracking system (freeware) Organization Abuky projecthttp://abuky.sunsite.dk/index.html Software Description Abuky stands for the Aoo BUg tracKing sYstem, while AOO stands for Art Of Open Source. Abuky is a system for tracking bugs and aiding the developer to fix them, written in Java with JSP as web interface. Platforms Linux, Solaris, Windows 98, Windows 2000 Entry updated February 3, 2003.

Automation The process of writing a set of instructions that are designed, scripted, tested, and checked in by a person, then executed by a machine, to produce results that can be analyzed.Acceptance Testing Is the process of comparing a program to its requirementsAd - Hoc testing Appropriate and very often syndicated when tester wants to become familiar with the product, or in the environment when technical/testing materials are not 100% completed. It is also largely based on general software product functionality/testing understanding and the normal 'Human Common Sense'.Automation The process of writing a set of instructions that are designed, scripted, tested, and checked in by a person, then executed by a machine, to produce results that can be analyzed.B - CBuild Acceptance Test The build acceptance test is a simplistic check of a product's functionality in order to determine if the product is capable of being tested to a greater extent. Every new build should undergo a build acceptance test to determine if further testing can be executed. Examples of a build acceptance:Product can be installed with no crashes or errors that terminate the installation. (Development needs to install the software from the same source accessed byQA (e.g. Drop Zone, CD-ROM, Electronic Software Distribution archives, etc.).Clients can connect to associated servers.Simple client server communication can be achievedBottom - up Start testing with the bottom of the program. The bottom - up strategy does not exist until the last module is added.client The client part of a client-server architecture. Typically, a client is an application that runs on a personal computer or workstation and relies on a server to perform some operations.Client-Server Testing Systems that operate in client/server environments.Compatibility Test This test is used to test compatibility between different client/server version combinations as well as other supported products.Confidence Test The confidence test ensures a product functions as expected by ensuring platform specific bugs are not introduced and functionality has not regressed from drop to drop. A typical confidence test is designed to touch all major areas of a product's functionality. These tests are run regularly once the Functional Freeze milestone is reached throughout the remaining development cycle.Configuration Tests These tests are run for product testing across various system configuration combinations. Examples of configurations:Cross platform (e.g. Windows Clients against a UNIX server).Client/server network configurations. Operating systems and database combinations (also including version combinations).Web servers and web browsers (for web products). The system configurations to test are determined from the product's compatibility matrix. This test is sometimes called a 'Platform test'.CET (Customer Experience Test)An in-house test is performed before the Alpha, Beta, and FCS milestones which is used to determine whether the product can be installed and used without any problems, assistance, or support from others.D - EDebug An attempt to determine the cause of the symptoms of malfunctions detected by testing or by frenzied user complaints.Event-Driven Testing event-driven processes, such as unpredictable sequences of interrupts from input devices or sensors, or sequences of mouse clicks in a GUI environment.F - GFinal Installation Test Verification that the final media, prior to hand off to Operations for duplication, contains the correct code which was previously tested and is installable on all the supported platforms and databases. The product demo is executed and product Release Notes verified.Functionality Test This is designed to test the full functionality, features, and user interfaces of software based upon the functional specifications.Graphical User Interface (GUI) Testing the front-end user interfaces to applications which use GUI support systems and standard such as MS Windows or Motif.GUI Roadmaps Step by step walk through of a tool or application, exercising each screen or window's menus, toolbar and dialog boxes to verify the execution and correctness of the Graphical User Interface. Typically, this is handled by automated scripts and rarely is used as a manual tests due to the low numbers of bugs found from them.H - IInternationalization The process whereby software, which was ordinarily designed to operate within a single language or locale, is enhanced with capabilities and features which allow general support of a broad range of languages or locales. This usually implies the implementation of internal functions which would have been required to implement all of the locales within the range of locales, without committing to a particular one, as well as providing a mechanism for easily "plugging in" strings of the different languages. Use of the "globalized" software for a specific locale will then require relatively simple "localization" work.J - k - l - m - n - OModule testing To test large program its necessary to use module testing. Module testing (or unit testing) is a process of testing individual subprograms (small blocks), rather than testing the program as a whole. Module testing eases the task of debugging. When error is found, it is known is which particular module it is.Object A defined Windows control, such as a window, dialog box, check box, label, grid, radio button, or command button. Applications may also contain custom objects that conform to Windows object programming standards.Object-Ooriented Testing systems designed or coded using an object-oriented approach or development environment, such as C++ or Smalltalk.PParallel Testing Testing by processing the same (or at least closely comparable) test workload against both the existing and new versions of a product, then comparing results.Performance Measurement and prediction of performance (e.g. Response time and/or throughput) for a given benchmark workload.Phased ApproachA testing strategy where test cases are developed in stages so a minimally acceptable level of testing can be completed at any time. As new features are coded and frozen, they receive priorities for a given amount of time-so that a concentrated effort is directed toward testing those new features before the effort returns to validate the preexisting functionality. When no new features are available, preexisting features will be targeted-with priorities set by Project Leads.1st level - Minimal Acceptance Test2nd level - Confidence Tests3rd level - Full Functionality Test4th level - Error, Negative, and other Tests5th level - System level testsQQA A.K.A. Quality Assurance. Also known as Software Test. This is the group that performs methodical testing of the products developed by engineering. They make no statement of the quality of the product and no guaranty of finding all the bugs in a product. Their job is to take an independent approach to evaluating the product and open bugs against anything they think is broken or not performing as a reasonable end user might expect.Quality The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs. Not to be mistaken for "degree of excellence" or "fitness for use" which meet only part of the definition.RRegression Tests These tests are used for comprehensive re-testing of software to validate that all functionality and features of previous builds (or releases) have maintained integrity of features and functions tested previously. This suite of tests includes the Full Functionality Tests and bug Regression Tests (automated and manual).SSanity Test Sanity tests are subsets of the confidence test and are used only to validate high-level functionality.Security Testing It is a test how easy to break program's security system.Server A computer or device on a network that manages network resources. For example, a file server is a computer and storage device dedicated to storing files.Stress Test These tests are used to validate software functionality at the limit (e.g. Maximum throughput) and then testing at and beyond these limits.System Level Test These tests check for factors such as Cross-Tool testing, memory management and other operating system factors.T - u - v - w - x - y - ZTest The process of exercising a product to identify differences between expected and actual behavior.Test Requirement An operation, property, or behavioral characteristic of the app-under-test that must be verified.Top - Down strategy Start testing with the top of the program.Volume Testing Is the process of feeding a program with heavy volume of data.Usability The effectiveness, efficiency, and satisfaction with which specified users can achieve specified goals in a particular environment. Synonymous with "ease of use".Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.Accessibility Testing: Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.Application Programming Interface (API): A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve software quality.Automated Testing:Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.B (return to top of page)Backus-Naur Form: A metalanguage used to formally describe the syntax of a language.Basic Block: A sequence of one or more consecutive, executable statements containing no branches.Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to design tests.Basis Set: The set of tests derived using basis path testing.Baseline: The point at which some deliverable produced during the software engineering process is put under formal change control.Beta Testing: Testing of a rerelease of a software product conducted by customers.Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.Black Box Testing: Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.Boundary Testing: Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner.Boundary Value Analysis: BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out of range as defined by the specification. his means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.Branch Testing: Testing in which all branches in the program source code are tested at least once.Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.C (return to top of page)CAST: Computer Aided Software Testing.Capture/Replay Tool: A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.CMM: The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.Cause Effect Graph: A graphical representation of inputs and the associated outputs effects which can be used to design test cases.Code Complete: Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.Code Coverage: An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.Code Inspection: A formal testing technique where the programmer reviews source code with a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.Coding: The generation of source code.Compatibility Testing: Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.Component: A minimal software item for which a separate specification is available.Component Testing: See Unit Testing.Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.Conformance Testing: The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.Context Driven Testing: The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in replacement systems.Cyclomatic Complexity: A measure of the logical complexity of an algorithm, used in white-box testing.D (return to top of page)Data Dictionary: A database that contains definitions of all data items defined during analysis.Data Flow Diagram: A modeling notation that represents a functional decomposition of a system.Data Driven Testing: Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.Debugging: The process of finding and removing the causes of software failures.Defect: Nonconformance to requirements or functional / program specificationDependency Testing: Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.Depth Testing: A test that exercises a feature of a product in full detail.Dynamic Testing: Testing software through executing it. See also Static Testing.E (return to top of page)Emulator: A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.Endurance Testing: Checks for memory leaks or other problems that may occur with prolonged execution.End-to-End testing: Testing 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.Equivalence Class: A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.Equivalence Partitioning: A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.Exhaustive Testing: Testing which covers all combinations of input values and preconditions for an element of the software under test.F (return to top of page)Functional Decomposition: A technique used during planning, analysis and design; creates a functional hierarchy for the software.Functional Specification: A document that describes in detail the characteristics of the product with regard to its intended features.Functional Testing: See also Black Box Testing.Testing the features and operational behavior of a product to ensure they correspond to its specifications.Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.G (return to top of page)Glass Box Testing: A synonym for White Box Testing.Gorilla Testing: Testing one particular module,functionality heavily.Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings.H (return to top of page)High Order Tests: Black-box tests conducted once the software has been integrated.I (return to top of page)Independent Test Group (ITG): A group of people whose primary responsibility is software testing,Inspection: A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).Integration Testing: Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.Installation Testing: Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.J (return to top of page)K (return to top of page)L (return to top of page)Load Testing: See Performance Testing.Localization Testing: This term refers to making software specifically designed for a specific locality.Loop Testing: A white box testing technique that exercises program loops.M (return to top of page)Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.Monkey Testing: Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.N (return to top of page)Negative Testing: Testing aimed at showing software does not work. Also known as "test to fail". See also Positive Testing.N+1 Testing: A variation of Regression Testing. Testing conducted with multiple cycles in which errors found in test cycle N are resolved and the solution is retested in test cycle N+1. The cycles are typically repeated until the solution reaches a steady state and there are no errors. See also Regression Testing.O (return to top of page)P (return to top of page)Path Testing: Testing in which all paths in the program source code are tested at least once.Performance Testing: Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".Positive Testing: Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.Q (return to top of page)Quality Assurance: All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer.Quality Audit: A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.Quality Circle: A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.Quality Control: The operational techniques and the activities used to fulfill and verify requirements of quality.Quality Management: That aspect of the overall management function that determines and implements the quality policy.Quality Policy: The overall intentions and direction of an organization as regards quality as formally expressed by top management.Quality System: The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.R (return to top of page)Race Condition: A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.Ramp Testing: Continuously raising an input signal until the system breaks down.Recovery Testing: Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.Regression Testing: Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.Release Candidate: A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).S (return to top of page)Sanity Testing: Brief test of major functional elements of a piece of software to determine if its basically operational. See also Smoke Testing.Scalability Testing: Performance testing focused on ensuring the application under test gracefully handles increases in work load.Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.Smoke Testing: A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.Soak Testing: Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.Software Requirements Specification: A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software/Software Testing: A set of activities conducted with the intent of finding errors in software.Static Analysis: Analysis of a program carried out without executing the program.Static Analyzer: A tool that carries out static analysis.Static Testing: Analysis of a program carried out without executing the program.Storage Testing: Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.Structural Testing: Testing based on an analysis of internal workings and structure of a piece of software. See also White Box Testing.System Testing: Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.T (return to top of page)Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.Testing:The process of exercising software to verify that it satisfies specified requirements and to detect errors.The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829).The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.Test Automation: See Automated Testing.Test Bed: An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.Test Case:Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc.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.Test Driven Development: Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.Test Driver: A program or test tool used to execute a tests. Also known as a Test Harness.Test Environment: The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.Test First Design: Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires that programmers do not write any production code until they have first written a unit test.Test Harness: A program or test tool used to execute a tests. Also known as a Test Driver.Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.Test Procedure: A document providing detailed instructions for the execution of one or more test cases.Test Script: Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool.Test Specification: A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.Test Suite: A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by what they are intended to test.Test Tools: Computer programs used in the testing of a system, a component of the system, or its documentation.Thread Testing: A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.Top Down Testing: An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.Total Quality Management: A company commitment to develop a process that achieves high quality product and customer satisfaction.Traceability Matrix: A document showing the relationship between Test Requirements and Test Cases.U (return to top of page)Usability Testing: Testing the ease with which users can learn and use a product.Use Case: The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.User Acceptance Testing: A formal product evaluation performed by a customer as a condition of purchase.Unit Testing: Testing of individual software components.V (return to top of page)Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation is testing, inspection and reviewing.Verification: The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.Volume Testing: Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.W (return to top of page)Walkthrough: A review of requirements, designs or code characterized by the author of the material under review guiding the progression of the review.White Box Testing: Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing. Contrast with Black Box Testing.Workflow Testing: Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by the end-user. 1. http://www.vvasan.net 2. http://arivu.8k.com/tcs2.htm 3. http://freshersworld.com 4. http://members.rediff.com/manux/others/placement/ 5. http://www21.brinkster.com/farzan/papers/index.asp 6. http://www.geocities.com/tejusmanjrekar/papers/papers.html 7. http://www.vyomworld.com/placementpapers/index.asp For other interview questions you can visit any of the followingweb sites: 1. C/C++ Interview Questions: 1. http://www.softcorp.demon.co.uk/c++2.htm 2. http://www.onesmartclick.com/interviews/interviews-programming.html 3. http://www.cpuniverse.com/newsite/archives/1999/mar/c++.html 4. http://www.oneparticularharbor.net/sam/interview.html 5. http://www.acetheinterview.com/cgi-bin/qanda.cgi?action=topics&number=5 6. http://www.geocities.com/Athens/Agora/3027/work/interviewQuestions.html 7. http://www.moskalyuk.com/jobs/cpp_5.htm 8. http://www.moskalyuk.com/jobs/java_1.htm 9. http://www.cs.unc.edu/~scheib/work/questions/ 10. http://www.cis.temple.edu/~ingargio/cis307/assessment/interviews.html 11. http://www.geocities.com/SiliconValley/Park/1512/cpuz_l1.html 2. C/C++ Notes for Interviews: 1. http://leepoint.net/notes/cpp/ 2. http://www.parashift.com/c++-faq-lite/ 3. My Notes 4. http://cslibrary.stanford.edu/ 3. Microsoft Interview Questions: 1. http://halcyon.usc.edu/~kiran/msqs.html 2. http://www.4guysfromrolla.com/ASPscripts/PrintPage.asp?REF=/webtech/012700-1.shtml 3. http://www.sellsbrothers.com/fun/msiview/default.aspx?content=question.htm 4. http://www.acetheinterview.com/qanda/microsoft_interview.html 5. http://bbs.mit.edu/cgi-bin/BBS0an?/groups/GROUP_3/JobHunting/Interview 6. http://www.bucketobits.com/chris/programmerinterviewquestions.html 4. Puzzles: 1. http://www.techinterview.org/archive/ 2. http://puzzle.dse.nl/index_us.html 3. http://www.chlond.demon.co.uk/academic/puzzles.html 4. http://pub13.ezboard.com/fvisualbasicexplorerfrm44 5. Operating Systems Notes: 1. http://williamstallings.com/Extras/OS-Notes/notes.html 2. http://www.ibilce.unesp.br/courseware/opsys/ostart.htm 3. http://www.cs.wisc.edu/~solomon/cs537/notes.html 4. http://www.cs.wisc.edu/~bart/537/lecturenotes/titlepage.html 6. Win32 Tutorials: 1. http://www.winprog.org/tutorial/ 2. http://www.gajits.com/win32.asp 7. Data Structure Notes: 1. http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/ds_ToC.html 2. http://www.csl.mtu.edu/cs2321.rp/www/lectures/cs2321lectures.htm 8. Software Testing Notes: 1. http://louisa.levels.unisa.edu.au/se1/testing-notes/testing.htm 2. http://hebb.cis.uoguelph.ca/~dave/343/Lectures/testing.html 3. http://www.cee.hw.ac.uk/~air/se4/ 4. http://www.darkshire.org/~jhkim/programming/process/testing.html 9. Mathematical Puzzles 1. http://thinks.com/webguide/mathpuzzles.htm 2. http://www.syvum.com/teasers/ 3. http://www.eduplace.com/math/brain/ 4. http://www.brainbashers.com/ 5. http://barryispuzzled.com/ 6. http://www.braingle.com/

HOW TO PREPARE FOR JOB HUNTING
Know What You Want
You should be perfectly clear of what you want. Don't give yourself vague objectives such as "any job that pays." Make your objectives and goals very definite and specific. Your first step to getting a successful job is knowing precisely what you want. Ask yourself this question and write down the answer on a sheet of paper.
Expect the Best But Prepare For Adversity
Always expect success, but prepare for the bad things in life. Adversity happens to the best of us. Our challenge is to conquer adversity. Adversity is a great teacher; learn its lessons well. Remember, if you haven't been through bad times, you are far from success.
Be Positive
When you create a "win, win, win" attitude, you will start to win. When you start to think positively, everything around you will be positive. Whatever you expect to take place will take place. If you want things to be good, they will be good. You are the master of your destiny. Destiny DOES NOT rule you.
Be Confident
You must have confidence in yourself. If you are not confident in yourself, people will not be confident in you. People admire and respect confident people. You will even admire and respect yourself more. If you have doubts about yourself, other people will have doubts about you, also.
YOUR RESUME
A resume is helpful for any type of professional job you are trying out for. A good and effective resume will lead you to personal interviews.
Preparing Your Resume
You must write down a collection of all the information about yourself on a sheet of paper. After all of this information is organized, transfer it to a resume. Only use the training and experience that are relevant to the job which you are applying. Write down all the information that relates to your goal on your data sheet. When you are mentioning jobs that are unrelated to the job you are applying for, be brief. Tell your prospective employer anything and everything that's in your favor and will interest him. Arrange the information so it catches your prospective employer's attention.
To determine what you should put in the beginning of your resume, think of what your potential employer will feel is important. You can organize your experience by job or by function. Your resume should be detailed enough to give an employer all the important facts on you, but it should not be too long or an employer may not read it. Employers are busy people and they want the facts in a few words as possible. When writing out your resume, don't mention anything negative about yourself. If you have never had any work experience and the job calls for work experience, should you put "none" in that section of your resume? No. If you have never had nay previous work experience, don't even include work experience.

Make Your Resume Impressive
Your resume must be typed on a good typewriter. Remember, when a prospective employer looks at a resume he subconsciously relates the quality of your resume with the quality of your work. It is the only thing he sees of you. The most impressive resumes are not five-color jobs on 20-cent paper. If your resume is too flashy, your prospective employer may not be too impressed. Don't pass out carbon copies of your resume because they look cheap and they tell an employer that you gave the original to someone else. Research has shown that resumes printed on yellow paper with brown ink are the most effective. If you don't want to print your resumes, just photocopy them on fancy yellow paper to give them that quality touch.
THE INTERVIEW
What You Should Bring To the Job Interview
Organize and prepare all the papers you will need with you at your job interview. Your main document is your resume.
Here are few tips for you …
1. You’ve likely heard the _expression: Dress for success. Dress in the finest clothes that suit the type of work for which you're applying. If you are going to an interview for outdoor work, wear unworn, casual clothes.
For office or professional positions, dress up conservatively. Ask someone to help you select an outfit from your closet or take a friend from the business world shopping with you, if you're not up on the standards. Don`t go overboard with make-up.
2. Arrive with at least 15 minutes to spare. This will allow you to prepare any last details. (It also shows how keen you are.)
3. If you have an opportunity to shake hands with the person or persons doing the interview, give a firm, solid handshake.
4. Look the interviewer in the eye. You'll find benefit in your ability to communicate, as you look people in the eye more and more. Look directly at the interviewer when you are answering questions.
5. Let your CV talk for you. Make it as interesting as possible and don`t forget to include all interests and hobbies they can say a lot about you. Be truthful.
6. Don't talk while the interviewer is reading your application or CV. The interviewer can only do one thing at a time, even though s/he's a boss.
7. Don`t slouch or fidget you will come across as lazy and nervous
8. Prepare yourself for questions that they might ask you about the company. This will show them how committed you are.
9. Ask questions, but make sure they are sensible ones, not like, how long is the lunch break.
10. Don`t be afraid to make suggestions tell them any ideas you have. This will show them how interested you are.
11. Remember they are human. Be open and honest. Don`t try and be something you are not they will see straight through any facade.
12. Demonstrate your communication skills by listening to the question you are asked. Answer that specific question. If you don't understand the question, ask the interviewer for clarification. Smart people who get ahead have the confidence to ask more questions than sulking people who think they should understand all questions and know all answers.
13. If you are asked why you left your last job don’t go into a story about how awful they where (even if you were treat badly) tell them your talent was wasted and that's why you are there.
14. Let them know how much of an asset you are to the company. But only if you are.
Your References
It is also important to create a list of references. Be prepared to give an employer the names and addresses of three people who are familiar with you and/or your work. You should ask your references for the use of their names in advance. If you think it appropriate, ask a professional friend or former employer to write you a letter of reference, and include it with your resume. If your work is the type of work you can show, take samples of what you have done in the past.
Know the Company and the Employer
Learn all you can about the company that is interviewing you. Go to the library or your Chamber of Commerce to find out all you can about it. Try to find out exactly what they do and what they have in store for you as far as jobs are concerned. Find out who you will be working for. The person you will be working for will be very influential in your life. Make sure you really want to work for this person. If your future boss doesn't tell you about himself at the interview, don't ask.
Know How Much You Should Earn
Know how much you should earn with your talents and skills. Make your estimate a little higher so the company benefits when they bid you down. Don't go too high or you won't get the job. Know approximately what the salary scale is for the job and be ready to negotiate the salary.
Know Yourself
It is important that you know yourself. Evaluate what you can offer this company, whether it is education, training or special skills. Always tell them what you can do, not what you can't do. Know exactly what type of job you are applying for and what type of job you want.
Know Your Interviewer
Prepare yourself for the questions for the questions the interviewer is going to ask you. You should rehearse answers to the most commonly asked questions. Have some one ask you these questions to practice your answers: Why do you want to work here? How long do you want to stay with this company? Why did you leave your last job? Tell me about yourself. Why aren't you working now? How long do you think you would stay in this present job without a promotion? Why should we hire you? What is your greatest strength/weakness? What did you like/dislike about your last job? How much did you earn? How much do you want to earn? Why do you think you can do this job without experience?
Your Appearance and Dress
Don't wear too casual or too formal clothing to the interview. Dress conservatively without flashy colors. Be well groomed and shave for your interview. Women should make sure thy look very neat. Hair should not be in the face, it should be up or tied back. Makeup should be subtle. The way you look is very important to your interviewer. If your appearance is bad for the interview, that is the impression an employer will have of your job performance. Neat appearance is always a must.
What to Do At the Interview
When you shake an employer's hand, shake it firm, solid grip. Don't shake his hand passively. Be business like but pleasant and friendly. Smile throughout the whole interview. Make sure your smile does not look fake. Good eye contact is very important. If you can't look into his eyes, look at the bridge of his nose. This will seem as if you are looking into his eyes. Sit straight up but toward the interviewer. This will make it seem as if you are very interested in what the interviewer has to say. Don't smoke or have poor posture during the interview. If you are under stress, try to act calm.
What to Say at the Interview
Let the employer take charge of the interview. Answer his questions briefly but completely. Don't ramble on about unimportant things and waste his time. Dogmatic statements should be avoided. Tell the employer exactly what you expect from your job and from him. Also tell him exactly what he can expect from you. Stress your qualifications in a positive, affirmative tone. When the employer tells you what type of person is wanted, use this information when telling the employer about your qualifications. It is very important to tell him what he wants to hear. When you tell people what they want to hear, they start to agree with you. Don't over do it and exaggerate with lies. Use your resume or records to support any claim you make about yourself. If you don't understand a question the interviewer asks you, repeat it back to him to see if you understand it. Try to see what the interviewer wants to find out about you. If you know what he wants to find out, make you answers fit his needs.
What Not To Say and Do at the Interview
Talk about previous jobs if they are in your favor. Don't say anything bad or criticize previous employers or fellow workers. If you say anything bad about anyone, your future employer can expect trouble from you. Don't say anything negative about yourself. Try not to discuss anything personal, financial or domestic unless you are specifically asked. If the interviewer questions you at a quick pace with confusing questions, he is doing this to put you under stress. Stay in control and answer calmly. Don't be overly impatient when an employer asks you a question. Wait for him to finish the question and then answer it completely and in a relaxed manner. You don't want an employer to think you are desperate for the job. Don't take anyone with you to the interview--this makes you seem insecure.
At The End of the Interview
If the employer does not offer you the job at the end of the interview, ask him when you will hear from him or when you can call to find out his decision. If you are asked to come back, write down the time and place you are to attend. After the interview thank the employer for spending his time with you. Ask him if he knows of any other company that may need a person with your qualifications. A good practice is to also thank the employer by mail with a "thank you" letter. Many applicants don't do this, so this may give you an edge on the job.
If You Are Hired At the Interview
Make sure that you understand what your duties will be. A good understanding of what your employer expects from you and what you expect from your job will prevent conflicts in the future. Make sure that you are very clear on both of them. You should also find out what advancement opportunities are open for you. Tell the employer what salary you want, but only bring up money when the employer brings up your salary.
If, at the end of the interview, you are not offered the job, tell the interviewer that you really want the job. Follow up with a thank you letter to the interviewer. Tell the interviewer again in the note that you really want the job. If you forgot to mention something in the interview that you thought was important, don't hesitate to mention it in the letter. If the company hasn't contacted you in a week or two, call. If somebody else is hired for the job ask the interviewer if he has any other openings in his company or if he can give you any leads.
WHAT YOU NEED TO GET THAT RAISE
Make the First Move
Don't wait for someone else to tell you what to do. Upper management admires an individual who takes initiative. Develop your individual talents. Educate yourself with new skills and knowledge. Show them that you are a real "go getter."
Make Quick Decisions
Teach yourself to make quick, intelligent decisions. Being indecisive will hurt you. Anyone can make good, quick decisions--it is just a matter of training yourself. Intuitive instincts must be developed.
Seek More Responsibility
Take on the tougher assignments. Actively seek more difficult work with added responsibility. Take on all the responsibility you can handle. Try to take the added responsibilities in addition to your assigned work, the greater your responsibilities, the more you are an asset to management.
Increase Your Interests
The more you know, the more valuable you are to the company you work for. Go to night classes or just read books that will give you that added education. Increase your interest in things that will help your company. Specializing in as many things as you can will help you move up in a company.
Here are some common interview questions with answers.
Q. Tell me about yourself.
A. This is the dreaded, classic, open-ended interview question and likely to be among the first. It's your chance to introduce your qualifications, good work habits, etc. Keep it mostly work and career related.
Q. Why do you want to leave your current job? (Why did you leave your last job?)
A. Be careful with this. Avoid trashing other employers and making statements like, "I need more money." Instead, make generic statements such as, "It's a career move."
Q. What are your strengths?
A. Point out your positive attributes related to the job.
Q. What are your weaknesses?
A. Everybody has weaknesses, but don't spend too much time on this one and keep it work related. Along with a minor weakness or two, try to point out a couple of weaknesses that the interviewer might see as strengths, such as sometimes being a little too meticulous about the quality of your work. (Avoid saying "I work too hard." It's a predictable, common answer.) For every weakness, offer a strength that compensates for it.
Q. Which adjectives would you use to describe yourself?
A. Answer with positive, work-oriented adjectives, such as conscientious, hard-working, honest and courteous, plus a brief description or example of why each fits you well.
Q. What do you know about our company? A. To answer this one, research the company before you interview.
Q. Why do you want to work for us?
A. Same as above. Research the company before you interview. Avoid the predictable, such as, "Because it's a great company." Say why you think it's a great company.
Q. Why should I hire you?
A. Point out your positive attributes related to the job, and the good job you've done in the past. Include any compliments you've received from management.
Q. What past accomplishments gave you satisfaction?
A. Briefly describe one to three work projects that made you proud or earned you pats on the back, promotions, raises, etc. Focus more on achievement than reward.
Q. What makes you want to work hard?
A. Naturally, material rewards such as perks, salary and benefits come into play. But again, focus more on achievement and the satisfaction you derive from it.
Q. What type of work environment do you like best?
A. Tailor your answer to the job. For example, if in doing your job you're required to lock the lab doors and work alone, then indicate that you enjoy being a team player when needed, but also enjoy working independently. If you're required to attend regular project planning and status meetings, then indicate that you're a strong team player and like being part of a team.
Q. Why do you want this job?
A. To help you answer this and related questions, study the job ad in advance. But a job ad alone may not be enough, so it's okay to ask questions about the job while you're answering. Say what attracts you to the job. Avoid the obvious and meaningless, such as, "I need a job."
Q. How do you handle pressure and stress?
A. This is sort of a double whammy, because you're likely already stressed from the interview and the interviewer can see if you're handling it well or not. Everybody feels stress, but the degree varies. Saying that you whine to your shrink, kick your dog or slam down a fifth of Jack Daniels are not good answers. Exercising, relaxing with a good book, socializing with friends or turning stress into productive energy are more along the lines of the "correct" answers.
Q. Explain how you overcame a major obstacle.
A. The interviewer is likely looking for a particular example of your problem-solving skills and the pride you show for solving it.
Q. Where do you see yourself five (ten or fifteen) years from now?
A. Explain your career-advancement goals that are in line with the job for which you are interviewing. Your interviewer is likely more interested in how he, she or the company will benefit from you achieving your goals than what you'll get from it, but it goes hand in hand to a large degree. It's not a good idea to tell your potential new boss that you'll be going after his or her job, but it's okay to mention that you'd like to earn a senior or management position.
Q. What qualifies you for this job?
A. Tout your skills, experience, education and other qualifications, especially those that match the job description well. Avoid just regurgitating your resume. Explain why.
Conclusion
Be Confident
If you don't have confidence in yourself, others will not have confidence in you, either. People admire and respect confident people. If you show others doubt, they will treat you with doubt. Be sure of yourself and play down your insecurities.
Getting a job can be very easy if you look for it the right way. Knowing exactly what you want and then going after it will always get you what you want. Be positive, determined and persistent so that you will benefit, be rewarded and prosper.
COMMON Interview Questions:

1. Tell me about yourself.
Keep your answer short and focused on your professional life. This is not the time to bring up relationships, childhood experiences, family etc. A brief history of education, career and special interests is what is called for here. End it with why you are interested in this particular job.

2. Why are you applying for this particular job?
Show interest and demonstrate that you have researched the job and know what you are getting into. Bring up evidence from past work/ studies that supports your interest in this role and any skills you have acquired in preparation for the role. You can say something like 'I would like to work for a leader in innovative network and telecommunications solutions and my college degree in computational mathematics has given me a solid background for this role. Mention the value-added you can bring to the job.

3. What do you know about our company?
Indicate what you have learnt from your research activities - from their annual reports,
newspapers, word of mouth, other employees etc. Use this to flatter them and show that you have done your homework.

4. What makes you qualified for this particular job?
Again, explain that you are very interested in the job and demonstrate what it is about your past experiences, education and qualifications that makes you ideal for the job. Show enthusiasm and support your answers with evidence wherever you can (eg. my summer internship at Citibank gave me broad exposure to the area of equity analysis and I think I can apply many of the tools I learnt there in this job). Elaborate on all the past experiences and skill sets that make you suitable for the job.In cases where your past experience is not directly relevant, you can still find elements of it that can be useful. Play up teamskills, computer skills, leadership roles, specific courses and independent research activities that can be useful to the job at hand to show your initiative even where you don't have directly relevant job experience.

5. What can you do for us that someone else can't?
Demonstrate key strengths, skills and personal characteristics.

6. Why should we hire you?
See 3. Because you have all the experience/ traits/ credentials demonstrated in 3 and in addition to being qualified, you are enthusiastic, intelligent, hardworking, flexible and willing to learn. Also mention any key relationships you may have that may assist you in the job.

7. What do you look for in a job?
Be honest. Also mention keywords such as challenging, steep learning curve, good work culture, demanding, rewarding, opportunities for advancement and growth, team environment, opportunity to build and maintain client relationships etc.

8. Why are you looking to make a career change?
Mention your interests and make sure you bring up all skills/ experience however insignificant that can support your move in this new direction. It is quite common in this day and age to make a career switch. You need however to show that you have very carefully thought about the change, have a strong interest in the new career and can use some of your previous skills/ education/ relationships to make that move.

9. Why did you leave your last job?
Do NOT use this as an opportunity to badmouth past employers or peers or talk about a failure of any sort. Any of these answers are acceptable: you were looking for a new challenge, your learning curve had flattened out in the previous job and you were looking for a new learning opportunity, the company or department were restructuring, you were ready to start something new after achieving your career goals at the previous company etc.

10. Why do you want to work for us (as opposed to the competitor companies)?
Demonstrate that you know something about the company, that you believe they are leaders/ innovators in what they do, or you think their work culture is exactly what you are looking for, or you like their product(s) or you have friends who work there and have always been attracted to the company etc. Flatter the company and show you know something about it.

11. How long will it take you to start making a meaningful contribution?
Show that you are enthusiastic and willing to learn and will put in all the hours and effort necessary to learn the ropes and start making an immediate contribution. Indicate that your past experiences/ skills/ credentials will enable you to make an immediate contribution at some level while you quickly learn all new aspects of the job. An Interviewer wants someone who is willing and able to learn and will make a return on his investment sooner rather than later.

12. What are your strengths?
See 14 below. In addition, keywords such as good teamplayer, work very well under pressure, very creative, very strong quantitative or computer skills, and very strong client relationship skills may be appropriate depending on your chosen field.

13. What are your weaknesses?
Do NOT mention key weaknesses here. This is not the place to say you are bad at meeting deadlines or you never mastered highschool mathematics etc. Turn this question around to your benefit. For example, you are 'overambitious' or 'extremely attentive to detail' or 'like to take on too many projects'. Make it sound positive.

14. What are your career goals?
Show you have thought forward and are committed to your career.

15. How would you describe yourself?
Any of these are good examples of attributes employers are looking for: intelligent, hardworking, quick to learn, enthusiastic, honest, efficient, productive, ambitious, successful, compassionate (in the medical fields).

16. How would your colleagues describe you?
Do not bring up anything negative here.

17. How would your boss describe you?
They will check references anyways so bring up the most positive attribute you can think of about yourself eg hardworking, honest etc. and leave it to your Boss to say anything to the contrary.

18. What did you most like/ dislike about your past job?
Do not use this to badmouth past jobs/ employers. Keep it light and in your favour eg I outgrew the job, there wasn't a clear career progression, I wasn't learning anything new etc. Ideally, you will have loved your last job and would like to achieve the same kind of success and job satisfaction in a more challenging area as you have now 'outgrown' that job and are ready for 'new challenges'.

19. Describe a situation in your past where you showed initiative?
You could describe any new methods you came up with to do your job or to save money for the company or to turn around a bad situation. It can be something as simple as changing a filing system, or establishing a relationship with a vendor that saved your department a lot of money. If you are in sales, you may want to talk about how you brought in that big account. Creatives may talk about how they came up with that cutthroat image or design that brought in the business.

20. What were your main responsibilities in your last job?
Have these ready and list them all. Dwell on the ones that are most relevant to the new job. This answer should be smooth and practiced.

21. What do you consider your greatest accomplishments?
Many of us have one or two milestones in our career that we are very proud of eg. that early promotion, that 'huge' deal we brought in, the design we came up with, the costs we saved, the revenues we increased, the people we trained, a new invention or process we came up with etc.
Examples of accomplishments may be: 'Reduced costs by X%; or renamed and repositioned a product at the end of its lifecycle, or organized and led a team to do do XYZ, or achieved sales increase of
X% etc. If you are a fresh college graduate, talk about extracurricular activities, leadership roles and grades.

22. Describe your management style (if relevant)
No answer

23. Do you work better in teams or independently?
Show that you are a proactive teamplayer and like to bounce ideas off others and get input; however you are very capable of working independently (give examples).

24. How do you work under pressure?
Well. Give evidence.

25. What other jobs have you applied for?
Don't mention jobs in different career directions (eg advertising and investment banking). Do however bring up any other offers or Interviews from competing firms.

26. How did you do in college?
Keep it positive. It's okay to say you were very busy making the most of college and were very involved in sports, activities, social life etc. Employers want human beings not robots. Mention the areas you did very well in even if it was just one or two courses you excelled in. They will check for themselves.

27. What kind of hours would you like to work?
Employers want to see flexibility. Indicate you are willing to put in whatever hours are necessary to finish the job. Do however mention any constraints you have eg. you would like to be home to pick your kids up from school at 3:30. Most employers are willing to work around your constraints if you show flexibility on your side as well.

28. Do you have any questions for me?
YES you do. Questions engage the Interviewer and show your interest. Ask questions that show you know something about the company or the job, that you are planning ahead, that you are anxious and willing to learn the ropes and that you are committed to the position.


http://www.programmersheaven.com
http://www.codeproject.com/vb/net/
http://www.planetsources.com
http://www.dotnetindex.com
http://www.codersource.net/aspnet_sample_application.html
http://www.computer-mentors.co.uk/messagelist.html
http://www.dbxtra.com/ Crystal reports

--Very useful site for ASP.NET
http://aspalliance.com/
http://aspalliance.com/509 Automatically printing crystal reports in ASP.NET
http://aspalliance.com/crystal/default.aspx
http://aspalliance.com/crystal/redir.aspx?ArticleURL=http://www.codeproject.com/aspnet/crystal_report.asp

Directory of ASP.NET Resources
http://www.123aspx.com/ReadReviews.aspx?res=30160


http://www.businessobjects.com/products/dev_zone/net/default.asp?ref=devzone_main
http://www.crystalreportsbook.com
http://www.dbnetgrid.com/dbnetgrid/default.aspx
http://www.asp.net/IEWebControls/Download.aspx?tabindex=0&tabid=1
http://www.asp.net/Modules/MoreCommunities.aspx?tabindex=0&mid=79

how to export crystal report to pdf format.
http://www.c-sharpcorner.com/Code/2004/May/ExportCrystalReportInASPNET.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/crystlmn/html/crconcrystalreports.asp

Good one to look
http://www.dotnetspider.com/technology/kbpages/842.aspx

http://www.learnxpress.com/modules/index.aspx

ADO.NET
http://www.sitepoint.com/subcat/asp
http://www.sitepoint.com/article/introduction-ado-net
http://www.datadirect.com/developer/net/basics/index.ssp
Resources
■ QTP 5.6 or 6.0 Readme
■ QTP 5.6 or 6.0 Knowledge Base Articles
■ QTP 5.6 or 6.0 Installation Guide
■ QTP 5.6 or 6.0 Tutorial
■ QTP 5.6 or 6.0 Object Model Reference
■ QTP 5.6 or 6.0 Help
■ Microsoft VBScript Reference
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/
vtoriVBScript.asp
■ Microsoft VBScript Users Guide
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/
vtoriVBScript.asp
■ Microsoft MSDN Library: Programming with VBScript
http://msdn.microsoft.com/library/default.asp?URL=/library/partbook/egvb6/
programmingwithvbscript.htm
■ VB & VBA in a Nutshell: The Language by Paul Lomax ISBN: 1-56592-358-8
■ Sun Java Developers Center: http://java.sun.com
■ JavaScript for the Total Non-Programmer
http://www.webteacher.com/javascript/
■ http://www.w3c.org

Testing Links
http://www.perftestplus.com/eval.htm
http://www.testingeducation.org/articles/

http://www.acomtech.com/testdevl.html
http://geekswithblogs.net/dthakur/archive/2004/08/20/9958.aspx
http://geekswithblogs.net/dthakur/articles/10085.aspx
http://geekswithblogs.net/dthakur/articles/6475.aspx


http://www.goau.com/

http://www.ebroadcast.com.au/dir/Computers/Programming/Software_Testing/
Subject: imp link test
http://www.qualitytree.com/links/links.htm
http://www.iso.ch/iso/en/iso9000-14000/iso9000/qmp.html


Interoperability Testing: which measures the ability of your software to communicate across the network on multiple machines from multiple vendors each of whom may have interpreted a design specification critical to your success differently.Inter-operability Testing: True inter-operability testing concerns testing for unforeseen interactions with other packages with which your software has no direct connection. In some quarters, inter-operability testing labor equals all other testing combined. This is the kind of testing that I say shouldn’t be done because it can’t be done.Scalability Testing: is a subtype of performance test where performance requirements for response time, throughput, and/or utilization are tested as load on the SUT is increased over time.
Numerous IT organizations have reported their success with process improvement based on the SEI CMM/CMMI framework. However, the CMM and CMMI models have very little practices addressing the test process. This motivated the software testing community to develop their own TEST process maturity models. Following are the test process assessment and improvement models:TPAM CMM-Companion Test Process Assessment Model;TMM Testing Maturity Model; andTPI Test Process Improvement Model

Some deails about TMM: http://www.stsc.hill.af.mil/consulting/show_ct_article.asp?uri=2002/11/staab.html

http://www.rspa.com/spi/index.htmlhttp://www.w3.org/Security/Faq/index.html#contentshttp://www.iturls.com/English/SoftwareEngineering/WE_d.asp
Pierce Business Systemshttp://www.pb-sys.com/ Software Description Buggit manages bugs and features throughout the software development process. Testers, developers, and managers can all benefit greatly from the use of Buggit. They can enter and edit bugs/features, perform quick lookups of existing issues, print from a wide variety of powerful reports and graphs (see screen shot links at PBSystems webpage), administer new bug project databases, and much more. Buggit provides an unlimited number of central, multi-user databases, each capable of handling mulitple concurrent users across the development team. Platforms Windows Entry updated February 3, 2003.

MantisKind of Tool Bug tracking system (freeware) Organization Mantis projecthttp://mantisbt.sourceforge.net/ Software Description A php/MySQL/web based bug tracking system. Beta status. Platforms Unix, Windows. Entry updated February 3, 2003.Return to Listings

AbukyKind of Tool Bug tracking system (freeware) Organization Abuky projecthttp://abuky.sunsite.dk/index.html Software Description Abuky stands for the Aoo BUg tracKing sYstem, while AOO stands for Art Of Open Source. Abuky is a system for tracking bugs and aiding the developer to fix them, written in Java with JSP as web interface. Platforms Linux, Solaris, Windows 98, Windows 2000 Entry updated February 3, 2003.

Automation The process of writing a set of instructions that are designed, scripted, tested, and checked in by a person, then executed by a machine, to produce results that can be analyzed.Acceptance Testing Is the process of comparing a program to its requirementsAd - Hoc testing Appropriate and very often syndicated when tester wants to become familiar with the product, or in the environment when technical/testing materials are not 100% completed. It is also largely based on general software product functionality/testing understanding and the normal 'Human Common Sense'.Automation The process of writing a set of instructions that are designed, scripted, tested, and checked in by a person, then executed by a machine, to produce results that can be analyzed.B - CBuild Acceptance Test The build acceptance test is a simplistic check of a product's functionality in order to determine if the product is capable of being tested to a greater extent. Every new build should undergo a build acceptance test to determine if further testing can be executed. Examples of a build acceptance:Product can be installed with no crashes or errors that terminate the installation. (Development needs to install the software from the same source accessed byQA (e.g. Drop Zone, CD-ROM, Electronic Software Distribution archives, etc.).Clients can connect to associated servers.Simple client server communication can be achievedBottom - up Start testing with the bottom of the program. The bottom - up strategy does not exist until the last module is added.client The client part of a client-server architecture. Typically, a client is an application that runs on a personal computer or workstation and relies on a server to perform some operations.Client-Server Testing Systems that operate in client/server environments.Compatibility Test This test is used to test compatibility between different client/server version combinations as well as other supported products.Confidence Test The confidence test ensures a product functions as expected by ensuring platform specific bugs are not introduced and functionality has not regressed from drop to drop. A typical confidence test is designed to touch all major areas of a product's functionality. These tests are run regularly once the Functional Freeze milestone is reached throughout the remaining development cycle.Configuration Tests These tests are run for product testing across various system configuration combinations. Examples of configurations:Cross platform (e.g. Windows Clients against a UNIX server).Client/server network configurations. Operating systems and database combinations (also including version combinations).Web servers and web browsers (for web products). The system configurations to test are determined from the product's compatibility matrix. This test is sometimes called a 'Platform test'.CET (Customer Experience Test)An in-house test is performed before the Alpha, Beta, and FCS milestones which is used to determine whether the product can be installed and used without any problems, assistance, or support from others.D - EDebug An attempt to determine the cause of the symptoms of malfunctions detected by testing or by frenzied user complaints.Event-Driven Testing event-driven processes, such as unpredictable sequences of interrupts from input devices or sensors, or sequences of mouse clicks in a GUI environment.F - GFinal Installation Test Verification that the final media, prior to hand off to Operations for duplication, contains the correct code which was previously tested and is installable on all the supported platforms and databases. The product demo is executed and product Release Notes verified.Functionality Test This is designed to test the full functionality, features, and user interfaces of software based upon the functional specifications.Graphical User Interface (GUI) Testing the front-end user interfaces to applications which use GUI support systems and standard such as MS Windows or Motif.GUI Roadmaps Step by step walk through of a tool or application, exercising each screen or window's menus, toolbar and dialog boxes to verify the execution and correctness of the Graphical User Interface. Typically, this is handled by automated scripts and rarely is used as a manual tests due to the low numbers of bugs found from them.H - IInternationalization The process whereby software, which was ordinarily designed to operate within a single language or locale, is enhanced with capabilities and features which allow general support of a broad range of languages or locales. This usually implies the implementation of internal functions which would have been required to implement all of the locales within the range of locales, without committing to a particular one, as well as providing a mechanism for easily "plugging in" strings of the different languages. Use of the "globalized" software for a specific locale will then require relatively simple "localization" work.J - k - l - m - n - OModule testing To test large program its necessary to use module testing. Module testing (or unit testing) is a process of testing individual subprograms (small blocks), rather than testing the program as a whole. Module testing eases the task of debugging. When error is found, it is known is which particular module it is.Object A defined Windows control, such as a window, dialog box, check box, label, grid, radio button, or command button. Applications may also contain custom objects that conform to Windows object programming standards.Object-Ooriented Testing systems designed or coded using an object-oriented approach or development environment, such as C++ or Smalltalk.PParallel Testing Testing by processing the same (or at least closely comparable) test workload against both the existing and new versions of a product, then comparing results.Performance Measurement and prediction of performance (e.g. Response time and/or throughput) for a given benchmark workload.Phased ApproachA testing strategy where test cases are developed in stages so a minimally acceptable level of testing can be completed at any time. As new features are coded and frozen, they receive priorities for a given amount of time-so that a concentrated effort is directed toward testing those new features before the effort returns to validate the preexisting functionality. When no new features are available, preexisting features will be targeted-with priorities set by Project Leads.1st level - Minimal Acceptance Test2nd level - Confidence Tests3rd level - Full Functionality Test4th level - Error, Negative, and other Tests5th level - System level testsQQA A.K.A. Quality Assurance. Also known as Software Test. This is the group that performs methodical testing of the products developed by engineering. They make no statement of the quality of the product and no guaranty of finding all the bugs in a product. Their job is to take an independent approach to evaluating the product and open bugs against anything they think is broken or not performing as a reasonable end user might expect.Quality The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs. Not to be mistaken for "degree of excellence" or "fitness for use" which meet only part of the definition.RRegression Tests These tests are used for comprehensive re-testing of software to validate that all functionality and features of previous builds (or releases) have maintained integrity of features and functions tested previously. This suite of tests includes the Full Functionality Tests and bug Regression Tests (automated and manual).SSanity Test Sanity tests are subsets of the confidence test and are used only to validate high-level functionality.Security Testing It is a test how easy to break program's security system.Server A computer or device on a network that manages network resources. For example, a file server is a computer and storage device dedicated to storing files.Stress Test These tests are used to validate software functionality at the limit (e.g. Maximum throughput) and then testing at and beyond these limits.System Level Test These tests check for factors such as Cross-Tool testing, memory management and other operating system factors.T - u - v - w - x - y - ZTest The process of exercising a product to identify differences between expected and actual behavior.Test Requirement An operation, property, or behavioral characteristic of the app-under-test that must be verified.Top - Down strategy Start testing with the top of the program.Volume Testing Is the process of feeding a program with heavy volume of data.Usability The effectiveness, efficiency, and satisfaction with which specified users can achieve specified goals in a particular environment. Synonymous with "ease of use".Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.Accessibility Testing: Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.Application Programming Interface (API): A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve software quality.Automated Testing:Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.B (return to top of page)Backus-Naur Form: A metalanguage used to formally describe the syntax of a language.Basic Block: A sequence of one or more consecutive, executable statements containing no branches.Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to design tests.Basis Set: The set of tests derived using basis path testing.Baseline: The point at which some deliverable produced during the software engineering process is put under formal change control.Beta Testing: Testing of a rerelease of a software product conducted by customers.Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.Black Box Testing: Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.Boundary Testing: Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner.Boundary Value Analysis: BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out of range as defined by the specification. his means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.Branch Testing: Testing in which all branches in the program source code are tested at least once.Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.C (return to top of page)CAST: Computer Aided Software Testing.Capture/Replay Tool: A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.CMM: The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.Cause Effect Graph: A graphical representation of inputs and the associated outputs effects which can be used to design test cases.Code Complete: Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.Code Coverage: An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.Code Inspection: A formal testing technique where the programmer reviews source code with a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.Coding: The generation of source code.Compatibility Testing: Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.Component: A minimal software item for which a separate specification is available.Component Testing: See Unit Testing.Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.Conformance Testing: The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.Context Driven Testing: The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in replacement systems.Cyclomatic Complexity: A measure of the logical complexity of an algorithm, used in white-box testing.D (return to top of page)Data Dictionary: A database that contains definitions of all data items defined during analysis.Data Flow Diagram: A modeling notation that represents a functional decomposition of a system.Data Driven Testing: Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.Debugging: The process of finding and removing the causes of software failures.Defect: Nonconformance to requirements or functional / program specificationDependency Testing: Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.Depth Testing: A test that exercises a feature of a product in full detail.Dynamic Testing: Testing software through executing it. See also Static Testing.E (return to top of page)Emulator: A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.Endurance Testing: Checks for memory leaks or other problems that may occur with prolonged execution.End-to-End testing: Testing 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.Equivalence Class: A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.Equivalence Partitioning: A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.Exhaustive Testing: Testing which covers all combinations of input values and preconditions for an element of the software under test.F (return to top of page)Functional Decomposition: A technique used during planning, analysis and design; creates a functional hierarchy for the software.Functional Specification: A document that describes in detail the characteristics of the product with regard to its intended features.Functional Testing: See also Black Box Testing.Testing the features and operational behavior of a product to ensure they correspond to its specifications.Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.G (return to top of page)Glass Box Testing: A synonym for White Box Testing.Gorilla Testing: Testing one particular module,functionality heavily.Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings.H (return to top of page)High Order Tests: Black-box tests conducted once the software has been integrated.I (return to top of page)Independent Test Group (ITG): A group of people whose primary responsibility is software testing,Inspection: A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).Integration Testing: Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.Installation Testing: Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.J (return to top of page)K (return to top of page)L (return to top of page)Load Testing: See Performance Testing.Localization Testing: This term refers to making software specifically designed for a specific locality.Loop Testing: A white box testing technique that exercises program loops.M (return to top of page)Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.Monkey Testing: Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.N (return to top of page)Negative Testing: Testing aimed at showing software does not work. Also known as "test to fail". See also Positive Testing.N+1 Testing: A variation of Regression Testing. Testing conducted with multiple cycles in which errors found in test cycle N are resolved and the solution is retested in test cycle N+1. The cycles are typically repeated until the solution reaches a steady state and there are no errors. See also Regression Testing.O (return to top of page)P (return to top of page)Path Testing: Testing in which all paths in the program source code are tested at least once.Performance Testing: Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".Positive Testing: Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.Q (return to top of page)Quality Assurance: All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer.Quality Audit: A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.Quality Circle: A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.Quality Control: The operational techniques and the activities used to fulfill and verify requirements of quality.Quality Management: That aspect of the overall management function that determines and implements the quality policy.Quality Policy: The overall intentions and direction of an organization as regards quality as formally expressed by top management.Quality System: The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.R (return to top of page)Race Condition: A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.Ramp Testing: Continuously raising an input signal until the system breaks down.Recovery Testing: Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.Regression Testing: Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.Release Candidate: A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).S (return to top of page)Sanity Testing: Brief test of major functional elements of a piece of software to determine if its basically operational. See also Smoke Testing.Scalability Testing: Performance testing focused on ensuring the application under test gracefully handles increases in work load.Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.Smoke Testing: A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.Soak Testing: Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.Software Requirements Specification: A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software/Software Testing: A set of activities conducted with the intent of finding errors in software.Static Analysis: Analysis of a program carried out without executing the program.Static Analyzer: A tool that carries out static analysis.Static Testing: Analysis of a program carried out without executing the program.Storage Testing: Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.Structural Testing: Testing based on an analysis of internal workings and structure of a piece of software. See also White Box Testing.System Testing: Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.T (return to top of page)Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.Testing:The process of exercising software to verify that it satisfies specified requirements and to detect errors.The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829).The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.Test Automation: See Automated Testing.Test Bed: An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.Test Case:Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc.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.Test Driven Development: Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.Test Driver: A program or test tool used to execute a tests. Also known as a Test Harness.Test Environment: The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.Test First Design: Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires that programmers do not write any production code until they have first written a unit test.Test Harness: A program or test tool used to execute a tests. Also known as a Test Driver.Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.Test Procedure: A document providing detailed instructions for the execution of one or more test cases.Test Script: Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool.Test Specification: A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.Test Suite: A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by what they are intended to test.Test Tools: Computer programs used in the testing of a system, a component of the system, or its documentation.Thread Testing: A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.Top Down Testing: An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.Total Quality Management: A company commitment to develop a process that achieves high quality product and customer satisfaction.Traceability Matrix: A document showing the relationship between Test Requirements and Test Cases.U (return to top of page)Usability Testing: Testing the ease with which users can learn and use a product.Use Case: The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.User Acceptance Testing: A formal product evaluation performed by a customer as a condition of purchase.Unit Testing: Testing of individual software components.V (return to top of page)Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation is testing, inspection and reviewing.Verification: The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.Volume Testing: Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.W (return to top of page)Walkthrough: A review of requirements, designs or code characterized by the author of the material under review guiding the progression of the review.White Box Testing: Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing. Contrast with Black Box Testing.Workflow Testing: Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by the end-user. 1. http://www.vvasan.net 2. http://arivu.8k.com/tcs2.htm 3. http://freshersworld.com 4. http://members.rediff.com/manux/others/placement/ 5. http://www21.brinkster.com/farzan/papers/index.asp 6. http://www.geocities.com/tejusmanjrekar/papers/papers.html 7. http://www.vyomworld.com/placementpapers/index.asp For other interview questions you can visit any of the followingweb sites: 1. C/C++ Interview Questions: 1. http://www.softcorp.demon.co.uk/c++2.htm 2. http://www.onesmartclick.com/interviews/interviews-programming.html 3. http://www.cpuniverse.com/newsite/archives/1999/mar/c++.html 4. http://www.oneparticularharbor.net/sam/interview.html 5. http://www.acetheinterview.com/cgi-bin/qanda.cgi?action=topics&number=5 6. http://www.geocities.com/Athens/Agora/3027/work/interviewQuestions.html 7. http://www.moskalyuk.com/jobs/cpp_5.htm 8. http://www.moskalyuk.com/jobs/java_1.htm 9. http://www.cs.unc.edu/~scheib/work/questions/ 10. http://www.cis.temple.edu/~ingargio/cis307/assessment/interviews.html 11. http://www.geocities.com/SiliconValley/Park/1512/cpuz_l1.html 2. C/C++ Notes for Interviews: 1. http://leepoint.net/notes/cpp/ 2. http://www.parashift.com/c++-faq-lite/ 3. My Notes 4. http://cslibrary.stanford.edu/ 3. Microsoft Interview Questions: 1. http://halcyon.usc.edu/~kiran/msqs.html 2. http://www.4guysfromrolla.com/ASPscripts/PrintPage.asp?REF=/webtech/012700-1.shtml 3. http://www.sellsbrothers.com/fun/msiview/default.aspx?content=question.htm 4. http://www.acetheinterview.com/qanda/microsoft_interview.html 5. http://bbs.mit.edu/cgi-bin/BBS0an?/groups/GROUP_3/JobHunting/Interview 6. http://www.bucketobits.com/chris/programmerinterviewquestions.html 4. Puzzles: 1. http://www.techinterview.org/archive/ 2. http://puzzle.dse.nl/index_us.html 3. http://www.chlond.demon.co.uk/academic/puzzles.html 4. http://pub13.ezboard.com/fvisualbasicexplorerfrm44 5. Operating Systems Notes: 1. http://williamstallings.com/Extras/OS-Notes/notes.html 2. http://www.ibilce.unesp.br/courseware/opsys/ostart.htm 3. http://www.cs.wisc.edu/~solomon/cs537/notes.html 4. http://www.cs.wisc.edu/~bart/537/lecturenotes/titlepage.html 6. Win32 Tutorials: 1. http://www.winprog.org/tutorial/ 2. http://www.gajits.com/win32.asp 7. Data Structure Notes: 1. http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/ds_ToC.html 2. http://www.csl.mtu.edu/cs2321.rp/www/lectures/cs2321lectures.htm 8. Software Testing Notes: 1. http://louisa.levels.unisa.edu.au/se1/testing-notes/testing.htm 2. http://hebb.cis.uoguelph.ca/~dave/343/Lectures/testing.html 3. http://www.cee.hw.ac.uk/~air/se4/ 4. http://www.darkshire.org/~jhkim/programming/process/testing.html 9. Mathematical Puzzles 1. http://thinks.com/webguide/mathpuzzles.htm 2. http://www.syvum.com/teasers/ 3. http://www.eduplace.com/math/brain/ 4. http://www.brainbashers.com/ 5. http://barryispuzzled.com/ 6. http://www.braingle.com/

HOW TO PREPARE FOR JOB HUNTING
Know What You Want
You should be perfectly clear of what you want. Don't give yourself vague objectives such as "any job that pays." Make your objectives and goals very definite and specific. Your first step to getting a successful job is knowing precisely what you want. Ask yourself this question and write down the answer on a sheet of paper.
Expect the Best But Prepare For Adversity
Always expect success, but prepare for the bad things in life. Adversity happens to the best of us. Our challenge is to conquer adversity. Adversity is a great teacher; learn its lessons well. Remember, if you haven't been through bad times, you are far from success.
Be Positive
When you create a "win, win, win" attitude, you will start to win. When you start to think positively, everything around you will be positive. Whatever you expect to take place will take place. If you want things to be good, they will be good. You are the master of your destiny. Destiny DOES NOT rule you.
Be Confident
You must have confidence in yourself. If you are not confident in yourself, people will not be confident in you. People admire and respect confident people. You will even admire and respect yourself more. If you have doubts about yourself, other people will have doubts about you, also.
YOUR RESUME
A resume is helpful for any type of professional job you are trying out for. A good and effective resume will lead you to personal interviews.
Preparing Your Resume
You must write down a collection of all the information about yourself on a sheet of paper. After all of this information is organized, transfer it to a resume. Only use the training and experience that are relevant to the job which you are applying. Write down all the information that relates to your goal on your data sheet. When you are mentioning jobs that are unrelated to the job you are applying for, be brief. Tell your prospective employer anything and everything that's in your favor and will interest him. Arrange the information so it catches your prospective employer's attention.
To determine what you should put in the beginning of your resume, think of what your potential employer will feel is important. You can organize your experience by job or by function. Your resume should be detailed enough to give an employer all the important facts on you, but it should not be too long or an employer may not read it. Employers are busy people and they want the facts in a few words as possible. When writing out your resume, don't mention anything negative about yourself. If you have never had any work experience and the job calls for work experience, should you put "none" in that section of your resume? No. If you have never had nay previous work experience, don't even include work experience.

Make Your Resume Impressive
Your resume must be typed on a good typewriter. Remember, when a prospective employer looks at a resume he subconsciously relates the quality of your resume with the quality of your work. It is the only thing he sees of you. The most impressive resumes are not five-color jobs on 20-cent paper. If your resume is too flashy, your prospective employer may not be too impressed. Don't pass out carbon copies of your resume because they look cheap and they tell an employer that you gave the original to someone else. Research has shown that resumes printed on yellow paper with brown ink are the most effective. If you don't want to print your resumes, just photocopy them on fancy yellow paper to give them that quality touch.
THE INTERVIEW
What You Should Bring To the Job Interview
Organize and prepare all the papers you will need with you at your job interview. Your main document is your resume.
Here are few tips for you …
1. You’ve likely heard the _expression: Dress for success. Dress in the finest clothes that suit the type of work for which you're applying. If you are going to an interview for outdoor work, wear unworn, casual clothes.
For office or professional positions, dress up conservatively. Ask someone to help you select an outfit from your closet or take a friend from the business world shopping with you, if you're not up on the standards. Don`t go overboard with make-up.
2. Arrive with at least 15 minutes to spare. This will allow you to prepare any last details. (It also shows how keen you are.)
3. If you have an opportunity to shake hands with the person or persons doing the interview, give a firm, solid handshake.
4. Look the interviewer in the eye. You'll find benefit in your ability to communicate, as you look people in the eye more and more. Look directly at the interviewer when you are answering questions.
5. Let your CV talk for you. Make it as interesting as possible and don`t forget to include all interests and hobbies they can say a lot about you. Be truthful.
6. Don't talk while the interviewer is reading your application or CV. The interviewer can only do one thing at a time, even though s/he's a boss.
7. Don`t slouch or fidget you will come across as lazy and nervous
8. Prepare yourself for questions that they might ask you about the company. This will show them how committed you are.
9. Ask questions, but make sure they are sensible ones, not like, how long is the lunch break.
10. Don`t be afraid to make suggestions tell them any ideas you have. This will show them how interested you are.
11. Remember they are human. Be open and honest. Don`t try and be something you are not they will see straight through any facade.
12. Demonstrate your communication skills by listening to the question you are asked. Answer that specific question. If you don't understand the question, ask the interviewer for clarification. Smart people who get ahead have the confidence to ask more questions than sulking people who think they should understand all questions and know all answers.
13. If you are asked why you left your last job don’t go into a story about how awful they where (even if you were treat badly) tell them your talent was wasted and that's why you are there.
14. Let them know how much of an asset you are to the company. But only if you are.
Your References
It is also important to create a list of references. Be prepared to give an employer the names and addresses of three people who are familiar with you and/or your work. You should ask your references for the use of their names in advance. If you think it appropriate, ask a professional friend or former employer to write you a letter of reference, and include it with your resume. If your work is the type of work you can show, take samples of what you have done in the past.
Know the Company and the Employer
Learn all you can about the company that is interviewing you. Go to the library or your Chamber of Commerce to find out all you can about it. Try to find out exactly what they do and what they have in store for you as far as jobs are concerned. Find out who you will be working for. The person you will be working for will be very influential in your life. Make sure you really want to work for this person. If your future boss doesn't tell you about himself at the interview, don't ask.
Know How Much You Should Earn
Know how much you should earn with your talents and skills. Make your estimate a little higher so the company benefits when they bid you down. Don't go too high or you won't get the job. Know approximately what the salary scale is for the job and be ready to negotiate the salary.
Know Yourself
It is important that you know yourself. Evaluate what you can offer this company, whether it is education, training or special skills. Always tell them what you can do, not what you can't do. Know exactly what type of job you are applying for and what type of job you want.
Know Your Interviewer
Prepare yourself for the questions for the questions the interviewer is going to ask you. You should rehearse answers to the most commonly asked questions. Have some one ask you these questions to practice your answers: Why do you want to work here? How long do you want to stay with this company? Why did you leave your last job? Tell me about yourself. Why aren't you working now? How long do you think you would stay in this present job without a promotion? Why should we hire you? What is your greatest strength/weakness? What did you like/dislike about your last job? How much did you earn? How much do you want to earn? Why do you think you can do this job without experience?
Your Appearance and Dress
Don't wear too casual or too formal clothing to the interview. Dress conservatively without flashy colors. Be well groomed and shave for your interview. Women should make sure thy look very neat. Hair should not be in the face, it should be up or tied back. Makeup should be subtle. The way you look is very important to your interviewer. If your appearance is bad for the interview, that is the impression an employer will have of your job performance. Neat appearance is always a must.
What to Do At the Interview
When you shake an employer's hand, shake it firm, solid grip. Don't shake his hand passively. Be business like but pleasant and friendly. Smile throughout the whole interview. Make sure your smile does not look fake. Good eye contact is very important. If you can't look into his eyes, look at the bridge of his nose. This will seem as if you are looking into his eyes. Sit straight up but toward the interviewer. This will make it seem as if you are very interested in what the interviewer has to say. Don't smoke or have poor posture during the interview. If you are under stress, try to act calm.
What to Say at the Interview
Let the employer take charge of the interview. Answer his questions briefly but completely. Don't ramble on about unimportant things and waste his time. Dogmatic statements should be avoided. Tell the employer exactly what you expect from your job and from him. Also tell him exactly what he can expect from you. Stress your qualifications in a positive, affirmative tone. When the employer tells you what type of person is wanted, use this information when telling the employer about your qualifications. It is very important to tell him what he wants to hear. When you tell people what they want to hear, they start to agree with you. Don't over do it and exaggerate with lies. Use your resume or records to support any claim you make about yourself. If you don't understand a question the interviewer asks you, repeat it back to him to see if you understand it. Try to see what the interviewer wants to find out about you. If you know what he wants to find out, make you answers fit his needs.
What Not To Say and Do at the Interview
Talk about previous jobs if they are in your favor. Don't say anything bad or criticize previous employers or fellow workers. If you say anything bad about anyone, your future employer can expect trouble from you. Don't say anything negative about yourself. Try not to discuss anything personal, financial or domestic unless you are specifically asked. If the interviewer questions you at a quick pace with confusing questions, he is doing this to put you under stress. Stay in control and answer calmly. Don't be overly impatient when an employer asks you a question. Wait for him to finish the question and then answer it completely and in a relaxed manner. You don't want an employer to think you are desperate for the job. Don't take anyone with you to the interview--this makes you seem insecure.
At The End of the Interview
If the employer does not offer you the job at the end of the interview, ask him when you will hear from him or when you can call to find out his decision. If you are asked to come back, write down the time and place you are to attend. After the interview thank the employer for spending his time with you. Ask him if he knows of any other company that may need a person with your qualifications. A good practice is to also thank the employer by mail with a "thank you" letter. Many applicants don't do this, so this may give you an edge on the job.
If You Are Hired At the Interview
Make sure that you understand what your duties will be. A good understanding of what your employer expects from you and what you expect from your job will prevent conflicts in the future. Make sure that you are very clear on both of them. You should also find out what advancement opportunities are open for you. Tell the employer what salary you want, but only bring up money when the employer brings up your salary.
If, at the end of the interview, you are not offered the job, tell the interviewer that you really want the job. Follow up with a thank you letter to the interviewer. Tell the interviewer again in the note that you really want the job. If you forgot to mention something in the interview that you thought was important, don't hesitate to mention it in the letter. If the company hasn't contacted you in a week or two, call. If somebody else is hired for the job ask the interviewer if he has any other openings in his company or if he can give you any leads.
WHAT YOU NEED TO GET THAT RAISE
Make the First Move
Don't wait for someone else to tell you what to do. Upper management admires an individual who takes initiative. Develop your individual talents. Educate yourself with new skills and knowledge. Show them that you are a real "go getter."
Make Quick Decisions
Teach yourself to make quick, intelligent decisions. Being indecisive will hurt you. Anyone can make good, quick decisions--it is just a matter of training yourself. Intuitive instincts must be developed.
Seek More Responsibility
Take on the tougher assignments. Actively seek more difficult work with added responsibility. Take on all the responsibility you can handle. Try to take the added responsibilities in addition to your assigned work, the greater your responsibilities, the more you are an asset to management.
Increase Your Interests
The more you know, the more valuable you are to the company you work for. Go to night classes or just read books that will give you that added education. Increase your interest in things that will help your company. Specializing in as many things as you can will help you move up in a company.
Here are some common interview questions with answers.
Q. Tell me about yourself.
A. This is the dreaded, classic, open-ended interview question and likely to be among the first. It's your chance to introduce your qualifications, good work habits, etc. Keep it mostly work and career related.
Q. Why do you want to leave your current job? (Why did you leave your last job?)
A. Be careful with this. Avoid trashing other employers and making statements like, "I need more money." Instead, make generic statements such as, "It's a career move."
Q. What are your strengths?
A. Point out your positive attributes related to the job.
Q. What are your weaknesses?
A. Everybody has weaknesses, but don't spend too much time on this one and keep it work related. Along with a minor weakness or two, try to point out a couple of weaknesses that the interviewer might see as strengths, such as sometimes being a little too meticulous about the quality of your work. (Avoid saying "I work too hard." It's a predictable, common answer.) For every weakness, offer a strength that compensates for it.
Q. Which adjectives would you use to describe yourself?
A. Answer with positive, work-oriented adjectives, such as conscientious, hard-working, honest and courteous, plus a brief description or example of why each fits you well.
Q. What do you know about our company? A. To answer this one, research the company before you interview.
Q. Why do you want to work for us?
A. Same as above. Research the company before you interview. Avoid the predictable, such as, "Because it's a great company." Say why you think it's a great company.
Q. Why should I hire you?
A. Point out your positive attributes related to the job, and the good job you've done in the past. Include any compliments you've received from management.
Q. What past accomplishments gave you satisfaction?
A. Briefly describe one to three work projects that made you proud or earned you pats on the back, promotions, raises, etc. Focus more on achievement than reward.
Q. What makes you want to work hard?
A. Naturally, material rewards such as perks, salary and benefits come into play. But again, focus more on achievement and the satisfaction you derive from it.
Q. What type of work environment do you like best?
A. Tailor your answer to the job. For example, if in doing your job you're required to lock the lab doors and work alone, then indicate that you enjoy being a team player when needed, but also enjoy working independently. If you're required to attend regular project planning and status meetings, then indicate that you're a strong team player and like being part of a team.
Q. Why do you want this job?
A. To help you answer this and related questions, study the job ad in advance. But a job ad alone may not be enough, so it's okay to ask questions about the job while you're answering. Say what attracts you to the job. Avoid the obvious and meaningless, such as, "I need a job."
Q. How do you handle pressure and stress?
A. This is sort of a double whammy, because you're likely already stressed from the interview and the interviewer can see if you're handling it well or not. Everybody feels stress, but the degree varies. Saying that you whine to your shrink, kick your dog or slam down a fifth of Jack Daniels are not good answers. Exercising, relaxing with a good book, socializing with friends or turning stress into productive energy are more along the lines of the "correct" answers.
Q. Explain how you overcame a major obstacle.
A. The interviewer is likely looking for a particular example of your problem-solving skills and the pride you show for solving it.
Q. Where do you see yourself five (ten or fifteen) years from now?
A. Explain your career-advancement goals that are in line with the job for which you are interviewing. Your interviewer is likely more interested in how he, she or the company will benefit from you achieving your goals than what you'll get from it, but it goes hand in hand to a large degree. It's not a good idea to tell your potential new boss that you'll be going after his or her job, but it's okay to mention that you'd like to earn a senior or management position.
Q. What qualifies you for this job?
A. Tout your skills, experience, education and other qualifications, especially those that match the job description well. Avoid just regurgitating your resume. Explain why.
Conclusion
Be Confident
If you don't have confidence in yourself, others will not have confidence in you, either. People admire and respect confident people. If you show others doubt, they will treat you with doubt. Be sure of yourself and play down your insecurities.
Getting a job can be very easy if you look for it the right way. Knowing exactly what you want and then going after it will always get you what you want. Be positive, determined and persistent so that you will benefit, be rewarded and prosper.
COMMON Interview Questions:

1. Tell me about yourself.
Keep your answer short and focused on your professional life. This is not the time to bring up relationships, childhood experiences, family etc. A brief history of education, career and special interests is what is called for here. End it with why you are interested in this particular job.

2. Why are you applying for this particular job?
Show interest and demonstrate that you have researched the job and know what you are getting into. Bring up evidence from past work/ studies that supports your interest in this role and any skills you have acquired in preparation for the role. You can say something like 'I would like to work for a leader in innovative network and telecommunications solutions and my college degree in computational mathematics has given me a solid background for this role. Mention the value-added you can bring to the job.

3. What do you know about our company?
Indicate what you have learnt from your research activities - from their annual reports,
newspapers, word of mouth, other employees etc. Use this to flatter them and show that you have done your homework.

4. What makes you qualified for this particular job?
Again, explain that you are very interested in the job and demonstrate what it is about your past experiences, education and qualifications that makes you ideal for the job. Show enthusiasm and support your answers with evidence wherever you can (eg. my summer internship at Citibank gave me broad exposure to the area of equity analysis and I think I can apply many of the tools I learnt there in this job). Elaborate on all the past experiences and skill sets that make you suitable for the job.In cases where your past experience is not directly relevant, you can still find elements of it that can be useful. Play up teamskills, computer skills, leadership roles, specific courses and independent research activities that can be useful to the job at hand to show your initiative even where you don't have directly relevant job experience.

5. What can you do for us that someone else can't?
Demonstrate key strengths, skills and personal characteristics.

6. Why should we hire you?
See 3. Because you have all the experience/ traits/ credentials demonstrated in 3 and in addition to being qualified, you are enthusiastic, intelligent, hardworking, flexible and willing to learn. Also mention any key relationships you may have that may assist you in the job.

7. What do you look for in a job?
Be honest. Also mention keywords such as challenging, steep learning curve, good work culture, demanding, rewarding, opportunities for advancement and growth, team environment, opportunity to build and maintain client relationships etc.

8. Why are you looking to make a career change?
Mention your interests and make sure you bring up all skills/ experience however insignificant that can support your move in this new direction. It is quite common in this day and age to make a career switch. You need however to show that you have very carefully thought about the change, have a strong interest in the new career and can use some of your previous skills/ education/ relationships to make that move.

9. Why did you leave your last job?
Do NOT use this as an opportunity to badmouth past employers or peers or talk about a failure of any sort. Any of these answers are acceptable: you were looking for a new challenge, your learning curve had flattened out in the previous job and you were looking for a new learning opportunity, the company or department were restructuring, you were ready to start something new after achieving your career goals at the previous company etc.

10. Why do you want to work for us (as opposed to the competitor companies)?
Demonstrate that you know something about the company, that you believe they are leaders/ innovators in what they do, or you think their work culture is exactly what you are looking for, or you like their product(s) or you have friends who work there and have always been attracted to the company etc. Flatter the company and show you know something about it.

11. How long will it take you to start making a meaningful contribution?
Show that you are enthusiastic and willing to learn and will put in all the hours and effort necessary to learn the ropes and start making an immediate contribution. Indicate that your past experiences/ skills/ credentials will enable you to make an immediate contribution at some level while you quickly learn all new aspects of the job. An Interviewer wants someone who is willing and able to learn and will make a return on his investment sooner rather than later.

12. What are your strengths?
See 14 below. In addition, keywords such as good teamplayer, work very well under pressure, very creative, very strong quantitative or computer skills, and very strong client relationship skills may be appropriate depending on your chosen field.

13. What are your weaknesses?
Do NOT mention key weaknesses here. This is not the place to say you are bad at meeting deadlines or you never mastered highschool mathematics etc. Turn this question around to your benefit. For example, you are 'overambitious' or 'extremely attentive to detail' or 'like to take on too many projects'. Make it sound positive.

14. What are your career goals?
Show you have thought forward and are committed to your career.

15. How would you describe yourself?
Any of these are good examples of attributes employers are looking for: intelligent, hardworking, quick to learn, enthusiastic, honest, efficient, productive, ambitious, successful, compassionate (in the medical fields).

16. How would your colleagues describe you?
Do not bring up anything negative here.

17. How would your boss describe you?
They will check references anyways so bring up the most positive attribute you can think of about yourself eg hardworking, honest etc. and leave it to your Boss to say anything to the contrary.

18. What did you most like/ dislike about your past job?
Do not use this to badmouth past jobs/ employers. Keep it light and in your favour eg I outgrew the job, there wasn't a clear career progression, I wasn't learning anything new etc. Ideally, you will have loved your last job and would like to achieve the same kind of success and job satisfaction in a more challenging area as you have now 'outgrown' that job and are ready for 'new challenges'.

19. Describe a situation in your past where you showed initiative?
You could describe any new methods you came up with to do your job or to save money for the company or to turn around a bad situation. It can be something as simple as changing a filing system, or establishing a relationship with a vendor that saved your department a lot of money. If you are in sales, you may want to talk about how you brought in that big account. Creatives may talk about how they came up with that cutthroat image or design that brought in the business.

20. What were your main responsibilities in your last job?
Have these ready and list them all. Dwell on the ones that are most relevant to the new job. This answer should be smooth and practiced.

21. What do you consider your greatest accomplishments?
Many of us have one or two milestones in our career that we are very proud of eg. that early promotion, that 'huge' deal we brought in, the design we came up with, the costs we saved, the revenues we increased, the people we trained, a new invention or process we came up with etc.
Examples of accomplishments may be: 'Reduced costs by X%; or renamed and repositioned a product at the end of its lifecycle, or organized and led a team to do do XYZ, or achieved sales increase of
X% etc. If you are a fresh college graduate, talk about extracurricular activities, leadership roles and grades.

22. Describe your management style (if relevant)
No answer

23. Do you work better in teams or independently?
Show that you are a proactive teamplayer and like to bounce ideas off others and get input; however you are very capable of working independently (give examples).

24. How do you work under pressure?
Well. Give evidence.

25. What other jobs have you applied for?
Don't mention jobs in different career directions (eg advertising and investment banking). Do however bring up any other offers or Interviews from competing firms.

26. How did you do in college?
Keep it positive. It's okay to say you were very busy making the most of college and were very involved in sports, activities, social life etc. Employers want human beings not robots. Mention the areas you did very well in even if it was just one or two courses you excelled in. They will check for themselves.

27. What kind of hours would you like to work?
Employers want to see flexibility. Indicate you are willing to put in whatever hours are necessary to finish the job. Do however mention any constraints you have eg. you would like to be home to pick your kids up from school at 3:30. Most employers are willing to work around your constraints if you show flexibility on your side as well.

28. Do you have any questions for me?
YES you do. Questions engage the Interviewer and show your interest. Ask questions that show you know something about the company or the job, that you are planning ahead, that you are anxious and willing to learn the ropes and that you are committed to the position.