MT - 56 - Why do we need a test management tool ?

We have several defect management tool emerging now a days like TFS, JIRA , HP ALM , etc. So here I am discussing few of the reasons :

1) Distributed Teams : Now a days we have global teams across different locations and different time zones. Mostly we have three teams that is development , testing and management teams. There may be variation in the time zone , so to be on the same page we need a test management tool. The tool lets them to communicate effectively with updated status.

2) Defect management : In most of SDLC and STLC models the testing revolves around requirements and code. There are several bugs and issues which need to be fixed and tracked as well. At small level we can do it manually but it becomes difficult to manage if the count becomes high. So in this scenario we use we use tool to map the defect against a code or a requirement. Also we can classify , assign and monitor the defect.


3) Map the tasks and issues against workflows : we can define workflows in JIRA for a particular issue/task/sub-task. Once defined we can track the tasks easily having different statuses. For Eg - Suppose a scenario where a bug is fixed by developer but the issue still persists in code when retested, in this case the tester will re-open the defect. Similarly we can have different statuses like closed , open , start work , etc. we can also customize our workflow.


4) Reporting : we can pull the daily status to fing the velosity of the sprint and the progress of work we have covered so far. We can also pull the status in excel.


5) Support to Agile and Kanban - Some management tools like JIRA gives a flexibility to plan our work in Agile and Kanban techniques. We can create product backlog and we can pull the user stories to the particular sprints.


6) We can fill all the details and hook a attachment to a particular story. We can also see the time taken by a particular task to complete. We can see the current status of a story.

MT - 55 - Spiral Model !

Spiral model is one of the best models that may be used for risk-based projects. In this model more emphasis is given on risk analysis. The spiral model is favored for large, expensive, and complicated projects.The spiral model combines the idea of iterative development with the systematic, controlled aspects of the waterfall model.It has basically following four phases :

Planning Phase/Determine Objective: Requirements are gathered during the planning phase. Requirements like ‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement specifications’. This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase.This also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral the product is deployed in the identified market.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. Risk Analysis includes identifying, estimating, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun. 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/Design 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. Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and final design in the subsequent spirals.

Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.after testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.

These all phases keeps on rotating in spiral.After one spiral the planning includes the plans for next iterations and so on. Although this is a complex model but can be used to risk-based projects.




Advantages : 

- Changing requirements can be accommodated.

- Allows for extensive use of prototypes

- Requirements can be captured more accurately.

- Users see the system early.

- Development can be divided into smaller parts and more risky parts can be developed earlier which helps better risk management.

- A highly customized product can be developed using this.

MT - 54 - SOAK/Endurance Testing !

Also known as endurance testing , soak testing is done to see the behaviour of the system after giving load for a prolonged period of time.Soak Testing is the form of Performance Testing, which incorporate testing a system with expressive load extended over an expressive period of time, to discover how the system and product behaves under repeated use.

As an example we can take the closing of the banks that are done at the end of year. At this time there is a huge load on the server for a prolonged period of time. At this time we would not want the application to crash or show slow response time, so endurance testing is done.

 A soak test would generally execute some times more transactions in an entire (full) day (or night) that intend be expected in a busy day, to distinguish any performance issues that appear after a immense number of transactions have been executed.A soak test also called an endurance test is generally done to originate whether an application can handle with the continuous expected load. A soak test is also used to audit whether there is any performance degradation afterwards a long period of activity.The goal is to discover how the system behaves under sustained use. That is, to ensure that the throughput and/or response times after some long period of sustained activity are as good or better than at the beginning of the test.It may also be used to check memory leaks and failure of the application over a long period of time.

MT - 53 - Spike Testing !

Spike Testing is a form of load testing process in which an application is tested with unusual increment and decrements in the load. The system is unexpectedly loaded and unloaded. It is done to notice how actually the system reacts with unexpected rise and decline of users.

Spike testing is mechanism of testing which means when in a web page frequent number of visitor access the page unexpectedly increases to maximum then obviously performance of the page breaks down. So the mechanism of testing a performance about web page due to unexpected sort of traffic on the page is always called as Spike testing.

Spike testing is usually done by unexpectedly increasing the number of loads generated by users by a very enormous amount and observing the dramatic behavior of the system.The goal of spike testing is to regulate whether performance will deteriorate, the system will always fail, or it will be able to hold dramatic changes in load.




Spikes represent the sudden rise and fall of number of users


As an example we can take the exam results declaration. Suppose the results will be declared at 9.00 A.M. So exactly at 9.00 A.M. the load will increase suddenly for a particular period of time. So this sudden rise and file needs to be tested for an application .

MT - 52 - Volume testing!

Volume testing is a kind of non-functional testing. As the name says the volume testing is performed to see the behave of the system over a large volume of data.
As an example we can take an application which is performing very well but there are very users for that application. But in future the number of users will keep growing and growing. Hence we would want to see the response of the system over a larger volumes.The purpose of volume testing is to determine system performance with increasing volumes of data in the database.
Also we can take an example of online ticket booking. Suppose a alrge number of users started booking tickets. So here we need to see that how the system is responding over a large volumes. We can also  check that the correct data is saved without failure.
Volume test shall check if there are any problems when running the system under test with realistic amounts of data, or even maximum or more. Volume test is necessary, as ordinary function testing normally does not use large amounts of data,rather the opposite.

MT - 51 - Stress Testing !

Like load testing stress testing is also non-functional testing. Stress testing is a generic term used to describe the process of putting a system through exertion or stress. The Stress test can combine aspects of performance testing and security testing. It is performed to see the behaviour of the system beyond its maximum capacity. It may be used to find the breaking point of the system where the system starts behaving abruptly.Stress tests commonly put a greater emphasis on robustness, availability, and error handling under a heavy load, than on what would be considered correct behaviour under normal circumstances.

Lets take an example that on an application there are maximum of 1000 visitors on the daily basis. Now to perform stress test we will see the behave of the system beyond 1000 users. We will observe the throughput and response time  at increased loads beyond 1000. We keep on increasing the load until the system breaks.

MT - 50 - Load Testing!

Load testing is a kind of non-functional testing which is all about measuring response of the application on the given load to measure the response and see the behaviour of system.A load test enables you to measure response times, throughput rates, and resource-utilization levels, and to identify your application’s breaking point, assuming that the breaking point occurs below the peak load condition.Load testing is done to see the behaviour of the system on the given controlled load whether its normal or too high. It helps seeing the behaviour of the system at different expected loads.It involves simulating real-life user load for the target application. It helps you determine how your application behaves when multiple users hits it simultaneously.

Lets take an example of the application which is having 1000 users on the daily basis and criteria given is that the response time should not be more than 2 seconds. So now to do the load testing we start measuring the response of the system from a low load. Suppose we start at 40 users then we keep on increasing till it reaches 1000 and at different stages we measure its response.Its done in such way because there may be possibility that on the load of 100 users the response time becomes 5 seconds so there will be no use of testing it at heigher load.

The primary goal of load testing is to define the maximum amount of work a system can handle without significant performance degradation on a given controlled load.

Tools Used : Load Runner , Jmeter

MT - 49 - Incremental Model (Multi-waterfall)

The incremental build model is a method of software development where the product is designed, implemented and tested incrementally (a little more is added each time) until the product is finished.In incremental model the whole requirement is divided into various builds. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle.  Cycles are divided up into smaller, more easily managed modules. Each modules are developed separately with separate requirement analysis phase.The product is decomposed into a number of components, each of which is designed and built separately (termed as builds). Each component is delivered to the client when it is complete.Each developed module in Incremental Model is standalone feature and could be delivered to the end users to use it. So ,a working version of software is produced during the first module, so you have working software early on during the software life cycle.Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.

We can explain the model with the help of following two diagrams :








Advantages of Incremental Model:

-Easier to manage risk because risky pieces are identified and handled during it’d iteration

-Core product is developed first i.e main functionality is added in the first increment.

-More flexible to add the new features based on the requirement.

-Each build is reviewed by client so very less probability to miss any requirement.

-Less resource required.

-Easy to manage the project and easy risk coverage.

-Easy to perform testing as each modules developed separately.

-Generates working software quickly and early during the software life cycle.

-This model is more flexible – less costly to change scope and requirements.

-It is easier to test and debug during a smaller iteration.

-In this model customer can respond to each built.

-Lowers initial delivery cost.

-It is generally easier to test and debug than other methods of software development because relatively smaller changes are made during each iteration. This allows for more targeted and rigorous testing of each element within the overall product.

-After each iteration, regression testing should be conducted. During this testing, faulty elements of the software can be quickly identified because few changes are made within any single iteration.

Disadvantages of Incremental Model:

-Need full specification and requirements so that number of modules could be decided.

-Final cost estimation might not be estimated in the beginning and depends on the complexity of the project.

-Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.

-As additional functionality is added to the product, problems may arise related to system architecture which were not evident in earlier prototypes.

-Each phase of an iteration is rigid and do not overlap each other.

-Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle

MT - 48 - V-Model

First of all I'd like to discuss why V-model was designed if we already had Waterfall model in place.
The waterfall was sequential model and the testing was covered at the last phase of the product. So the defect caught at last phase of the the development incurs more cost than in the beginning phase.
V - Model is an extension of the waterfall model and is based on association of a testing phase for each corresponding development stage.. So this model allowed us to catch the defects at early stage of development. In this model development and testing activities were done side by side.


V- Model Diagram


Verification Phases :

Requirements analysis : It is the first phase of the verification process . This is the first phase in the development cycle where the product requirements are understood from the customer perspective. This phase involves detailed communication with the customer to understand his expectations and exact requirement. This is a very important activity and need to be managed well, as most of the customers are not sure about what exactly they need. The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing.

The high-level design (HLD)(System Design):  Once you have the clear and detailed product requirements, it.s time to design the complete system. System design would comprise of understanding and detailing the complete hardware and communication setup for the product under development. System test plan is developed based on the system design. Doing this at an earlier stage leaves more time for actual test execution later.


The low-level design (LLD)(Architecture design) phase is where the actual software components are designed. It defines the actual logic for each and every component of the system. Class diagram with all the methods and relation between classes comes under LLD. Component tests are created in this phase as well.The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. With this information, integration tests can be designed and documented during this stage.

The implementation phase(Module design) : In this phase the detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD). It is important that the design is compatible with the other modules in the system architecture and the other external systems. Unit tests are an essential part of any development process and helps eliminate the maximum faults and errors at a very early stage. Unit tests can be designed at this stage based on the internal module designs.

Coding: The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The best suitable programming language is decided based on the system and architectural requirements. The coding is performed based on the coding guidelines and standards. The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.

Validation Phases
Following are the Validation phases in V-Model:

Unit Testing: Unit tests designed in the module design phase are executed on the code during this validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing.

Integration Testing: Integration testing is associated with the architectural design phase. Integration tests are performed to test the coexistence and communication of the internal modules within the system.

System Testing: System testing is directly associated with the System design phase. System tests check the entire system functionality and the communication of the system under development with external systems. Most of the software and hardware compatibility issues can be uncovered during system test execution.

Acceptance Testing: Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. Acceptance tests uncover the compatibility issues with the other systems available in the user environment. It also discovers the non functional issues such as load and performance defects in the actual user environment.



Advantages of V-model:

-Simple and easy to use.

-Testing activities like planning, test designing happens well before coding. This
saves a lot of time. Hence higher chance of
success over the waterfall model.

-Easy to manage due to the rigidity of the model . each phase has specific deliverables and a review process.

-Proactive defect tracking – that is defects are found at early stage.

-Avoids the downward flow of the defects.

-Works well for small projects where requirements are easily understood.


Disadvantages of V-model:

-Very rigid and least flexible.

-Poor model for long and ongoing projects.

-Software is developed during the implementation phase, so no early prototypes of the software are produced.

-If any changes happen in midway, then the test documents along with requirement documents has to be updated.

-No working software is produced until late during the life cycle.

MT - 47 - Waterfall Model (Linear-sequential model ).

The best model for the sequential software design is waterfall model. Since the process flow is sequentially from top to down so it is called waterfall model. This model was considered to be the first process model or linear-sequential model. It is a simple linear model without phase overlapping. In this model the next phase begins only when the last phase ends.
This model is preferred only when requirements are very well- known clear and  fixed, product definition is stable and there are ample of resources and time.

Sequential flow diagram :




Requirement Gathering and analysis:This is the first phase of the model where all the possible requirements of the system to be developed are captured and documented.During this phase research is being conducted which includes brainstorming about the software, what it is going to be and what purpose is it going to fulfil.Software requirements specification includes the complete information about how actual end users are expecting from the system.

System Design: After the requirement gathering is done, there comes the phase of system design.System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.If the first phase gets successfully completed and a well thought out plan for the software development has been laid then the next step involves formulating the basic design of the software on paper.

Implementation: This is the third phase. Here the system is developed or implemented with the help of the above phases.Here the whole modules are divided into units and each units are developed and unit tested.

Integration and System Testing: In the previous model the system requirements are divided into models & each model is developed & tested separately.In this phase all units are integrated & done the system testing to check whether the all models/units are integrated properly or not & the system as whole doing as mention as per the system requirement document, so we call this phase as the Integration & System Testing. Upon complete testing of software is done then actual Software is successfully send to customer.

Deployment of system: Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market.

Maintenance: There are some issues , change orders which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment. This is a long tyerm process and the system keep on getting enhanced.


Advantages of waterfall model:

- This model is simple and easy to understand and use.

-It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.

- The project requires the fulfilment of one phase, before proceeding to the next. Therefore if there is a fault in this software it will be detected during one of the initial phases and will be sealed off for correction.

-In this model phases are processed and completed one at a time. Phases do not overlap.
Waterfall model works well for smaller projects where requirements are very well understood.

-For each stage deadlines can be set which will help to develop the system on decided time frame.

 Disadvantages of waterfall model:

- It requires a lot of time and resources

-Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.

-No working software is produced until late during the life cycle.

-High amounts of risk and uncertainty.

-Not a good model for complex and object-oriented projects.

-Poor model for long and ongoing projects.

- The testing period comes very late in this model.

- To make it customer happy such new requirement need to be implemented in new version of system which leads to added cost to system development.

-Not suitable for the projects where requirements are at a moderate to high risk of changing.

MT - 46 - SRS , FRS and BRS !

SRS: System Requirement Specification:
It depicts entire system flow, how data is going to flow into the system and overall functionality of the system. SRS says brief about each module's functionality and doesn't include in-depth functionality of each page and module.

BRS: Business Requirement Specification:
This document is called as high level document includes all the requirement demanded by the client. Ideally, this document simply includes all the requirements should be part of proposed system.


FRS: Functional Requirement Specification:
FRS includes requirements, converted into functionality and says that how this requirement is going to work as a part of proposed system.

SRS	FRS	BRS
1. It means “Software Requirement Specification” (SRS).	1. It means “Functional Requirement Specification” (FRS).	1. It means “Business Requirement Specification” (BRS).
2. It deals with resources provided by Company.	2. It deals with requirements given by client.	2. It deals with aspects of business requirements.
3. It always includes Use cases to describe the interaction of the system.	3. In this Use cases are not included.	3. In this Use cases are also not included.
4. It is derived from BRS.	4.It is also derived by discussions.	4.It is derived from the client requirement and discussions.
5. It is developed by System Analyst. And it is also known as User Requirement Specifications.	5. It is always developed by developers and engineers.	5. It is always developed by Business Analyst.
6. In SRS, we describe all the business functionalities of the application.	6. In FRS, we describe the particular functionalities of   every single page in detail from start to end.	6.In BRS, we defines what exactly customer wants. This is the document which is followed by team from start to end.
7. SRS tells means explains all the functional and non functional requirements.	7. FRS tells means explains the sequence of operations to be followed on every single process.	7. BRS tells means explains the story of whole requirements.
8. SRS is a complete document which describes the behavior of the system which would be developed.	8. FRS is a document, which describes the Functional requirements i.e. all the functionalities of the system would be easy and efficient for end user.	8. BRS is a simple document, which describes the business requirements on a quite broad level.

NOTE : FRS and BRS is little confusing : BRS includes list of requirements which are demanded by client and should be part of proposed system; whereas, FRS includes requirement converted into the way it is going to work as a part of proposed system.

MT - 45 - Test scenario and Test case - Difference!

Often we get confused between test case and Test scenario. These are two important points from testing point of view :

Test Case	Test Scenario
Test Case is ‘How to be tested’	Test Scenario is ‘What to be tested’
Test case consist of test case name, Precondition, steps / input condition, expected result.	Test scenario consists of a detailed test procedure. We can also say that a test scenario has many test cases associated with it. Before executing the test scenario we need to think of test cases for each scenario.
Test cases are low level actions and it can be derived from test scenarios.	Test scenarios are the high level classification of test requirement grouped depending on the functionality of a module and it can be derived from use cases.
Each test case checks for a single functionality or test scenario.	Test scenario may have numbers of test cases.
Test case means detailed documenting the cases which help executing while testing.	Test Scenario means talking and thinking requirements in detail.
Test cases are set of steps which performed on system to verify the expected output.	Test scenario is thread of operations.
Test cases are more importance in case where development is happening onsite and QA is happening Off shored. It will help to understand and make both developer and QA in sync.	Test scenarios are more important when time to write test cases is no sufficient and team members are agree with the detailed one liner scenario.
Writing test cases is one time effort which can be used in future while executing regression test case. While reporting defects it will help tester to link the defect with test case id.	In new software testing generation it is new idea and time saver activity. The addition and modification (easy maintainability) of test scenarios is easy and independent on specific person.
The intention of test cases is to capture all the requirements. If developer missed something then it is easy to catch while executing these full-proof test cases.	One of the most positive point about test scenario is good test scenarios reduces the complexity and repeatability of product.
It requires more effort due to detailed test case which talks about how to test .	If the test scenario not detailed enough then it might take some time to discussion and understand what test scenario is exactly talking about.
Test cases has one to one relation	Test scenarios has one to many relation.
Test cases are the set of valid and invalid executable procedure of a test scenario. A test case with valid functionality is called positive test case and a test case with invalid functionality is called negative test case.	A test scenario may have one or more test cases associated to it.

MT - 44 - Error Seeding or Bee-bugging ?

Bee-bugging or error seeding is a process of intentionally adding errors to the code to evaluate the amount of residual errors during the phase of testing. In Simple language we can say that we can estimate the total error found in the application to that of the error seeded in the code. This may be used to map the testcases and the level of testcases designed. Additionally we can check that the behaviour of application after introducing errors. IN error-seeding technique a certain number of errors are sown in code while in mutation testing a change in the statement is done (Refer blog 26 for mutation testing).

Here are few differences between them

Error Seeding	Mutation Testing
No mutants are present here.	Mutants are developed for testing.
Here source code is tested within itself.	Here mutants are combined, compared for testing to find error introduced.
Errors are introduced directly.	Special techniques are used to introduce errors.
Test cases which detect errors are used for testing.	Here, test cases which kill mutants are used for testing.
It is less efficient error testing technique.	It is more efficient than error seeding	.
It requires less time.	It is more time consuming.
It is economical to perform.	It is expensive to perform.
It is better method for bigger problems.	It is a better method for small size programs.

MT - 43 - What is baseline testing?

As the name says , base-lining is defined as the standard that forms the base for any software or application.
Its a type of non-functional testing which refers to the validation of the documents and specifications on which the test-cases will be designed.In configuration management, a baseline is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change Normally SRS is considered as the baseline of testing.
Baseline is the point at which some deliverable produced during the software engineering process is put under formal change control.Base Lining is the very important process in the Configuration Management.Once the base lining is done the application is blocked for the editing. Only after the base lining we can give the version no to the particular application.A specification or software product that has been formally reviewed or agreed upon ,that thereafter serves as the basis for further development,and that can be changed only through a formal change control process.he point at which some deliverable produced during the software engineering process is put under formal change control.

MT - 42 - What is component testing?

Let us see what is component in software. A component may be a class or a cluster of classes tightly coupled, but conceptually its always a unit.So lets talk about component testing.
Component testing, similar to unit testing but with higher level of integration, is a testing method which  searches for defects in, and verifies the functioning of software . Here we check  each modules , programs , objects and classes at unit level. Component testing may be done in isolation from the rest of the system depending on the context of the development life cycle and the system. Most often stubs and drivers are used to replace the missing software and simulate the interface between the software components in a simple manner. A stub is called from the software component to be tested; a driver calls a component to be tested. The stubs and drivers are used to test the missing components in the application.

There are basically three types of components that we can test :

Reusable components - Components intended for reuse should be tested over a wider range of values than a component intended for a single focused use.

Domain components - Components that represent significant domain concepts should be tested both for correctness and for the faithfulness of the representation.

Commercial components - Components that will be sold as individual products should be tested not only as reusable components but also as potential sources of liability.

MT - 41 - Positive and Negative testing !

- Positive Testing is testing process where the system validated against the valid input data While Negative Testing is testing process where the system validated against the invalid input data.

- In positive testing tester always check for only valid set of values and check if a application behaves as expected with its expected inputs. A negative test checks if a application behaves as expected with its negative inputs.

- The main intention of positive testing is to check whether software application not showing error when not supposed to & showing error when supposed to.The main intention of negative testing is to check whether software application not showing error when supposed to & showing error when not supposed to.

- Positive testing is to be carried out keeping positive point of view & only execute the positive scenario. Negative testing is to be carried out keeping negative point of view & only execute the test cases for only invalid set of input data.

- Positive Testing always tries to prove that a given product and project always meets the requirements and specifications. Under Positive testing is test the normal day to day life scenarios and check the expected behaviour of application.Negative testing is a testing process to identify the inputs where system is not designed or un-handled inputs by providing different invalid. The main reason behind Negative testing is to check the stability of the software application against the influences of different variety of incorrect validation data set

-Positive testing can be performed on the system by providing the valid data as input. Negative Testing can be performed on the system by providing invalid data as input.

- Positive testing is done with intention of passing the testcase while negative testing is done to fail the testcase.

- If we talk about BVA(boundary value analysis) , positive testing is done with the positive testdata consists of value inside the boundary while negative testcases are out the bouindary.

Positive Testing (Valid)	Negative Testing (Invalid)
1. Positive Testing means testing the application or system by giving valid data.	1. Negative Testing means testing the application or system by giving invalid data.
2. In this testing tester always check for only valid set of values.	2. In this testing tester always check for only invalid set of values.
3. Positive Testing is done by keeping positive point of view for example checking the mobile number field by giving numbers only like 9999999999.	3. Negative Testing is done by keeping negative point of view for example checking the mobile number field by giving numbers and alphabets like 99999abcde.
4. It is always done to verify the known set of Test Conditions.	4. It is always done to break the project and product with unknown set of Test Conditions.
5. This Testing checks how the product and project behave by providing valid set of data.	5. This Testing covers those scenarios for which the product is not designed and coded by providing invalid set of data.
6. Main aim means purpose of this Testing is to prove that the project and product works as per the requirements and specifications.	6. Main aim means purpose of this Testing is try to break the application or system by providing invalid set of data.
7. This type of Testing always tries to prove that a given product and project always meets the requirements and specifications of a client and customer.	7. Negative Testing is that in which tester attempts to prove that the given product and project does, which is not said in the client and customer requirements.

MT - 40 - Exhaustive testing - Is it possible in real ?

Exhaustive testing is an approach in which all the possible inputs are tested against a system. It covers all the data combinations to test a system.In this type of testing we try to check the output given by the software by entering all the possible inputs, in fact we use all the permutations and combinations of the inputs. Each element of code is verified under this process. This way we are able to find software endurance as well as its ability to handle extreme situations. Exhaustive testing is the process of testing for absolutely everything just to make sure that the product cannot be destroyed or crashed by some random inputs. It takes into consideration all possible combinations of inputs, usage scenarios as well as random situations and inputs.

Is it possible ?
So here I'd like to say that it totally depends on the type and size of application. If our application is very small then the ans will be yes but for very large system its impossible.Although it provides complete surity of correctness of application but its rarely done in real practice.

MT - 39 - Verification and validation ( V &V ) or Static and dynamic testing

Used in software testing , validation and verification are two independent procedures that are used to check the product or any setup meets requirements and specifications or not.

Validation(Static testing):

Validation is the process of evaluating the final product to check whether the software meets the business needs. In simple words the test execution which we do in our day to day life are actually the validation activity which includes smoke testing, functional testing, regression testing, systems testing etc

Verification(Dynamic testing):

Verification is a process of evaluating the intermediary work products of a software development lifecycle to check if we are in the right track of creating the final product.


There are two aspects of V&V tasks

Confirms to requirements (Producer view of quality)
Fit for use (consumers view of quality)

Producer’s view of quality, in simpler terms means the developers perception of the final product.
Consumers view of quality means users perception of final product.
When we carry out the V&V tasks, we have to concentrate both of these view of quality.

Methods of Verification

1. Walkthrough
2. Inspection
3. Review

Methods of Validation

1. Different phases of testing
2. End Users


Difference : 

Verification	Validation
1. Verification is a static practice of verifying documents, design, code and program. Its done without executing the actual code.	1. Validation is a dynamic mechanism of validating and testing the actual product. Its done with t he execution of the code.
2. To ensure that the product is being built according to the requirements and design specifications. In other words, to ensure that work products meet their specified requirements.	2. To ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfils its intended use when placed in its intended environment.
3. Its discussion based checking of documents , code , RTM and files.	3. It is actual testing of system through execution of program.
4. Verification uses methods like inspections, reviews, walkthroughs, and Desk-checking etc.	4. Validation uses methods like black box (functional)  testing, gray box testing, and white box (structural) testing etc.
5. Verification is to check whether the software conforms to specifications.It makes sure that the product is designed to deliver all functionality to the customer.	5. Validation is to check whether software meets the customer expectations and requirements.
6. Checks “Are we building the product right”?	6. Checks “Are we building the right product”?
7. Target is requirements specification, application and software architecture, high level, complete design, and database design etc.	7. Target is actual product-a unit, a module, a bent of integrated modules, and effective final product.
8. Verification is done by QA team to ensure that the software is as per the specifications in the SRS document.	8. Validation is carried out with the involvement of testing team.
9. It generally comes first-done before validation.	9. It generally follows after verification.

Advantages of Software Verification :

Verification helps in lowering down the count of the defect in the later stages of development.

Verifying the product at the starting phase of the development will help in understanding the product in a better way.

It reduces the chances of failures in the software application or product.

It helps in building the product as per the customer specifications and needs.