What is Software Testing ?

Software Testing is a process used to identify the Correctness , Completeness and Quality of developed computer software. 

Software Testing is done with an intention to find bugs .It involves operation of a system or application under controlled conditions and evaluating the results.

What is difference between Severity and Priority ?

There are two key things in defects of the Software Testing. They are:

1)     Severity

2)     Priority

What is the difference between Severity and Priority?

1)  Severity:

It is the extent to which the defect can affect the software. In other words it defines the impact that a given defect has on the system. For example: If an application or web page crashes when a remote link is clicked, in this case clicking the remote link by an user is rare but the impact of  application crashing is severe. So the severity is high but priority is low.

Severity can be of following types:

• Critical: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable and there is no acceptable alternative method to achieve the required results then the severity will be stated as critical.
• Major: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable but there exists an acceptable alternative method to achieve the required results then the severity will be stated as major.
• Moderate: The defect that does not result in the termination, but causes the system to produce incorrect, incomplete or inconsistent results then the severity will be stated as moderate.
• Minor: The defect that does not result in the termination and does not damage the usability of the system and the desired results can be easily obtained by working around the defects then the severity is stated as minor.
• Cosmetic: The defect that is related to the enhancement of the system where the changes are related to the look and field of the application then the severity is stated as cosmetic.

2)  Priority:

Priority defines the order in which we should resolve a defect. Should   we fix it now, or can it wait? This priority status is set by the tester to the developer mentioning the time frame to fix the defect. If high priority is mentioned then the developer has to fix it at the earliest. The priority status is set based on the customer requirements. For example: If the company name is misspelled in the home page of the website, then the priority is high and severity is low to fix it.

Priority can be of following types:

• Low: The defect is an irritant which should be repaired, but repair can be deferred until after more serious defect have been fixed.
• Medium: The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.
• High: The defect must be resolved as soon as possible because the defect is affecting the application or the product severely. The system cannot be used until the  repair has been done.

Few very important scenarios related to the severity and priority which are asked during the interview:

High Priority & High Severity: An error which occurs on the basic functionality of the application and will not allow the user to use the system. (Eg. While Login the application [Login] button donot work then this is high priority and high severity bug.)

High Priority & Low Severity: The spelling mistakes that happens on the cover page or heading or title of an application.

High Severity & Low Priority: An error which occurs on the functionality of the application and will not allow the user to use the system but on click of link which is rarely used by the end user.

Low Priority and Low Severity: Any cosmetic or spelling issues which is within a paragraph or in the report (Not on cover page, heading, title).

What is Defect Life Cycle ?

Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced. Defect Life Cycle is related to the bug found during testing.

The bug has different states in the Life Cycle. The Life cycle of the bug can be shown diagrammatically as follows:

Life Cycle includes following status:-

1. New: When a defect is logged and posted for the first time. It’s state is given as new.
2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned.
3. Open:  At  this state the developer has started analyzing and working on the defect fix.
4. Fixed:  When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
5. Pending retest:  After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.
6. Retest:  At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not.
7. Verified:  The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”.
8. Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again.
9. Closed:  Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.
10. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“.
11. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.
12. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 
13. Not a bug:  The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.

What is cost of defects in Software Testing ?

The cost of defects can be measured by the impact of the defects and when we find them.

• Earlier the defect is found lesser is the cost of defect. For example if error is found in the requirement specifications then it is somewhat cheap to fix it. The correction to the requirement specification can be done and then it can be re-issued. In the same way when defect or error is found in the design then the design can be corrected and it can be re-issued. But if the error is not caught in the specifications and is not found till the user acceptance then the cost to fix those errors or defects will be way too expensive.

If the error is made and the consequent defect is detected in the requirement phase then it is relatively cheap to fix it.

• If a defect is introduced in the requirement specification and it is not detected until acceptance testing or even once the system has been implemented then it will be much more expensive to fix. This is because rework will be needed in the specification and design before changes can be made in construction; because one defect in the requirements may well propagate into several places in the design and code; and because all the testing work done-to that point will need to be repeated in order to reach the confidence level in the software that we require.

It is quite often the case that defects detected at a very late stage, depending on how serious they are, are not corrected because the cost of doing so is too expensive.

What is Software Validation ?

• Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs.
• Validation is done at the end of the development process and takes place after verifications are completed.
• It answers the question like: Am I building the right product?
• Am I accessing the right data (in terms of the data required to satisfy the requirement).
• It is a High level activity.
• Performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment.
• Determination of correctness of the final software product by a development project with respect to the user needs and requirements.

Advantages of Validation:

1. During verification if some defects are missed then during validation process it can be caught as failures.
2. If during verification some specification is misunderstood and development had happened then during validation process while executing that functionality the difference between the actual result and expected result can be understood.
3. Validation is done during testing like feature testing, integration testing, system testing, load testing, compatibility testing, stress testing, etc.
4. Validation helps in building the right product as per the customer’s requirement and helps in satisfying their needs.

Validation is basically done by the testers during the testing. While validating the product if some deviation is found in the actual result from the expected result then a bug is reported or an incident is raised. Not all incidents are bugs. But all bugs are incidents. Incidents can also be of type ‘Question’ where the functionality is not clear to the tester.

Hence, validation helps in unfolding the exact functionality of the features and helps the testers to understand the product in much better way. It helps in making the product more user friendly.

What is software Verification ?

• It makes sure that the product is designed to deliver all functionality to the customer.
• Verification is done at the starting of the development process. It includes reviews and meetings, walkthroughs, inspection, etc. to evaluate documents, plans, code, requirements and specifications.
• Suppose you are building a table. Here the verification is about checking all the parts of the table, whether all the four legs are of correct size or not. If one leg of table is not of the right size it will imbalance the end product.Similar behavior is also noticed in case of the software product or application. If any feature of software product or application is not up to the mark or if any defect is found then it will result into the failure of the end product. Hence, verification is very important. It takes place at the starting of the development process.
• It answers the questions like: Am I building the product right?
• Am I accessing the data right (in the right place; in the right way).
• It is a Low level activity
• Performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards.
• Demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle.

Advantages of Software Verification :

1. Verification helps in lowering down the count of the defect in the later stages of development.
2. Verifying the product at the starting phase of the development will help in understanding the product in a better way.
3. It reduces the chances of failures in the software application or product.
4. It helps in building the product as per the customer specifications and needs.

What are the principles of Software Testing ?

There are seven principles of testing . They are as follows:

1) Testing shows presence of defects:Testing can show the defects presence, but cannot prove that there are no defects. Even after testing the application or product thoroughly we cannot say that the product is 100% defect free. Testing always reduces the number of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness.

2) Exhaustive testing is impossible: Testing everything including all combinations of inputs and preconditions is not possible. So, instead of doing the exhaustive testing we can use risks and priorities to focus testing efforts. For example: In an application in one screen there are 15 input fields, each having 5 possible values, then to test all the valid combinations you would need 30  517  578  125  (5¹⁵) tests. This is very unlikely that the project timescales would allow for this number of tests. So, accessing and managing risk is one of the most important activities and reason for testing in any project.

3) Early testing: In the Software Development Life Cycle testing activities should start as early as possible and should be focused on defined objectives.

4) Defect clustering: A small number of modules contains most of the defects discovered during per-release testing or shows the most operational failures.

5) Pesticide paradox: If the same kinds of tests are repeated again and again, eventually the same set of test cases will no longer be able to find any new bugs. To overcome this “Pesticide Paradox”, it is really very important to review the test cases regularly and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

6) Testing is context depending: Testing is basically context dependent. Different kinds of sites are tested differently. For example, safety – critical software is tested differently from an e-commerce site.

7) Absence – of – errors fallacy: If the system built is unusable and does not fulfill the user’s needs and expectations then finding and fixing defects does not help.

What are Software Testing Levels ?

Testing levels are basically to identify missing areas and prevent overlap and repetition between the development life cycle phases. In software development life cycle models there are defined phases like requirement gathering and analysis, design, coding or implementation, testing and deployment.  Each phase goes through the testing. Hence there are various levels of testing. The various levels of testing are:

1. Unit Testing : It is basically done by the developers to make sure that their code is working fine and meet the user specifications. They test their piece of code which they have written like classes, functions, interfaces and procedures.

2.Component Testing: It is also called as module testing. The basic difference between the unit testing and component testing is in unit testing the developers test their piece of code but in component testing the whole component is tested. For example, in a student record application there are two modules one which will save the records of the students and other module is to upload the results of the students. Both the modules are developed separately and when they are tested one by one then we call this as a component or module testing.

3.Integration Testing:Integration testing is done when two modules are integrated, in order to test the behavior and functionality of both the modules after integration. Below are few types of integration testing:

1. Big bang integration testing
2. Top down
3. Bottom up
4. Functional Incremental

 4. Component Integration Testing: In the example above when both the modules or components are integrated then the testing done is called as Component integration testing. This testing is basically done to ensure that the code should not break after integrating the two modules.

5.System Integration Testing: System integration testing (SIT) is a testing where testers basically test that in the same environment all the related systems should maintain data integrity and can operate in coordination with other systems.

6.System Testing: In system testing the testers basically test the compatibility of the application with the system.

7.Acceptance Testing: Acceptance testing are basically done to ensure that the requirements of the specification are met.

8.Alpha Testing: Alpha testing is done at the developers site. It is done at the end of the development process

9.Beta Testing: Beta testing is done at the customers site. It is done just before the launch of the product.

Difference between Error, Defect and Failure in software testing ?

Error: The mistakes made by programmer is knowns as an ‘Error’.  This could happen because of the following reasons:

-           Because of some confusion in understanding the functionality of the software

-           Because of some miscalculation of the values

-           Because of misinterpretation of any value, etc.

Defect: The bugs introduced by programmer inside the code are known as a defect. This can happen because of some programatical mistakes.

Failure: If under certain circumstances these defects get executed by the tester during the testing then it results into the failure which is known as software failure.

What is Defect or bugs , error in software testing?

• A defect is an error or a bug, in the application which is created. Mistake done by a programmer while designing and building the software can lead to error. These mistakes or errors mean that there are flaws in the software. These are called defects.
• Deviation from the specification mentioned in the product functional specification document is a defect. In different organizations it’s called differently like bug, issue, incidents or problem.
• When the result of the software application or product does not meet with the end user expectations or the software requirements then it results into a Bug or Defect. These defects or bugs occur because of an error in logic or in coding which results into the failure or unpredicted or unanticipated results.

Additional Information about Defects / Bugs:

While testing a software application or product if large number of defects are found then it’s called Buggy.

When a tester finds a bug or defect it’s required to convey the same to the developers. Thus they report bugs  with the detail steps and are called as Bug Reports, issue report, problem report, etc.

This Defect report or Bug report consists of the following information:

• Defect ID – Every bug or defect has it’s unique identification number
• Defect Description – This includes the abstract of the issue.
• Product Version – This includes the product version of the application in which the defect is found.
• Detail Steps – This includes the detailed steps of the issue with the screenshots attached so that developers can recreate it.
• Date Raised – This includes the Date when the bug is reported
• Reported By – This includes the details of the tester who reported the bug like Name and ID
• Status – This field includes the Status of the defect like New, Assigned, Open, Retest, Verification, Closed, Failed, Deferred, etc.
• Fixed by – This field includes the details of the developer who fixed it like Name and ID
• Date Closed – This includes the Date when the bug is closed
• Severity – Based on the severity (Critical, Major or Minor) it tells us about impact of the defect or bug in the software application
• Priority – Based on the Priority set (High/Medium/Low) the order of fixing the defect can be made.

What are software testing objectives and purpose?

Software Testing  has different goals and objectives.The major objectives of Software testing are as follows:

• Finding Defects  which may get created by the programmer while developing the software.
• Gaining confidence in and providing information about the level of quality.
• To prevent defects in future releases.
• To make sure that the end result meets the client requirments.
• To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is System Requirement Specifications.
• To gain the confidence of the customers by providing them a quality product.

Purpose of Software Testing:-  is to give a product to the client that is bug free and working up to the expectation of the client as per his requirement.

Objectives of Software Testing :-

1. It is very important to have good test coverage in order to test the software application completely and make it sure that it’s performing well and as per the specifications.

2. Test cases should be designed with maximum possibilities of finding the errors or bugs. The test cases should be very effective.  Higher the number of the defects reported the more effective are the test cases.

3. Another main objective of Software Testing is to deliver the product to the customer bug free so that customer can operate on that without any complaints.In order to make it possible tester should know as how the customers are going to use this product and accordingly they should write down the test scenarios and design the test cases. This will help a lot in fulfilling all the customer’s requirements.

4. Good Coverage is yet another objective as good coverage means that the testing has been done to cover the various areas like functionality of the application, compatibility of the application with the OS, hardware and different types of browsers, performance testing to test the performance of the application and load testing to make sure that the system is reliable and should not crash or there should not be any blocking issues. It also determines that the application can be deployed easily to the machine and without any resistance.

Why Software Testing is required ?

Software testing is very important because of the following reasons:

1. Software testing is really required to point out the defects and errors that were made during the development phases.
2. It’s essential because it make sure that product is ready as per customer satisfaction without any show stopper issue.
3. It is very important to ensure the Quality of the product before it goes on production environment. Software Testing is performed on the product that helps in gaining the confidence on the product.
4. Testing is necessary to have accurate,consistent and reliable results.It helps in delivering of high quality product. 
5. Testing is required for an effective performance of software application or product.
6. It’s important to ensure that the application should not result into any failures because it can be very expensive in the future or in the later stages of the development.
7. It’s required to stay in the business.

What is Software Testing Methodology ?

In the field of Software testing we use different types of Software Testing Methodologies.

In the Software Development Process different software development approaches are used. A software development process also known as a Software Development Life Cycle (SDLC).

Each process model has its own advantages & disadvantages, the choosing of model is based on the requirement & need of your project to do the success in process of software development.

Here are the few commonly used Software Development Life Cycle used in actual testing:

• Waterfall Model
• V Model
• Agile Model
• Spiral Model
• RAD Model

1. Waterfall Model

The Waterfall Model approach is most basic life cycle model, which is the first Process Model begins and used broadly in Software Development to make sure project success. This model is developed by Winston Royce in the early 1970. Waterfall model is software development process sequential process, as flowing progressively downwards like waterfall via multiple phases & these simple sequence of phases has its own defines activities and goals. The Waterfall model is divided into following separate phases:

• Requirement Gathering & Analysis phase,
• Software Design,
• Implementation and Testing
• Maintenance

All these phases are the sequential phases & next step is totally depends on the previous step, so that second phase is begins as only if the defined set of objectives and goals are completed first.

Diagram of Waterfall model:

  2. V Model

         In the V Model Software Development Life Cycle, based on same information(requirement specification document) the development & testing activity is started. Based on the requirement document developer team started working on the design & after completion on design start actual implementation and testing team starts working on test planning, test case writing, test scripting. Both activities are working parallel to each other. In Waterfall model & V-model they are quite similar to each other. As it is most popular Software Testing Life Cycle model so most of the organization is following this model.

The V-model is also called as Verification and Validation model. The testing activity is perform in the each phase of Software Testing Life Cycle phase. In the first half of the model Verification testing activity is integrated in each phase like review user requirements, System Design document & in the next half the Validations testing activity is come in picture.

Typical V-model shows Software Development activities on the Left hand side of model and the Right hand side of the model actual Testing Phases can be performed.

In this process “Do-Procedure” would be followed by the developer team and the “Check-Procedure” would be followed by the testing team to meets the mentioned requirements.

In the V-Model software development life cycle different steps are followed however here we will taking a most common type of V-model example. The V-model typically consist of the following phases:

1. Unit Testing: Preparation of Unit Test Cases

2. Integration Testing: Preparation of Integration Test Cases

3. System Testing: Preparation of System test cases

Diagram of V model:

3. Agile Model

   Agile development model is also a type of Incremental Model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time critical applications.  Extreme Programming (XP) is currently one of the most well known agile development life cycle model.

Diagram of Agile model:

3. Spiral Model

    The spiral model is similar to the increment model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.

Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

Diagram of Spiral model:

4. RAD Model

RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the components or functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled into a working prototype. This can quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements.

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business information flow to achieve some specific business objective. Description are identified and created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the actual system.
Testing and turnover: Test new components and all the interfaces.

What is the Difference between SDLC and STLC Life cycle ?

SDLC vs STLC is a complex debate and hence we have provided some examples to make this point clear –

1.  STLC is a part of SDLC. It is like a SET and a SUBSET. We cannot have STLC running individually on its own. It needs to wait for its roll call before implementing its phases.
2.  STLC is limited to Testing software module. SDLC is rather a vast model with more inputs and executions.
3. STLC is the most important part of the SDLC life cycle. One cannot release the final product without running it through STLC process.
4. STLC team requires skilled developers and Testers. The efficiency demand is rather high here in comparison to other parts of the SDLC module.
5. STLC is also a part of the post release update cycle. The bug fixes and end user reports are logged by the application. This log is checked and fixed while building and releasing the new version of the software or Program module.
6. STLC involes following stages:

• Preparing the test strategy.
• Preparing the test plan.
• Creating the test environment.
• Writing the test cases.
• Creating test scripts.
• Executing the test scripts.
• Analyzing the results and reporting the bugs.
• Doing regression testing.
• Test exiting.

    7. SDLC involves following stages:

• Project initiation.
• Requirement gathering and documenting.
• Designing.
• Coding and unit testing.
• Integration testing.
• System testing.
• Installation and acceptance testing. " Support or maintenance.

STLC Life cycle

Software Testing Life Cycle (STLC) defines the steps/ stages/ phases in testing of software. 
Software Testing life cycle comprises following phases.

Requirement Analysis/Requirement Review:

Requirement Analysis is the very first step in Software Testing Life Cycle (STLC). In this step Quality Assurance (QA) team understands the requirement in terms of what we will be testing & figure out the testable requirements. If any conflict, missing or not understood any requirement, then QA team follow up with the various stakeholders like Business Analyst, System Architecture, Client, Technical Manager/Lead etc to better understand the detail knowledge of requirement.

Test Planning:

Test Planning is most important phase of Software testing life cycle where all testing strategy is defined. This phase also called as Test Strategy phase. In this phase typically Test Manager (or Test Lead based on company to company) involved to determine the effort and cost estimates for entire project. This phase will be kicked off once the requirement gathering phase is completed & based on the Test Plan or Test strategy & Testing Effort Estimation  documents. Once test planning phase is completed the QA team can start with test cases development activity.

Test Case Development:

The test case development activity is started once the test planning activity is finished. This is the phase of STLC where testing team write down the detailed test cases. Along with test cases testing team also prepare the test data if any required for testing. Once the test cases are ready then these test cases are reviewed by peer members or QA lead.

Also the Requirement Traceability Matrix (RTM) is prepared. The Requirement Traceability Matrix is an industry-accepted format for tracking requirements where each test case is mapped with the requirement. Using this RTM we can track backward & forward traceability.

Test Environment Setup:

Setting up the test environment is vital part of the STLC. Basically test environment decides on which conditions software is tested. This is independent activity and can be started parallel with Test Case Development. In process of setting up testing environment test team is not involved in it. Based on company to company may be developer or customer creates the testing environment. Mean while testing team should prepare the smoke test cases to check the readiness of the test environment setup.

Test Execution:

Once the preparation of Test Case Development and Test Environment setup is completed then test execution phase can be kicked off. In this phase testing team start executing test cases based on prepared test planning & prepared test cases in the prior step.

Once the test case is passed then same can be marked as Passed. If any test case is failed then corresponding defect can be reported to developer team via bug tracking system & bug can be linked for corresponding test case for further analysis. Ideally every failed test case should be associated with at least single bug. Using this linking we can get the failed test case with bug associated with it. Once the bug fixed by development team then same test case can be executed based on your test planning.

If any of the test cases are blocked due to any defect then such test cases can be marked as Blocked, so we can get the report based on how many test cases passed, failed, blocked or not run etc. Once the defects are fixed, same Failed or Blocked test cases can be executed again to retest the functionality.

Test Cycle Closure:

Call out the testing team member meeting & evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software. Discuss what all went good, which area needs to be improve & taking the lessons from current STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC process. Test case & bug report will analyze to find out the defect distribution by type and severity. Once complete the test cycle then test closure report & Test metrics will be prepared. Test result analysis to find out the defect distribution by type and severity.

What is Test Strategy ? How it varies from Test Plan ?

A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document.

The Test Strategy document is a static document meaning that it is not updated too often. It sets the standards for testing processes and activities and other documents such as the Test Plan draws its contents from those standards set in the Test Strategy Document.

Some companies include the “Test Approach” or “Strategy” inside the Test Plan, which is fine and it is usually the case for small projects. However, for larger projects, there is one Test Strategy document and different number of Test Plans for each phase or level of testing.

COMPONENTS OF THE TEST STRATEGY DOCUMENT

• Scope and Objectives
• Business issues
• Roles and responsibilities
• Communication and status reporting
• Test deliverables
• Industry standards to follow
• Test automation and tools
• Testing measurements and metrices
• Risks and mitigation
• Defect reporting and tracking
• Change and configuration management
• Training plan

TEST PLAN

The Test Plan document on the other hand, is derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents.
The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test.

It is not uncommon to have one Master Test Plan which is a common document for the test phases and each test phase have their own Test Plan documents.

There is much debate, as to whether the Test Plan document should also be a static document like the Test Strategy document mentioned above or should it be updated every often to reflect changes according to the direction of the project and activities.

My own personal view is that when a testing phase starts and the Test Manager is “controlling” the activities, the test plan should be updated to reflect any deviation from the original plan. After all, Planning and Control are continuous activities in the formal test process.

COMPONENTS OF THE TEST PLAN DOCUMENT

• Test Plan id
• Introduction
• Test items
• Features to be tested
• Features not to be tested
• Test techniques
• Testing tasks
• Suspension criteria
• Features pass or fail criteria
• Test environment (Entry criteria, Exit criteria)
• Test deliverables
• Staff and training needs
• Responsibilities
• Schedule

This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-company

How to write effective testcases ?

Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written.

Here I will share some tips on how to write test cases, test case procedures and some basic test case definitions.

What is a test case?“A test case has components that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.” 

There are levels in which each test case will fall in order to avoid duplication efforts.
Level 1: In this level you will write the basic test cases from the available specification and user documentation.
Level 2: This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
Level 3: This is the stage in which you will group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases maximum of 10.
Level 4: Automation of the project. This will minimize human interaction with system and thus QA can focus on current updated functionalities to test rather than remaining busy with regression testing.

So you can observe a systematic growth from no testable item to a Automation suit.

Why we write test cases?The basic objective of writing test cases is to validate the testing coverage of the application. If you are working in any CMMi company then you will strictly follow test cases standards. So writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing.

How to write test cases?

Fields in test cases:

Test case id:
Unit to test: What to be verified?
Assumptions:
Test data: Variables and their values
Steps to be executed:
Expected result:
Actual result:
Pass/Fail:
Comments:

So here is a basic format of test case statement:

Verify
Using [tool name, tag name, dialog, etc]
With [conditions]
To [what is returned, shown, demonstrated]

Verify: Used as the first word of the test case statement.
Using: To identify what is being tested. You can use ‘entering’ or ‘selecting’ here instead of using depending on the situation.

For any application basically you will cover all the types of test cases including functional, negative and boundary value test cases.

Keep in mind while writing test cases that all your test cases should be simple and easy to understand. Don’t write explanations like essays. Be to the point.