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 the 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 services you can bring to the job.

Indicate what you have learnt from your research activities- from their annual reports, newspapers, word of mouth, other employee’s etc. Use this to flatter them and show that you have done your homework.

Again, explain that you are very interested in the job and demonstrate what it is about your past experiences, education and qualifications that make you an ideal candidate for the job. Show enthusiasm and support your answers with evidence wherever you can (e.g. 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 team skills, 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 relevant job experience.

Demonstrate key strengths, skills and personal characteristics.

Because you have all the experience/ traits/ credentials 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.

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.

Mention your interests and make sure you bring up all skills and 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 and relationships to make that move.

Do not use this as an opportunity to badmouth past employers or talk about a failure of any sort. Any of these answers are not acceptable: you are looking for a new challenge as your learning curve had flattened out in the previous job and you are looking for a new learning opportunity.

Demonstrate that you know something about the company, that you believe they are leaders or innovators in what they do, or you think their work culture is exactly what you are looking for, or you like their products 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.

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.

Words such as good team player, 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.

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

Show you have thought forward and are committed to your career.

Any of these are good examples of attributes as employers look for intelligent, hardworking, quick to learn, enthusiastic, honest, efficient, productive, ambitious, successful, compassionate candidates

Do not bring up anything negative here.

They will check references anyways so bring up the most positive attribute you can think of about yourself e.g.: hardworking, honest etc. and leave it to your Boss to say anything to the contrary.

Do not use this to badmouth past jobs/ employers. Keep it light and in your favor e.g.: 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'.

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.

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.

Many of us have one or two milestones in our career that we are very proud of e.g. 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.

No answer

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).

Well. Give evidence.

Don't mention jobs in different career directions (e.g. advertising and investment banking). Do however bring up any other offers or Interviews from competing firms.

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.

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 e.g. 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.

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.

Before the User Acceptance testing application should be fully developed. These various levels of testing (Unit, Integration and System) should be completed before User Acceptance Testing is done. As various levels of testing have been completed most of the technical bugs have already been fixed before UAT.

To ensure an effective User Acceptance Testing Test cases should be created, These Test cases can be created using various use cases identified during the Requirements definition stage.

Test cases should ensure proper coverage of all the scenarios during testing.

During this type of testing the specific focus is the exact real world usage of the application. The Testing is done in an environment that simulates the production environment.

The Test cases are written using real world scenarios for the application

The user acceptance testing is usually a black box type of testing. In other words, the focus is on the functionality and the usability of the application rather than the technical aspects. It is generally assumed that the application would have already undergone Unit, Integration and System Level Testing.

However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment.

The steps taken for User Acceptance Testing typically involve one or more of the following:

1. User Acceptance Test (UAT) Planning
2. Designing UA Test Cases
3. Selecting a Team that would execute the (UAT) Test Cases
4. Executing Test Cases
5. Documenting the Defects found during UAT
6. Resolving the issues or Bug Fixing
7. Sign Off

As always the Planning Process is the most important of all the steps. This affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria.

As always the Planning Process is the most important of all the steps. This affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria.

The User Acceptance Test Cases help the Test Execution Team to test the application thoroughly. This also helps ensure that the UA Testing provides sufficient coverage of all the scenarios.

The Use Cases created during the Requirements definition phase may be used as inputs for creating Test Cases. The inputs from Business Analysts and Subject Matter Experts are also used for creating.

Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something.

The Business Analysts and the Project Team review the User Acceptance Test Cases.

Selecting a Team that would execute the UAT Test Cases is an important step. The UAT team is generally a good representation of the real world end users. The team thus comprises of the actual end users who will be using the application.

The Testing Team executes the Test Cases and may additional perform random Tests relevant to them

The team logs their comments and any defects or issues found during testing.

The issues/defects found during Testing are discussed with the Project Team, Subject Matter Experts and Business Analysts. The issues are resolved as per the mutual consensus and to the satisfaction of the end users.

Upon successful completion of the User Acceptance Testing and resolution of the issues the team generally indicates the acceptance of the application. This step is important in commercial software sales. Once the User “Accept” the Software delivered they indicate that the software meets their requirements.

The users now confident of the software solution delivered and the vendor can be paid for the same.

In the traditional software development lifecycle, successful completion of User Acceptance testing is a significant milestone.

The Key Deliverables typically of User Acceptance Testing Phase are:

1. The Test Plan- This outlines the Testing Strategy
2. The UAT Test cases – The Test cases help the team to effectively test the application
3. The Test Log – This is a log of all the test cases executed and the actual results.
4. User Sign Off – This indicates that the customer finds the product delivered to their satisfaction

This ‘level of testing’ focuses on testing the integration of “units of code” or components.

Even if a software component is successfully unit tested, in an enterprise n-tier distributed application it is of little or no value if the component cannot be successfully integrated with the rest of the application.

Once unit tested components are delivered, we then integrate them together. These “integrated” components are tested to weed out errors and bugs caused due to the integration. This is a very important step in the software development life Cycle.

• It is possible that different programmers developed different components.
• A lot of bugs emerge during the integration step.
• In most cases a dedicated testing team focuses on Integration Testing.

Before we begin Integration Testing it is important that all the components have been successfully unit tested.

Integration Testing typically involves the following Steps:

Simply put, a Test Case describes exactly how the test should be carried out. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.

So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should be tested to make sure the app works when the different components are brought together.

The various Integration Test Cases clubbed together form an Integration Test Suite Each suite may have a particular focus. In other words different Test Suites may be created to focus on different areas of the application.

As mentioned before a dedicated Testing Team may be created to execute the Integration test cases. Therefore the Integration Test Cases should be as detailed as possible.

1. Test Suite Name
2. Tested By
3. Date
4. Test Iteration (One or more iterations of Integration testing may be performed)

There are various factors that affect Software Integration and hence Integration Testing:

1) Software Configuration Management:Since Integration Testing focuses on Integration of components and components can be built by different developers and even different development teams, it is important the right versions of components are tested. This may sound very basic, but the biggest problem faced in n-tier development is integrating the right version of components. Integration testing may run through several iterations and to fix bugs components may undergo changes. Hence it is important that a good Software Configuration Management (SCM) policy is in place. We should be able to track the components and their versions. So each time we integrate the application components we know exactly what versions go into the build process.

2) Automate Build Process where Necessary: A Lot of errors occur because the wrong version of components were sent for the build or there are missing components. If possible write a script to integrate and deploy the components this helps reduce manual errors.

3) Document: Document the Integration process/build process to help eliminate the errors of omission or oversight. It is possible that the person responsible for integrating the components forgets to run a required script and the Integration Testing will not yield correct results.

4) Defect Tracking: Integration Testing will lose its edge if the defects are not tracked correctly. Each defect should be documented and tracked. Information should be captured as to how the defect was fixed. This is valuable information. It can help in future integration and deployment processes.

This article explains about different steps in life cycle of Testing Process. In Each phase of the development process will have a specific input and a specific output. Once the project is confirmed to start, the phases of the development of project can be divided into the following phases:

• Software requirements phase.
• Software Design
• Implementation
• Testing
• Maintenance

In the whole development process, testing consumes highest amount of time. But most of the developers oversee that and testing phase is generally neglected. As a consequence, erroneous software is released. The testing team should be involved right from the requirements stage itself.

The various phases involved in testing, with regard to the software development life cycle are:

1. Requirements Stage
2. Test Plan
3. Test Design
4. Test Cases Preparation
5. Design Reviews
6. Code Reviews
7. Test Execution and Bugs Reporting
8. Release to Production

Normally in many companies, developers itself take part in the requirements stage. Especially for product-based companies, a tester should also be involved in this stage. Since a tester thinks from the user side whereas a developer can’t. A separate panel should be formed for each module comprising a developer, a tester and a user. Panel meetings should be scheduled in order to gather everyone’s view. All the requirements should be documented properly for further use and this document is called "Software Requirements Specifications".

Without a good plan, no work is a success. A successful work always contains a good plan. The testing process of software should also require good plan. Test plan document is the most important document that brings in a process – oriented approach. A test plan document should be prepared after the requirements of the project are confirmed. The test plan document must consist of the following information:

• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies.
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

Test Design is done based on the requirements of the project. Test has to be designed based on whether manual or automated testing is done. For automation testing, the different paths for testing are to be identified first. An end to end checklist has to be prepared covering all the features of the project.

The test design is represented pictographically. The test design involves various stages. These stages can be summarized as follows:

• The different modules of the software are identified first.
• Next, the paths connecting all the modules are identified.

Then the design is drawn. The test design is the most critical one, which decides the test case preparation. So the test design assesses the quality of testing process.

• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios

The software design is done in systematical manner or using the UML language. The tester can do the reviews over the design and can suggest the ideas and the modifications needed.

Code reviews are similar to unit testing. Once the code is ready for release, the tester should be ready to do unit testing for the code. He must be ready with his own unit test cases. Though a developer does the unit testing, a tester must also do it. The developers may oversee some of the minute mistakes in the code, which a tester may find out.

Once the unit testing is completed and the code is released to QA, the functional testing is done. A top-level testing is done at the beginning of the testing to find out the top-level failures. If any top-level failures occur, the bugs should be reported to the developer immediately to get the required workaround.

The test reports should be documented properly and the bugs have to be reported to the developer after the testing is completed.

Once the bugs are fixed, another release is given to the QA with the modified changes. Regression testing is executed. Once the QA assures the software, the software is released to production. Before releasing to production, another round of top-level testing is done.

The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus the testing process is an unending process.

Installation testing is the testing of a full, partial, upgrade install or uninstall process. The installation test is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the application's System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. Following installation testing, a sanity test is performed when necessary.

Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.

Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment.

Comparison testing is testing that compares software weaknesses and strengths to those of competitors' products.

Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.

Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager.

The Test or QA Team Lead coordinate the testing activity, communicates testing status to management and manages the test team.

The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.

One software testing methodology is a three step process of...

• Creating a test strategy
• Creating a test plan/design
• Executing tests.

This methodology can be used and molded to your organization's needs. This methodology is important in the development and ongoing maintenance of his customers' applications.

The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan or design (which usually includes test cases and test procedures) and the execution of tests.

Big difference is that debugging is conducted by a programmer and the programmer fixes the errors during debugging phase. Tester never fixes the errors, but rather find them and return to programmer.

Structural is a "white box" testing and based on the algorithm or code. Functional testing is a "black box" (behavioral) testing where the tester verifies the functional specification.

Bug is an error during execution of the program. There are two types of bugs: syntax and logical.

The goals of both are different: The goal of testing is to find the errors. The goal of QA is to prevent the errors in the program.

This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:

•  Deadlines (release deadlines, testing deadlines, etc.)
•  Test cases completed with certain percentage passed
•  Test budget depleted
•  Coverage of code or functionality or requirements reaches a specified point
•  Bug rate falls below a certain level
•  Beta or alpha testing period ends

Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the same considerations as described previously in ‘What if there isn't enough time for thorough testing?' apply. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis.

Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers, especially in multi-tier systems. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus should be on integration and system testing. Additionally, load/stress/performance testing may be useful in determining client/server application limitations and capabilities. There are commercial tools to assist with such testing

Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well-designed this can simplify test design.

GUI testing is the process of testing a graphical user interface to ensure it meets its written specifications. This is normally done through the use of a variety of test cases.

To generate a ‘good’ set of test cases, the test designer must be certain that their suite covers all the functionality of the system and also has to be sure that the suite fully exercises the GUI itself. The difficulty in accomplishing this task is twofold: one has to deal with domain size and then one has to deal with sequences. In addition, the tester faces more difficulty when they have to do regression testing.

The second problem is the sequencing problem. Some functionality of the system may only be accomplishable by following some complex sequence of GUI events. For example, to open a file a user may have to click on the File Menu and then select the Open operation, and then use a dialog box to specify the file name, and then focus the application on the newly opened window. Obviously, increasing the number of possible operations increases the sequencing problem exponentially. This can become a serious issue when the tester is creating test cases manually. Regression testing also becomes a problem with GUI’s as well. This is because the GUI may change significantly across versions of the application, even though the underlying application may not. A test designed to follow a certain path through the GUI may not be able to follow that path since a button, menu item or dialog may not be where it used to be.

These issues have driven the GUI testing problem domain towards automation. Many different techniques have been proposed to automatically generate test suites that are complete and that simulate user behavior.

Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.

Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications. Requirements are the details describing an application's externally perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable and testable. A non-testable requirement would be, for example, "user-friendly", which is too subjective. A testable requirement would be something such as, "the product shall allow the user to enter their previously-assigned password to access the application". Care should be taken to involve all of a project's significant customers in the requirements process. Customers could be in-house or external and could include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, future software maintenance engineers, salespeople and anyone who could later derail the project. If his/her expectations aren't met, they should be included as a customer, if possible. In some organizations, requirements may end up in high-level project plans, functional specification documents, design documents, or other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by test engineers in order to properly plan and execute tests. Without such documentation there will be no clear-cut way to determine if a software application is performing correctly.

A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.

A test case is a document that describes an input, action or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as

•  Test case identifier
•  Test case name
•  Objective
•  Test conditions or setup
•  Input data requirements or steps and
•  Expected results.

Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.

When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact etc., and regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking or management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

Configuration management (CM) covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes. Rob Davis has had experience with a full range of CM tools and concepts. Rob Davis can easily adapt to your software tool and process needs.

This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are

•  Deadlines, e.g. release deadlines, testing deadlines
•  Test cases completed with certain percentage passed>
•  Test budget has been depleted
•  Coverage of code, functionality, or requirements reaches a specified point
•  Bug rate falls below a certain level
•  Beta or alpha testing period ends.

BRD stands for Business requirement document. This document specifies the needs and the requirements of the customer.

A well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well designed this can simplify test design.

Quality assurance is a planned and systematic set if activities necessary to provide adequate confidence that the product and services will confirm to specified requirement and meet user needs.

•  Process oriented
•  Defect prevention based.

Quality control is the process by which the product quality is compared with applicable standards and the action taken when non-conformance is detected.

•  Product oriented
•  Defect detecting based.

Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. They also ensure a process is repeatable. Once Rob Davis has learned and reviewed customer's business processes and procedures, he will follow them. He will also recommend improvements and/or additions.

All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. It also helps in learning where information is located, making it easier for a user to find what they want. Lastly, with standards and templates, information will not be accidentally omitted from a document. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions.

•  Unit Testing
•  Integration Testing
•  System testing
•  User Acceptance Testing

Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing is based on requirements and functionality.

White box testing is based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths and conditions.

Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.

A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers should perform functional testing.

Usability testing is testing for 'user-friendliness'. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Test engineers are needed, because programmers and developers are usually not appropriate as usability testers.

Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application's functionality are independent enough to work separately, before all parts of the program are completed or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers.

Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.

Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable or acceptable based on client input.

System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an application's accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a "simulated real life" test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input.

Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by SWQA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels.

End-to-end testing is similar to system testing, the *macro* end of the test scale; it is the testing a complete application in a situation that mimics real life use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.

The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify that changes introduced during the release have not "undone" any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.

Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

Bug life cycles are similar to software development life cycles. At any time during the software development life cycle errors can be made during the gathering of requirements, requirements analysis, functional design, internal design, documentation planning, document preparation, coding, unit testing, test planning, integration, testing, maintenance, updates, re-testing and phase-out. Bug life cycle begins when a programmer, software developer, or architect makes a mistake, creates an unintentional software defect, i.e. bug, and ends when the bug is fixed, and the bug is no longer in existence.

When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested.

Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking, management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

A document showing the relationship between Test Requirements and Test Cases.

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

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.

Golden bug is nothing but the difference between our perception and reality.

If a piece of Software is modified for any reason testing needs to be done to ensure that it works as specified and that it has not negatively impacted any functionality that it offered previously. This is known as Regression Testing. Regression Testing attempts to verify:

•  That the application works as specified even after the changes, additions or modification were made to it
•  The original functionality continues to work as specified even after changes, additions or modification to the software application
•  The changes/additions/modification to the software application have not introduced any new bugs

Regression Testing plays an important role in any Scenario where a change has been made to a previously tested software code. Regression Testing is hence an important aspect in various Software Methodologies where software changes enhancements occur frequently. Any Software Development Project is invariably faced with requests for changing Design, code, features or all of them.

Some Development Methodologies embrace change.

For example ‘Extreme Programming’ Methodology advocates applying small incremental changes to the system based on the end user feedback.

Each change implies more Regression Testing needs to be done to ensure that the System meets the Project Goals.

• Any Software change can cause existing functionality to break.Changes to a Software component could impact dependent Components.
• It is commonly observed that a Software fix could cause other bugs.
• All this affects the quality and reliability of the system. Hence Regression Testing, since it aims to verify all this, is very important.

Every time a change occurs one or more of the following scenarios may occur:

• More Functionality may be added to the system
• More complexity may be added to the system
• New bugs may be introduced
• New vulnerabilities may be introduced in the system
• System may tend to become more and more fragile with each change

After the change the new functionality may have to be tested along with all the original functionality.

With each change Regression Testing could become more and more costly.

To make the Regression Testing Cost Effective and yet ensure good coverage one or more of the following techniques may be applied:

• Test Automation: If the Test cases are automated the test cases may be executed using scripts after each change is introduced in the system. The execution of test cases in this way helps eliminate oversight, human errors. It may also result in faster and cheaper execution of Test cases. However there is cost involved in building the scripts.

• Selective Testing: Some Teams choose execute the test cases selectively. They do not execute all the Test Cases during the Regression Testing. They test only what they decide is relevant. This helps reduce the Testing Time and Effort.

Since Regression Testing tends to verify the software application after a change has been made everything that may be impacted by the change should be tested during Regression Testing. Generally the following areas are covered during Regression Testing:

• Any functionality that was addressed by the change
• Original Functionality of the system
• Performance of the System after the change was introduced

Like any other Testing Regression Testing Needs proper planning.

For an Effective Regression Testing to be done the following ingredients are necessary:

• Create a Regression Test Plan: Test Plan identified Focus Areas, Strategy, Test Entry and Exit Criteria. It can also outline Testing Prerequisites, Responsibilities, etc.
• Create Test Cases: Test Cases that cover all the necessary areas are important. They describe what to Test, Steps needed to test, Inputs and Expected Outputs. Test Cases used for Regression Testing should specifically cover the functionality addressed by the change and all components affected by the change. The Regression Test case may also include the testing of the performance of the components and the application after the change(s) were done.
• Defect Tracking: As in all other Testing Levels and Types It is important Defects are tracked systematically, otherwise it undermines the Testing Effort.

Yes, I have been using WinRunner for creating automates scripts for GUI, functional and regression testing of the AUT.

WinRunner testing process involves six main stages

Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested

Create testscripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested.

Debug Test: run tests in Debug mode to make sure they run smoothly

Run Tests: run tests in Verify mode to test your application.

View Results: determines the success or failure of the tests.

Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window.

WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description. There are 2 types of GUI Map files.

Global GUI Map file: a single GUI Map file for the entire application

GUI Map File per Test:WinRunner automatically creates a GUI Map file for each test created.

WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested.

Yes I have created test scripts. It contains the statement in Mercury Interactive’s Test Script Language (TSL). These statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function Generator.

Following each test run, WinRunner displays the results in a report. The report details are the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.

Yes, we can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.

We run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.

Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window. If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window. This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is fixed.

TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.

When you work with WinRunner, you can choose to save your tests directly to your TestDirector database or while creating a test case in the TestDirector we can specify whether the script in automated or manual. And if it is automated script then TestDirector will build a skeleton for the script that can be later modified into one which could be used to test the AUT.

There are two type of recording in WinRunner.

Context Sensitive recordingrecords the operations you perform on your application by identifying Graphical User Interface (GUI) objects.

Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.

Add-Ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the add-in selected will be listed in the function generator and while executing the script only those functions in the loaded add-in will be executed else WinRunner will give an error message saying it does not recognize the function.

WinRunner fails to identify an object in a GUI due to various reasons.

The object is not a standard windows object.

If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window.

An object’s logical name is determined by its class. In most cases, the logical name is the label that appears on an object.

If the object does not have a name then the logical name could be the attached text.

The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files.

Global GUI Map file: a single GUI Map file for the entire application

GUI Map File per Test:WinRunner automatically creates a GUI Map file for each test created. GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and their physical description.

GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The GUI Map Editordisplays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description.

If we are learning a window then WinRunner automatically learns all the objects in the window else we will we identifying those object, which are to be learned in a window, since we will be working with only those objects while creating scripts.

If we are using a single GUI Map file for the entire AUT then the memory used by the GUI Map may be much high.

If there is any change in the object being learned then WinRunner will not be able to recognize the object, as it is not in the GUI Map file loaded in the memory. So we will have to learn the object again and update the GUI File and reload it.

When we load a GUI Map file, the information about the windows and the objects with their logical names and physical description are loaded into memory. So when the WinRunner executes a script on a particular window, it can identify the objects using this information loaded in the memory.

While recording a script, WinRunner learns objects and windows by itself. This is actually stored into the temporary GUI Map file. We can specify whether we have to load this temporary GUI Map file should be loaded each time in the General Options.

The extension for a GUI Map file is “.gui”.

The GUI Map Editor has a drop down “GUI File” displaying all the GUI Map files loaded into the memory.

You can modify the logical name or the physical description of an object in a GUI map file using the GUI Map Editor.

Changing the logical name of an object is useful when the assigned logical name is not sufficiently descriptive or is too long.

Changing the physical description is necessary when the property value of an object changes.

We can suppress the regular expression of a window by replacing the regexp_label property with label property.

We can copy and move objects between different GUI Map files using the GUI Map Editor. The steps to be followed are:

• Choose Tools > GUI Map Editor to open the GUI Map Editor.
• Choose View > GUI Files.
• Click Expand in the GUI Map Editor. The dialog box expands to display two GUI map files simultaneously.
• View a different GUI map file on each side of the dialog box by clicking the file names in the GUI File lists.

In one file, select the objects you want to copy or move. Use the Shift key and/or Control key to select multiple objects. To select all objects in a GUI map file, choose Edit > Select All.Click Copy or Move.

To restore the GUI Map Editor to its original size, click Collapse.

Use th