What can be done if requirements are changing continuously?

What can be done if requirements are changing continuously?

A: Work with management early on to understand how requirements might
change, so that alternate test plans and strategies can be worked out in advance.
It is helpful if the application's initial design allows for some adaptability, so that
later changes do not require redoing the application from scratch. Additionally, try
to...

Ø Ensure the code is well commented and well documented; this makes
changes easier for the developers.

Ø Use rapid prototyping whenever possible; this will help customers feel
sure of their requirements and minimize changes.

Ø In the project's initial schedule, allow for some extra time to
commensurate with probable changes.

Ø Move new requirements to a 'Phase 2' version of an application and use
the original requirements for the 'Phase 1' version.

Ø Negotiate to allow only easily implemented new requirements into the
project; move more difficult, new requirements into future versions of the application.

Ø Ensure customers and management understands scheduling impacts,
inherent risks and costs of significant requirements changes. Then let
management or the customers decide if the changes are warranted; after all, that's their job.

Ø Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.

Ø Design some flexibility into automated test scripts;

Ø Focus initial automated testing on application aspects that are most likely to remain unchanged;

Ø Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;

Ø Design some flexibility into test cases; this is not easily done; the best
bet is to minimize the detail in the test cases, or set up only higher-level
generic-type test plans;

Ø Focus less on detailed test plans and test cases and more on ad-hoc
testing with an understanding of the added risk this entails

Part-2: Real Time: How to connect VPN(Virtual Privat Network)?

VPN Setup using PPTP Tele-worker to Head Office

Windows XP PPTP or L2TP/IPSec Client

Below are Step-by-step screenshots illustrating how to setup PPTP-based VPN clients on Windows XP?

Next, you must enter the IP address of the remote host. That is the Public IP address of the Vigor router. If the host connection has a fixed/static IP address from the ISP, then the address will always be the same. If they have a dynamic IP address, then it will change, normally every time they log on. You can use a Dynamic DNS service to track dynamic IP addresses. Note that in the below example, the address 212.119.... is not a real IP address - you must enter your own host's public IP address.

Once your computer is connected to the remote network, the system tray will show a VPN connection and a connection message will appear momentarily:

Now you are connected, and you can browse the remote network (assuming it is a Windows based network over TCP/IP):

---

L2TP/IPSec

IPSec Encryption is much stronger than PPTP with MPPE encryption. If you wish to use IPSec instead of PPTP, then you can edit the VPN's properties directly in Windows, however WindowsXP does not make it very easy to set up L2TP/IPSec manually. To assist with this, DrayTek provide the 'VPN Smart Tool'.

The VPN SmartTool is not a VPN client in itself, but a setup 'wizard' and front end VPN dialler for Windows' own VPN client. It is supplied on your CD-Rom, or you can obtain the latest version from the DrayTek web site.

Part-1: What is VPN(Virtual Private Networking)?

What is VPN (Virtual Private Networking)?

VPN gives extremely secure connections between private networks linked through the Internet. It allows remote computers to act as though they were on the same secure, local network.

Advantages

• Allows you to be at home and access your company's computers in the same way as if you were sitting at work.
• Almost impossible for someone to tap or interfer with data in the VPN tunnel.
• If you have VPN client software on a laptop, you can connect to your company from anywhere in the world.

Disadvantages

• Setup is more complicated than less secure methods. VPN works across different manufacturers' equipment, but connecting to a non-NETGEAR product will add to difficulty, since there may not documentation specific to your situation.
• The company whose network you connect to may require you to follow the company's own policies on your home computers ( ! )

VPN goes between a computer and a network (client-to-server), or a LAN and a network using two routers (server-to-server). Each end of the connection is an VPN "endpoint", the connection between them is a "VPN tunnel". When one end is a client, it means that computer is running VPN client software such as NETGEAR's ProSafe VPN Client. The two types of VPN:

VPN Client-to-Server (Client-to-Box)

VPN Server-to-Server (Box-to-Box)

All NETGEAR routers support "VPN Passthrough", but "passthrough" simply means the router does not stop VPN traffic — you still need two endpoints.

The whole purpose of VPN is to prevent data being altered, so, for example, a passthrough router that is also running NAT will break the VPN connection.

Use this Bug tracking tool for interviews....

Explore this bug tracking tool

Use this below bug tracking tool for your interviews

http://www.geniesys.net/solutions/BTR/demo.asp

FOR QA ENGINEER
Username: qa
password: qa123

Test Strategy

Test Strategy

What is a strategy? Why does testing need one?

A strategy outlines what to plan, and how to plan it. A successful strategy is your guide through change, and provides a firm foundation for ongoing improvement. Unlike a plan, which is obsolete from the point of creation, a strategy reflects the values of an organisation - and remains current and useful.

When an organisation tests its products or its tools, it tries to compare them against its expectations and values. By its nature, testing introduces change as problems are identified and resolved. A test strategy is necessary to allow these two impulses to work together. Furthermore, testing can never be said to be 'complete', and a core skill in testing is the justified management of conflicting demands; without a strategy, these judgements will be inconsistent to the point of failure.

Software development is a creative process. A test strategy is a vital enabler to this process - keeping focus on core values and consistent decision-making to help achieve desired goals with best use of resource. A good strategy stands as a clear counter to reactive, counter-productive test approaches.

Examples and Templates

A test strategy is not a document. It is a framework for making decisions about value, and has strong links to the unique values of an organisation. It is part of the creative process. Although templates exist, most organisations and projects are poorly served by a one-size-fits-all approach to their specific goals. You may find templates useful on projects where the product to be tested can be created and marketed simply by following templates - but on other projects, they're dangerous.

I try to avoid using Test Strategy templates. Instead, I use my skills and experience to rapidly help your team arrive at an understanding of their shared goals and potential conflicts. From this, a strategy will be both obvious, and shared. If you have an existing, problematic strategy, I will suggest areas where it could be slimmed down, and identify aspects that have been missed.

Test strategies can cover a wide range of testing and business issues. While not a checklist, you might expect to see some of the following in your own strategy:

• values and decision-making framework
• approaches to risk assessment, costs and quality through the organisation
• test techniques, test data, test scope and test planning
• completion criteria and analysis
• test management, metrics and improvement
• skills, staffing, team structure and training
• test environment, change control and release strategy
• defect control, tracking and the approach to fixes
• re-tests and regression tests
• profiling and analysis for non-functional testing
• test automation and test tool assessment

Testing as a genuinely strategic part of software development

A strategic decision is one that opens up opportunities which are otherwise unapproachable - a strategic resource is the mechanism by which these opportunities are exploited.

Design, coding, and testing are the three key parts of software development. These are activities, not phases; they operate in parallel and are closely coupled. On a not-too-turbulent project, testing and defect resolution typically account for 25-35% of the final cost of development. Information produced by software testing is clearly an input to the overall organisation's strategic decisions about marketability and release - but testing can provide much more than this for the significant spend it absorbs.

Various Bug Tracking Tools

Various Bug Tracking Tools used in Real Time....

Click on the below hyper-link

http://www.testingfaqs.org/t-track.html

Install: Practise ISTQB Sample Test

Download the setup from the below link and write the sample exams....

http://agilitek.com/ISTQB-CTFL-Exam-Simulation.html

Part-1: Software Testing Interview Questions with Answers

1. What is Retesting?
Ans: If u do all the test procedures once u make any new change or add a new functionality is Regression testing whereas in Retesting
U will do testing for only the Changed Scenarios.

2. What documents we need/refer to make a test plan?
Ans: Most required SRS documentation
Real time question: We can refer only LLD for clear information About Requirements,Then what is the use of referring SRS document in V model, Please can u make difference

Srs is Software requirement specification, which contains the detailed description of what the user expects the application or software to perform . LLd is nothing but logic design/ code of control flow & data flow in the software or application.

In order to detect defects at the early stages of software development cycle . Testers has to be provided with both SRS and LLD.

3. What is Test Bed?
Ans: 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.

4. What is Software Requirements Specification?
Ans:A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software

5.Difference between smoke testing and sanity testing?
Ans: Smoke Testing is non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details. 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.

6.What is Soak Testing?
Ans: 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.

7.What is exactly the technical definition of a build
Ans:The application under test is known as Build.
OR
The executable software which is under testing.

8.What is Scalability Testing?
Ans: Performance testing focused on ensuring the application under test gracefully handles increases in work load.

9. What is Release Candidate?
Ans: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).

10. What is Ramp Testing?
Ans: Continuously raising an input signal until the system breaks down.

11. What is Quality System?
Ans: The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.


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

13. What is Quality Management?
Ans:That aspect of the overall management function that determines and implements the quality policy.

14.What is Quality Control?
Ans:The operational techniques and the activities used to fulfill and verify requirements of quality.

15.What is Quality Circle?
Ans: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.

16.What is Quality Audit?
Ans: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.

17.What is Quality Assurance?
Ans: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.

18.What is Monkey Testing?
Ans: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.

19.What is Metric?
Ans: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.


20.What is Localization Testing?
Ans:This term refers to making software specifically designed for a specific locality.

21.What is Independent Test Group (ITG)?
Ans:A group of people whose primary responsibility is software testing.

21.What is Gorilla Testing?
Ans:Testing one particular module, functionality heavily.

22.What is Gray Box Testing?
Ans: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.

23.What is Functional Specification?
Ans. A document that describes in detail the characteristics of the product with regard to its intended features.

24.What is Functional Decomposition?
Ans:A technique used during planning, analysis and design; creates a functional hierarchy for the software.

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

26. What is Equivalence Partitioning?
Ans: A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.

27. What is Equivalence Class?
Ans: A portion of a component’s input or output domains for which the component’s behavior is assumed to be the same from the component’s specification.

28. What is Endurance Testing?
Ans: Checks for memory leaks or other problems that may occur with prolonged execution what is testing
Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, ‘if the user is in interface A of the application while using hardware B, and does C, then D should happen’). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. It is oriented to ‘detection’. (See the Bookstore section’s ‘Software Testing’ category for a list of useful books on Software Testing.) • Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization’s size and business structure.

29. What is Depth Testing?
Ans:A test that exercises a feature of a product in full detail.

30. What is Dependency Testing?
Ans: Examines an application’s requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.

31. What is Defect?
Ans:Non conformance to requirements or functional / program specification

32.What is Debugging?
Ans:The process of finding and removing the causes of software failures.

33.What is Cyclomatic Complexity?
Ans:A measure of the logical complexity of an algorithm, used in white-box testing.

34.What is Conversion Testing?
Ans: Testing of programs or procedures used to convert data from existing systems for use in replacement systems.

35. What is Component?
Ans: A minimal software item for which a separate specification is available.

36. What is Code Coverage?
Ans: 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.

37. What is Cause Effect Graph?
Ans: A graphical representation of inputs and the associated outputs effects which can be used to design test cases.

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

39.What is Branch Testing?
Testing in which all branches in the program source code are tested at least once.

40. What is Boundary Value Analysis?
Ans: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.

41. What is Boundary Testing?
Ans:Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).

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

43. What is Baseline?
Ans:The point at which some deliverable produced during the software engineering process is put under formal change control.

44. What is Basis Set?
Ans: The set of tests derived using basis path testing.

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

46. What is Basic Block?
Ans:A sequence of one or more consecutive, executable statements containing no branches.

47.What is Backus-Naur Form?
Ans: A metalanguage used to formally describe the syntax of a language.

48. How do you debug an ASP.NET Web application?
Ans: Attach the aspnet_wp.exe process to the DbgClr debugger.

49.Why are there five tracing levels in System. Diagnostics. Trace Switcher?
Ans: The tracing dumps can be quite verbose. For applications that are constantly running you run the risk of overloading the machine and the hard drive. Five levels range from none to Verbose, allowing you to fine-tune the tracing activities.


50.What’s the difference between the Debug class and Trace class?
Ans:Documentation looks the same. Use Debug class for debug builds, use Trace class for both debug and release builds.


51. What is test case? How test case is written. Example.
Ans: It is a input condition with expected result to a small work unit.
Based on Business requirements and Functional requirements test case is return.
For ex: A pen
1.To check whether pen is writing properly or not.
2.To check whether ink is there in the refill.
3. Verify pen cap is there or not.
etc.

52. What we do when the Requirements are continuously changed?
Ans: Whenever the requirements are continuously changing, we will do agile testing.

53.In an application if I enter delete button it should give an error message "Are you sure u want to delete?" but the application gives message as "are u sure?"is it a bug? And if it a bug how you rate severity?
Ans: First we have to make sure what the actual error message should be from the specifications document. If it is not clearly mentioned, then the bug to be reported should have a severity as "low" with suggestion attached.. If it is clearly mentioned in the specifications document, then its severity should be "medium" with reference attached.

54. What do you mean by review? How many reviews are there in manual testing? Please explain those?
Ans:

REVIEW
review is verification process without EXECUTION
static technique
bug prevention technique

Ex:- peer review, walkthrough, inspection

TYPES
1. TECHNICAL REVIEW
2. MGMT REVIEW


55.Test cases for shirt button?
Ans:
verify color of button
verify size of button
verify holes size in button

56.WHAT IS UCD ?
Ans: UCD means USE CASE DOCUMENT, it is the diagrammatic representation of requirements given by B.A

57.What is the maximum possible value of reliability?
Ans:To estimate\" peakload\" test eng,s are performing stress test
under customer expected configuration and more than customer expected load

58.When should you begin test plan
Ans:After the preparation of SRS document by PM and PL.

59. What is benchmark testing?
Ans:Benchmark testing is a normal part of the application development life cycle. It is a team effort that involves both application developers and database administrators (DBAs), and should be performed against your application in order to determine current performance and improve it.

60. How many test cases can we write for a scenario?
Ans: we can’t say the exact maximum no. but we can write 1 positive test case and 1 negative test case at minimum

61.What are the key challenges of testing?
Ans: To find out uncover bugs. Not notice even by client side
tell me some typical bugs you encountered in your last assignment give some examples
Example: In this question my answer is if we are testing the web page. If we are click one link, that link is not displayed related web page this is one bug. And another one is links are not working this is also one bug.

62. What is thread Testing?
Ans: A testing technique used to test the business functionality or business logic of the AUT in an end-to-end manner, in much the same way a User or an operator migyht interact with the system during its normal use.

63.How to write simple test cases for login page?
Ans:
enter valid id and valid pass word it should open expected page
enter valid and invalid password it should show \" enter valid pass word\"
enter invalid id and valid pass word it should show \" for got your user id\"
enter invalid id and invalid pass word it should show\" please enter valid pass word\"
leave user id blank and valid pass word it should show \"enter valid id\"
enter valid id and pass word blank it should show \" enter valid pass word\"
both of fields leave blank and click on Ok it should show \" forgot ur pass word\"
apply BVA for both user id and pass word
apply ECP for both user id and pass word

64.what is PATCH and abbreviate it

Ans: Patch is nothing but a software which contains supported additional features OR may be the fix for bugs. This patch is loaded and verify the new features and bug fixes

65.How much interaction with users should testers have and why there should be interaction within client
Ans: Client can provide their requirements and feedback to the under development project and helps to tester get known to client inputs(actual data) .

66.what is scenario? tell me with a simple example.
Ans:Test scenarios is nothing but combination of test cases
ex: if you take for a login window in that we have user name and password click on ok button this is one scenario.

67. In an application if I enter delete button it should give an error message "Are you sure u want to delete?" but the application gives message as "are u sure?"Is it a bug? And if it a bug how you rate severity?
Ans: First we have to make sure what the actual error message should be from the specifications document. If it is not clearly mentioned, then the bug to be reported should have a severity as "low" with suggestion attached.. If it is clearly mentioned in the specifications document, then its severity should be "medium" with reference attached.

68. What is the role of bug tracking system?
Ans: The Bug tracking system is used to know the status of bugs that occurs during the test execution. The tools like mantis, test director, Bugzilla are used for defect tracking.

69. How can we do database testing?
Ans: TO conduct database testing the test engineers are following bellow issues:

1) verification of data entered by the users through application at back end.
2) verification of database design
3) verifying the data integrity
4) verification of SQL scripts.

Software Configuration Management Tools used in real time.

Software Configuration Management Tools

Click on the below link to download different configuration
tools which are used in real time.

http://www.laatuk.com/tools/SCM_tools.html

ATM System test cases

Please click on the below link for ATM test cases.

http://www.math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html

Documentation and Strategy and Key QA Documents

Documentation and Strategy

This is a quick reference guide to the Quality Assurance process. It explains at a high level the key documents QA must receive or prepare during the course of a project cycle to adequately assess the readiness of a product for release. Although the level of detail in each document may vary by team and project, each is mandatory

Key QA Documents

1. PRAD

The Product Requirement Analysis Document is the document prepared/reviewed by marketing, sales, and technical product managers. This document defines the requirements for the product, the "What". It is used by the developer to build his/her functional specification and used by QA as a reference for the first draft of the Test Strategy.

2. Functional Specification

The functional specification is the "How" of the product. The functional specification identifies how new features will be implemented. This document includes items such as what database tables a particular search will query. This document is critical to QA because it is used to build the Test Plan.

QA is often involved in reviewing the functional specification for clarity and helping to define the business rules.

3. Test Strategy

The Test Strategy is the first document QA should prepare for any project. This is a living document that should be maintained/updated throughout the project. The first draft should be completed upon approval of the PRAD and sent to the developer and technical product manager for review.

The Test Strategy is a high-level document that details the approach QA will follow in testing the given product. This document can vary based on the project, but all strategies should include the following criteria:
· Project Overview - What is the project.

· Project Scope - What are the core components of the product to be tested

· Testing - This section defines the test methodology to be used, the types of testing to be executed (GUI, Functional, etc.), how testing will be prioritized, testing that will and will not be done and the associated risks. This section should also outline the system configurations that will be tested and the tester assignments for the project.

· Completion Criteria - These are the objective criteria upon which the team will decide the product is ready for release

· Schedule - This should define the schedule for the project and include completion dates for the PRAD, Functional Spec, and Test Strategy etc. The schedule section should include build delivery dates, release dates and the dates for the Readiness Review, QA Process Review, and Release Board Meetings.

· Materials Consulted - Identify the documents used to prepare the test strategy

4. Test Matrix (Test Plan)

The Test Matrix is the Excel template that identifies the test types (GUI, Functional etc.), the test suites within each type, and the test categories to be tested. This matrix also prioritizes test categories and provides reporting on test coverage.
· Test Summary report
· Test Suite Risk Coverage report

Upon completion of the functional specification and test strategy, QA begins building the master test matrix. This is a living document and can change over the course of the project as testers create new test categories or remove non-relevant areas. Ideally, a master matrix need only be adjusted to include near feature areas or enhancements from release to release on a given product line.

5. Test Cases

As testers build the Master Matrix, they also build their individual test cases. These are the specific functions testers must verify within each test category to qualify the feature. A test case is identified by ID number and prioritized. Each test case has the following criteria:
· Purpose - Reason for the test case
· Steps - A logical sequence of steps the tester must follow to execute the test case
· Expected Results - The expected result of the test case
· Actual Result - What actually happened when the test case was executed
· Status - Identifies whether the test case was passed, failed, blocked or skipped.
· Pass - Actual result matched expected result
· Failed - Bug discovered that represents a failure of the feature
· Blocked - Tester could not execute the test case because of bug
· Skipped - Test case was not executed this round
· Bug ID - If the test case was failed, identify the bug number of the resulting bug.

6. Test Results by Build

Once QA begins testing, it is incumbent upon them to provide results on a consistent basis to developers and the technical product manager. This is done in two ways: A completed Test Matrix for each build and a Results Summary document.

For each test cycle, testers should fill in a copy of the project's Master Matrix. This will create the associated Test Coverage reports automatically (Test Coverage by Type and Test Coverage by Risk/Priority). This should be posted in a place that necessary individuals can access the information.
Since the full Matrix is large and not easily read, it is also recommended that you create a short Results Summary that highlights key information. A Results Summary should include the following:
· Build Number
· Database Version Number
· Install Paths (If applicable)
· Testers
· Scheduled Build Delivery Date
· Actual Build Delivery Date
· Test Start Date
· Scope - What type of testing was planned for this build? For example, was it a partial build? A full-regression build? Scope should identify areas tested and areas not tested.
· Issues - This section should identify any problems that hampered testing, represent a trend toward a specific problem area, or are causing the project to slip. For example, in this section you would note if the build was delivered late and why and what its impact was on testing.
· Statistics - In this section, you can note things such as number of bugs found during the cycle, number of bugs closed during the cycle etc.

7. Release Package

The Release Package is the final document QA prepares. This is the compilation of all previous documents and a release recommendation. Each release package will vary by team and project, but they should all include the following information:

· Project Overview - This is a synopsis of the project, its scope, any problems encountered during the testing cycle and QA's recommendation to release or not release. The overview should be a "response" to the test strategy and note areas where the strategy was successful, areas where the strategy had to be revised etc.

The project overview is also the place for QA to call out any suggestions for process improvements in the next project cycle.

Think of the Test Strategy and the Project Overview as "Project bookends".

· Project PRAD - This is the Product Requirements Analysis Document, which defines what functionality was approved for inclusion in the project. If there was no PRAD for the project, it should be clearly noted in the Project Overview. The consequences of an absent PRAD should also be noted.

· Functional Specification - The document that defines how functionality will be implemented. If there was no functional specification, it should be clearly noted in the Project Overview. The consequences of an absent Functional Specification should also be noted.

· Test Strategy - The document outlining QA's process for testing the application.

· Results Summaries - The results summaries identify the results of each round of testing. These should be accompanied in the Release Package by the corresponding reports for Test Coverage by Test Type and Test Coverage by Risk Type/Priority from the corresponding completed Test Matrix for each build. In addition, it is recommended that you include the full Test Matrix results from the test cycle designated as Full Regression.

· Known Issues Document - This document is primarily for Technical Support. This document identifies workarounds, issues development is aware of but has chosen not to correct, and potential problem areas for clients.

· Installation Instruction - If your product must be installed as the client site, it is recommended to include the Installation Guide and any related documentation as part of the release package.

· Open Defects - The list of defects remaining in the defect tracking system with a status of Open. Technical Support has access to the system, so a report noting the defect ID, the problem area, and title should be sufficient.

· Deferred Defects - The list of defects remaining in the defect tracking system with a status of deferred. Deferred means the technical product manager has decided not to address the issue with the current release.

· Pending Defects - The list of defects remaining in the defect tracking system with a status of pending. Pending refers to any defect waiting on a decision from a technical product manager before a developer addresses the problem.

· Fixed Defects - The list of defects waiting for verification by QA.

· Closed Defects - The list of defects verified as fixed by QA during the project cycle.
The Release Package is compiled in anticipation of the Readiness Review meeting. It is reviewed by the QA Process Manager during the QA Process Review Meeting and is provided to the Release Board and Technical Support.

· Readiness Review Meeting:

The Readiness Review meeting is a team meeting between the technical product manager, project developers and QA. This is the meeting in which the team assesses the readiness of the product for release.

This meeting should occur prior to the delivery of the Gold Candidate build. The exact timing will vary by team and project, but the discussion must be held far enough in advance of the scheduled release date so that there is sufficient time to warn executive management of a potential delay in the release.

The technical product manager or lead QA may schedule this meeting.

· QA Process Review Meeting:

The QA Process Review Meeting is meeting between the QA Process Manager and the QA staff on the given project. The intent of this meeting is to review how well or not well process was followed during the project cycle.

This is the opportunity for QA to discuss any problems encountered during the cycle that impacted their ability to test effectively. This is also the opportunity to review the process as whole and discuss areas for improvement.

After this meeting, the QA Process Manager will give a recommendation as to whether enough of the process was followed to ensure a quality product and thus allow a release.

This meeting should take place after the Readiness Review meeting. It should be scheduled by the lead QA on the project.

· Release Board Meeting:

This meeting is for the technical product manager and senior executives to discuss the status of the product and the teams release recommendations. If the results of the Readiness meeting and QA Process Review meeting are positive, this meeting may be waived.

The technical product manager is responsible for scheduling this meeting.

This meeting is the final check before a product is released.
Due to rapid product development cycles, it is rare that QA receives completed PRADs and Functional Specifications before they begin working on the Test Strategy, Test Matrix, and Test Cases. This work is usually done in parallel.

Testers may begin working on the Test Strategy based on partial PRADs or confirmation from the technical product manager as to what is expected to be in the next release. This is usually enough to draft out a high -level strategy outlining immediate resource needs, potential problem areas, and a tentative schedule.

The Test Strategy is then updated once the PRAD is approved, and again when the functional specifications are complete enough to provide management with a committed schedule. All drafts of the test strategy should be provided to the technical product manager and it is QA's responsibility to ensure that information provided in the document (such as potential resource problems) is clearly understood.

If the anticipated release does not represent a new product line, testers can begin the Master Test Matrix and test cases at the same time the project's PRAD is being finalized. Testers can build and/or refine test cases for the new functionality as the functional specification is defined. Testers often contribute to and are expected to be involved in reviewing the functional specification.

The results summary document should be prepared at the end of each test cycle and distributed to developers and the technical product manager. It is designed more to inform interested parties on the status of testing and possible impact to the overall project cycle.

The release package is prepared during the last test cycle for the readiness review meeting.

8. Test Strategy Template

QA Test Strategy: [Product and Version]

[Document Version history in format MM-DD-YYYY]

1.0 PROJECT OVERVIEW

[Brief description of project]

1.2 PROJECT SCOPE

[More detailed description of project detailing functionality to be included]

2.0 MATERIALS CONSULTED

[Identify all documentation used to build the test strategy]

3.0 TESTING

· CRITICAL FOCUS AREAS

[Areas identified by developers as potential problems above and beyond specific feature enhancements or new functionality already given priority 1 status by QA]

· INSTALLATION:

[Installation paths to be qualified by QA. Not all products require installation testing. However, those that do often have myriad installation paths. Due to time and resource constraints, QA must prioritize. Decisions on which installation paths to test should be made in cooperation with the technical product manager. Paths not slated for testing should also be identified here.]

· GUI

[Define what if any specific GUI testing will be done]

· FUNCTIONAL

[Define the functionality to be tested and how it will be prioritized]

· INTEGRATION

[Define the potential points of integration with other MediaMap products and how they will be prioritized and tested]

· SECURITY

[Define how security issues will be tested and prioritized]

· PERFORMANCE

[Define what if any performance testing will be done and its priority]

· FAILURE RECOVERY

[Define what if any failure recovery testing will be done and its priority]

3.1 TECHNIQUE

· [Technique used for testing. Automation vs. Manual]

3.2 METHODOLOGY

[Define how testers will go about testing the product. This is where you outline your core strategy. Include in this section anything from tester assignments to tables showing the operating systems and browsers the team will qualify. It is also important to identify any testing limitations and risks]

4.0 TEST SET-UP

4.1 TEST PRE-REQUISITES

[Any non-software or hardware related item QA needs to test the product. For example, this section should identify contact and test account information for 3rd party vendors]

4.2 HARDWARE

QA has the following machines available for testing:

Workstations: Servers:
[Include processor, chip, and memory and disk space]

Other:
[Identify any other hardware needed such as modems etc.]

4.3 SOFTWARE

[Identify all those software applications QA will qualify with the product and those QA will not qualify. For example, this is where you would list the browsers to be qualified. It is also important to identify what will not be qualified (for example, not testing with Windows 2000)]

4.4 PERSONNEL

[Identify which testers are assigned to the project and who will test what. It is also important to identify who is responsible for the creation of the test strategy, test plan, test cases, release package, documentation review etc.]

5.0 COMPLETION CRITERIA

[Identify how you will measure whether the product is ready for release. For example, what is the acceptable level of defects in terms of severity, priority, and volume?]

6.0 SCHEDULE

6.1 Project Schedule
· PRD Review completed by [MM-DD-YYYY] - [STATUS]
· Functional Specification completed [MM-DD-YYYY] - [STATUS]
· Release Date approved by [MM-DD-YYYY] - [STATUS]
· Test Strategy completed by [MM-DD-YYYY] - [STATUS]
· Core Test Plan (functional) completed by [MM-DD-YYYY] - [STATUS]
· Readiness Meeting - [STATUS]
· QA Process Review Meeting - [STATUS]
· Release Board Meeting - [STATUS]
· Release on [MM-DD-YYYY] - [STATUS]

6.2 Build Schedule
· Receive first build on [MM-DD-YYYY] - [STATUS]
· Receive second build on [MM-DD-YYYY] - [STATUS]
· Receive third build on [MM-DD-YYYY] - [STATUS]
· Receive fourth build on [MM-DD-YYYY] - [STATUS]
· Receive Code Freeze Build on [MM-DD-YYYY] - [STATUS]
· Receive Full Regression Build on [MM-DD-YYYY] - [STATUS]
· Receive Gold Candidate Build on [MM-DD-YYYY] - [STATUS]
· Final Release on [MM-DD-YYYY] - [STATUS]

7.0 QA Test Matrix and Test Cases:

Characteristics of a Tester

Introduction

All professions in the world have certain traits or features attached to it. Software testing is no exception to this. Many a times you must have seen that as a tester your inputs are not being accepted in the real time software projects. You must also be working overtime for no fault of yours but due to bad planning by others. You are often asked to "complete the testing" or "windup testing" but also asked to ensure to deliver a defect free product. What should you do to be prepared in such situations? How to tackle the different sections of persons in the software projects? What characteristics portrays a successful "software tester"? Read on…

Communication skills - oral and written

There are situations when as a tester, you would have to meet / interact with different sections of people - the business analysts, the design team, the development team and other testing teams. In those situations, it is necessary to explain yourself (the issues/problems/clarifications that you may have) to them. It has to be conveyed in the correct way so that the person(s) sitting across the table is/are able to understand clearly. Also, it is very important that any defect that is written by you has to be understood clearly by the receiving team.

Be clear/ concise in your oral and written communication skills.

Critical eye

Look out for details. As a tester you should be in a position to look out for any implicit or unstated requirements that need clarification from the clients. Always check for "what if " scenarios and get the answers. Think in multi dimensional way about a problem/requirement.

For example, during testing of a home banking application, there was a requirement to display all balances in dual currencies (Euro/local currency). The business requirement stated the list of screens pertaining to the withdrawal and Balance Inquiry modules for which this requirement was supposed to be implemented. On analysis this requirement was impacting more places like the screen in which the user checks out the history of transactions, or does a deposit, or sets up a standing instruction to the bank. On discussing the issue with the client, it was found that they thought that this was implied!!

Have a critical eye for minor details though others might think them as insignificant.

Do not assume things

This is the continuation from previous point that as a tester it is very important that you should not assume any of the requirement / issues / problems / defects. For example, never assume that in a screen where data is captured a field labeled "Clear" clears the entire content, though it is pretty evident. Ask more questions and get the affirmations from the respective persons.

Also, remember that it is necessary to test the software from the end-user's perspective and not just compliance with the requirements given by the client.

Never assume anything. It may not be true as you think!

Convincing skills

It is a skill to convince and explain to a person who has developed the software as to why a defect report written is indeed a defect. Put forth this in such a way that the developer also starts thinking along the lines of the scenario given in the defect report / requirement. Remember in such situations to put you in other person's shoes and speak accordingly. Avoid using accusing words, do not get into any arguments and do not rise to any bait a developer may throw at you. Concentrate on the issue and not on the person.

Also, while deciding the end of testing activities, it is important to bring out the impact of the open defects in the software and the implications to the business analyst / client or whoever is the logical end point contact. It is necessary to push your point through either to continue with further testing activities or to stop testing.

Develop good convincing skills!

Be factual

While reporting a defect or clarification of a requirement, be as factual as possible. Do not bring in your own suggestions / views into picture. Do not use words that describe the type of work or the person who developed the software.

For example, do not bring in words like, "badly developed software", "often crashing software", etc. Do not spell out such phrases even during interaction with the developer. Such activities will only be counter productive. This is result in people not viewing your defect reports with seriousness.

Be a good reporter of facts!

Effective listening

While discussing a defect report / requirement clarification, give a good hearing to other person's view or perspective. Understand the limitations of the software and try to find ways to resolve such issues. For example, if there exists an issue that is pertaining to display / functionality in one particular browser version, ensure that it is listed as one of the "Known issues" in the Release Notes or Limitations section or in the Read me file.

Be flexible whenever required!

Provide constructive criticism

While discussing any issues / defects / requirements clarifications with developer / business analyst do not use words that are pointing to their personal characteristics. Be very tactful in describing issues / defects and try not to point fingers at the person who developed the software or who collected the requirements for the software.

Be empathetic

Listen to the developer / the business analyst who developed / collected the requirements carefully. Try to understand the reality and limitations. Do not argue over trivial issues. Try to resolve limitations / issues in different possible ways.

Develop good rapport with other teams, it helps!

Effective follow up of issues

Many a times, defects are written and deferred to next release. At the start of next release not all of them are picked up and fixed. The status of defects that are left out from previous releases need to be discussed at the beginning of every release with the business analyst / development team. Also, any issue that has not been converted to defect needs to have a closer follow up. This needs to be documented as Open issues at the end of the testing activity.

Be good at follow-ups!

Good reviewer

Be a good reviewer and look out for inconsistencies of implementation of a particular requirement across different sections. Review all user documentation apart from testing the software. Check out for inconsistencies in the description of the software, look for glossary and an index. This enables for easy search on topics of user's choice.

Sharpen your reviewing skills!

Conclusion

As a tester you need special set of interpersonal skills more than the technical and functional skills. More importantly patience should be there. Make a start, be aware and practice.

How to Write a Useful Bug Report?

How to Write a Useful Bug Report

Useful bug reports are ones that get bugs fixed. A useful bug report normally has two qualities:

1. Reproducible. If an engineer can't see the bug herself to prove that it exists, she'll probably stamp your bug report "WORKSFORME" or "INVALID" and move on to the next bug. Every detail you can provide helps.

2. Specific. The quicker the engineer can isolate the bug to a specific area, the more likely she'll expediently fix it. (If a programmer or tester has to decipher a bug, they may spend more time cursing the submitter than solving the problem.)

Description: Please provide a detailed problem report in this field. Your bug's recipients will most likely expect the following information:

Overview Description: More detailed expansion of summary.

-Drag-selecting any page crashes Mac builds in NSGetFactory

Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.

1) View any web page. (I used the default sample page, resource:/res/samples/test0.html)
2) Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.)

Actual Results: What the application did after performing the above steps.

-The application crashed. Stack crawl appended below from MacsBug.

Expected Results: What the application should have done, were the bug not present.

-The window should scroll downwards. Scrolled content should be selected. (Or, at least, the application should not crash.)

Build Date & Platform: Date and platform of the build that you first encountered the bug in.