Can Test Driven Development (TDD) work for data-oriented development?

Today the test driven development is quite a familiar concept among the developers and testers in the field of software engineering and technology and so is the data oriented development. 

Data oriented development is commonly known as the object oriented development. We have taken up an important question in this article which is “can test driven development work for data oriented development?”

But before answering this question we shall discuss about the two different developments involved in the question individually so that the understanding of the answer becomes easy. 

About Test Driven Development

First let us discuss about the test driven development. The test driven development as the term itself suggests is based up on carrying out the development process with the help of short development cycles that include the following steps:

1. Addition of a test: The development begins with the creation of test cases for all the features.
2. Execution of all tests in order to check the working of the new one.
3. Production of code implementing which the code can only pass the test and does not incorporates any new functionality.
4. Execution of the automated tests and observing their success.
5. Re-factoring or cleaning up of the code
6. Repetition of the whole cycle for the improvement of the functionalities.

Many development styles have been developed for the test driven development few of which are mentioned below:

1. YAGNI (you ain’t gonna need it),
2. KISS (keep it simple stupid),
3. Fake it till you make it and so on.

About Data Oriented Development

- It makes use of the models that are developed around the real world concepts.

- This development methodology involves the incorporation of the data behavior as well as the structure. 

- The process starts from the quantization of the data in to small distinguishable and discrete entities which are known as the “objects”. 

- Each of the objects created have their own inherent and unique identity. 

- Other characteristics of the data oriented development aare:

1. Classification
2. Inheritance
3. Polymorphism

- The essence of the object oriented development lies in the organization and identification of the application concepts.

- The primary focus lies with the analysis and design phases. 

- The data oriented development is known for encouraging the software developers to work and think. 

- This can be thought of as a conceptual process independent of a programming language. 

- The methodology here is to build the software model and add details to it during the design. 

- It consists of the following steps:

1. System conception
2. Analysis
3. System design
4. Class design and
5. Implementation

Can TDD work for Data Oriented Development

Now coming to our question, the answer is yes test driven development can absolutely work for the data oriented development since it has many characteristics and benefits that can be successfully incorporated in to the data oriented development:

1. Predictability: With the test driven development it is easy to predict that when the development process if finished since all the tests that they have are passed by the code.

2. Learning: With the test driven development the developers get a better understanding of the code and hence it becomes easier to develop the code that models the real world very well.

3. Reliability: Moreover the test driven development makes the data oriented development more reliable since it has a suite of regressions tests that cover all of the system aspects.

4. Speed: With the test driven development the data oriented development can be speeded up since a little time is spent debugging and mistakes are sought very soon.

5. Confidence

6. Cost

7. Scope limiting

8. Manageability

9. Documentation

What is meant by test driven development (TDD)?

Test driven development or TDD is another process in the league of the software development processes. The topic of the test driven development is in the spot light of this article. The test driven development follows from the idea of the repetition of a very short development cycles. 

Concepts of Test Driven Development (TDD)

- First of all a failing automated test case is written or created by the developer or tester which serves the purpose of defining a new function or a desired improvement. 
- Then a code to pass the above created test is also created by the developer. 
- This newly written code is then refactored in order to make it meet the acceptable standards.
- Kent Beck is credited with the discovery of the test driven development process in the year of 2003. 
- The test driven development was looked up as an encouragement for the simple designs and also as an inspiration for boosting up confidence levels.
- The test driven development has always been related to the concepts of the extreme programming which took its root in the year of 1999. 
- But, eventually it came up as an individual process with its own ways and rights. 
- The concepts of the test driven development are also employed by the programmers and developers as a measure for debugging the legacy code and improving it further. 
- The test driven development is driven by a series of automated unit tests that are created by the developer for defining the requirements of the code and then automatically produce the code for them. 
- These unit tests are comprised of assertions i.e., either true values or false values. 
- Successful passing of a test confirms the developer of the correctness of the code and that it can be further evolved and re-factored. 
- To run these automated test cases, the developers make use of the testing frame works.

Steps involved in Test Driven Development (TDD)

Addition of a Test: 
The development begins with the creation of test cases for all the features. These test cases are often expected to fail since they have been created before the implementation of those features. If these test cases do not fail then either the test case is having some defect or the proposed new feature is already in existence. Before writing the test case, the developer is supposed to fully understand the specifications and requirements of the feature using the user stories and use cases etc. This is what that makes the test driven development different from other development methodologies.


Execution of all tests in order to check the working of the new one: 
This step involves the validation of the test harness for its correct working. At this step this is also ensured that the new test is not passing without the requirement of some new code. The test itself is also tested in negative and the possibility that the newly added test will always pass out is reduced. The new test is also expected to fail because of the reason figured out.


Production of code: 
This step involves the creation of some code implementing which the code can only pass the test and does not incorporates any new functionality.


Execution of the automated tests and observing their success.


Re-factoring of code: 
This step involves the cleaning up of the code.


Repetition: 
The whole cycle is repeated for the improvement of the functionalities.

Many development styles have been developed for the test driven development like:

1. YAGNI (you ain’t gonna need it)
2. KISS (keep it simple stupid) etc.

What are different automated testing challenges?

Automated testing though being a modern testing methodology, faces challenges. Test automation is used whenever a large number of test cases are to be executed. A huge number of test cases cannot be executed manually.

AUTOMATED TESTING
- In automated testing, an automation tool or software is employed to handle the execution of the test cases.
- Such software even compares the actual outcome to the expected outcome.
- It efficiently generates the test data and also the preconditions.

MANUAL AND AUTOMATED TESTING
- Test automation process is mainly used to automate a manual testing process which is typically a much formalized one.
- Although manual testing is way more effective than the automated testing, it consumes too much of time and requires a larger effort.
- Though, manual testing is able to discover more errors and bugs, there are certain kinds of bugs that cannot be discovered up by manual testing.
- For automated testing a computer program is written that will take up the whole testing process which otherwise would have required manual work.
- Manual testing sounds like quite a drudgery! Isn’t it?
- Once the automated software is ready, the test cases can be executed quickly and can also be repeated any number of times without much fuss.
- Automated testing proves to be time, efforts and cost effective method for the software projects that are way too lengthy and need more maintenance.

CHALLENGES FACED IN AUTOMATED TESTING
Test automation tools are expensive and therefore they are employed in certain definite combinations with the manual testing. There are few challenges faced in automated testing:

1. COST EFFECTIVE
One of the challenges that automated testing faces is that it becomes cost effective only when used in the long term i.e., for regression testing of a software system or application.

2. Requirements
- The requirements for a software system or application are identified from the user stories.
- User stories are basically a description like of the software product.
- These requirements are sorted according to the priority as follows:

(a) High priority Requirements
These are the most critical requirements of a software system or application and have to be included in to the software before it is released to the public.
(b) Medium priority Requirements
These requirements are not so critical to the software system or application and hence can be worked around later. But, it should be done before the implementation.
(c) Low priority Requirements
These requirements are added just to enhance the overall quality of the software system or application. But, the software can do without these requirements.

After sorting up on the requirements in the order of their priority, the iterations for the release are planned and each iteration release takes about 1-2 months. Meanwhile too much of change occurs in the requirements of the software. Many a times such changes cause the iterations to bump. This is indeed a great challenge that hinders the implementation of the automating processes.

3. Tools
- The traditional tools don’t seem to work for all kinds of automated testing processes.
- For example, the traditional tools cannot be used for the agile automation process since they are capable of solving only the traditional problems.
- This makes it difficult to implement the automation in the early stages of the testing cycle.
- The deployment of the automated testing processes become simpler only after the whole software comes to the verge of completion since by then many issues had been settled.
- So, making a wise selection of tools is crucial for the automation and also poses a big challenge.

4. Effective resource management as the program grows poses another problem.
5. Lack of effective communication among the team members.

What are the different tips for writing test cases?

What is the foremost thing that should be taken care of to carry out effective testing? Its test cases of course! Writing test cases without thinking is not going to help because any amount of efforts and time you waste on them, you are not going to get effective results. Writing test cases forms a major component of any software testing methodology.

SOME IMPORTANT FACTS

1. Any change in the requirements tends to affect the concerned test case as well. Since the test cases are based upon the requirements, any change in requirements is reflected in the test cases. If you make any changes to the requirements, make sure you have altered the related test case also accordingly.

2. After you finish writing your test cases, revise them twice so that any error that you didn’t notice can be found out.

3. It rarely happens that all the written test cases are executed. So keep the number of test cases limited i.e., as many as you can execute. If you have less number of test cases, you will be able to focus on them properly.

4. Some test cases demand other test cases as their prerequisites. If that is the case, then you should go through the list of test cases and decide a sequence for executing the test cases.

5. Some test cases are dependent on each other and so it becomes difficult which one to execute first. So try to keep your test cases as much independent as possible.

Now keeping above points in mind, we define some tips for writing effective test cases that if followed will certainly reap you the expected results:

1. Keep your test cases as simple as possible. i.e., keep them to the point and precise. You should be able to integrate your test cases with the test plan.

2. Document your test cases.

3. Review all your test cases at least twice.

4. Include input test data along with the test cases because if the tester is to choose test data by himself/ herself, he/ she may omit the most important test data making the whole testing go in vain.

5. While writing test cases always keep in mind that the end user is the one who will use the AUT.

6. Pay due attention while writing the test cases because this will affect the whole testing process.

7. For every condition or assertion in the program, write a different test case so that you don’t mix up.

8. Make sure that your each test case tests only one aspect of the program. Otherwise you will have problems like over lapping and over complicated tests. If one test case focuses upon one aspect, then the code will get good coverage and tracking any error will be easy.

9. Prepare documentation for every test case. Your documentation should have assertions and description of 4 stages (set up, execution, verification, and output) of the test case.

10. Select a basis on which you want to organize your test cases like functionality or class, so that it becomes easy for you to add new test cases later. The order of your test cases should be consistent.

11. The test cases should be able to execute with a good speed, should be independent as discussed above, should be small and precise so that they can be repeated without much hassle is needed to and should be transparent. By transparency I mean that the test case should clearly state its purpose.

12. Your test cases should be reusable.

What do we mean by automated test data generation?

First let us clear up what is meant by Test automation? Test automation can be defined as the use of software system, program or application to carry out the following tasks:

- control the process of execution of tests
- to compare the actual outcomes with the predicted outcomes
- to set up the preconditions for test cases
- to keep test control and
- to implement the function of reporting tests.

WHY TEST AUTOMATION IS USED?
Test automation as the term itself suggests involves automation of a manual testing process which is already in progress.

- It is used for automating manual testing processes which use a formal approach for testing.

- Although manual testing also holds good for finding defects in a software program or application, it is a very laborious and time consuming testing process and also it is not so effective in finding certain kinds of defects.

- To overcome these drawbacks of manual testing, automated Testing is employed.

- It involves a process of writing a computer program or software to carry out testing that would otherwise requires to be done manually.

- Once the tests have been automated, they can be run, easily, quickly and repeatedly.

- All these plus points make the automated testing a very cost effective method for software applications.

- Even minor bugs or discrepancies can cause the program to break or crash over the lifetime of the application.

Two general approaches to test automation have been discovered so far:

- Code driven testing
Elements like classes, public interfaces, libraries and modules are tested under code driven testing with a assorted data arguments in order to validate the results for their correctness.

- Graphical user interface testing
As the name suggests this testing approach creates user interface events such as mouse clicks, key strokes etc. the changes that occur in the user interface are observed and that observable behavior is validated for its correctness.

TOOLS FOR TEST AUTOMATION
Unlike tools required for manual testing, test automation tools are quite expensive, and are usually employed or used in combination with the tools of manual testing.

- Nevertheless, the tools can be cost-effective in the longer term if used repeatedly in regression testing.

WAYS TO GENERATE DATA
Now coming to the automated test data generation, there are several ways for generating data and test cases.

- One of the ways to generate test cases automatically is model- based testing and it generates test cases through use of a model of the system.

- Data is the most important thing needed to execute any test.

- Generating data again and again for repeating tests becomes a time consuming task.

- You need to design the test data again and again to execute your test cases.

- You need to design the test data at the current instant if you are running tests in an exploratory manner.

- Generating test data on your own takes a lot of your valuable time.

- Automated tests need a large amount of distinct test data.

- Another alternative can be copying and pasting data for running tests if the production data is available.

- However, this does not prove to be a very good approach.

- But, nowadays several tools have been developed which can be used for automated test data generation.

So the good thing is that you need not waste your precious time generating test data by hand. These tools help you by creating large quantities of test data based on the conditions and constraints specified by you.

Automated test data generation has got the below mentioned benefits:
- Fast data generation
- Accurate data
- Uses built in algorithms
- Creates both valid and invalid test data
- Data is exportable

What are different aspects of exploratory testing?

First let us discuss a little about what is exploratory testing actually?
It is a term rarely heard of! Exploratory testing is a usual approach to software testing and can be defined as a test designing, test execution and simultaneously a learning process. It was named by Cem Kaner in 1983.

He stated:

"exploratory testing as a kind of software testing that is emphasized and focused up on the responsibility and the personal freedom of the software tester to optimize the quality and effectiveness of his /her work continually by taking in to consideration mutually supportive activities like test designing, test related learning, test result interpretation and test execution".

- These activities run in parallel to each other.

- Exploratory testing basically heeds to exploiting the creativity of the tester or the programmer.

- During the testing of the software, the tester comes across various new things to learn together with experiencing them.

- The tester or the developer with his /her creativity can generate new and better test cases to run.

- Exploratory can be thought of as a black box testing methodology or technique instead of thinking of it as an approach to testing that can be used for any type of testing methodology and also at any phase of development of the software system or application.

According to some misconceptions, the testing technique or the object is considered to be the key here but, it is not so.

- In actual, the key is the cognitive engagement of the software tester and his /her responsibility of managing time.

- The effectiveness of the exploratory testing depends basically on how it is performed.

- Exploratory testing should always be performed by skilled testers or developers.

- Exploratory testing can also be though of as an intellectual activity.

- Exploratory testing is all about discovering how the software system or application actually works and how it handles both the easy and difficult cases.

- The effectiveness or the quality of the testing is largely dependent on the skills for developing test cases by the tester.

- It also depends on his/ her ability to find defects in the software code.

We can say that the quality of the testing is directly proportional to the knowledge of the tester about the software product and different test methods.

- The more he/ she know about the software system under test and testing methodologies, the better will be the exploratory testing.

- While carrying out the exploratory testing, the expectations should be kept open.

- Only some results can be expected or predicted but not all.

- The tester is responsible for configuring, operating, observing and evaluating the product itself and its behavior, investigating the result and reporting information.

- If we see practically the actual testing is a combination of both scripted testing and exploratory testing but, depending on the context of the testing the tendency is towards either one.

Exploratory testing is more about thinking how the testing should be done more than a testing technique. The documentation part of the exploratory testing includes:

- Documentation of all the test cases used.
- Documentation of the bugs.

Exploratory testers use tools like:

- Screen capture
- Video tools

These tools are used to generate situations of interest or as a record of the exploratory session. Bugs are discovered quickly and the approach tends to be more intellectual. Deductive reasoning based on the results of the previous tests can also be used in the exploratory testing. This leads to increased bug detection when used properly. The main disadvantage is that the tests can’t be reviewed before hand.

What are different aspects of exploratory testing?

Exploratory testing is a usual approach to software testing and can be defined as a test designing, test execution and simultaneously learning process.

It was named by Cem Kaner in 1983. "He stated exploratory testing as a kind of software testing that is emphasized and focused up on the responsibility and the personal freedom of the software tester to optimize the quality and effectiveness of his /her work continually by taking in to consideration mutually supportive activities like test designing, test related learning, test result interpretation and test execution".

These activities run in parallel to each other.

- Exploratory testing basically heeds to exploiting the creativity of the tester or the programmer.
- During the testing of the software, the tester comes across various new things to learn together with experiencing them.
- The tester or the developer with his /her creativity can generate new and better test cases to run.
- Exploratory can be thought of as a black box testing methodology or technique instead of thinking of it as an approach to testing that can be used for any type of testing methodology and also at any phase of development of the software system or application.

According to some misconceptions, the testing technique or the object is considered to be the key here but, it is not so.
- In actual, the key is the cognitive engagement of the software tester and his /her responsibility of managing time.
- The effectiveness of the exploratory testing depends basically on how it is performed.
- Exploratory testing should always be performed by skilled testers or developers.
- Exploratory testing can also be thought of as an intellectual activity.
- Exploratory testing is all about discovering how the software system or application actually works and how it handles both the easy and difficult cases.

The effectiveness or the quality of the testing is largely dependent on the skills for developing test cases by the tester.
- It also depends on his/ her ability to find defects in the software code.
- We can say that the quality of the testing is directly proportional to the knowledge of the tester about the software product and different test methods.
- The more he/ she know about the software system under test and testing methodologies, the better will be the exploratory testing.
- While carrying out the exploratory testing, the expectations should be kept open.
- Only some results can be expected or predicted but not all.
- The tester is responsible for configuring, operating, observing and evaluating the product itself and its behavior, investigating the result and reporting information. - If we see practically the actual testing is a combination of both scripted testing and exploratory testing but, depending on the context of the testing the tendency is towards either one.
- Exploratory testing is more about thinking how the testing should be done more than a testing technique.

The documentation part of the exploratory testing includes:

- Documentation of all the test cases used.
- Documentation of the bugs.

Exploratory testers use tools like:
- Screen capture
- Video tools

These tools are used to generate situations of interest or as a record of the exploratory session. For exploratory testing less before hand testing is needed. Bugs are discovered quickly and the approach tends to be more intellectual. Deductive reasoning based on the results of the previous tests can also be used in the exploratory testing. This leads to increased bug detection when used properly. The main disadvantage is that the tests can’t be reviewed before hand.

What are different characteristics of dynamic testing?

Dynamic testing is also known as dynamic analysis. It’s a part of software testing which is basically used to explain the dynamic behavior of a software application or a program. Therefore, dynamic testing can now be defined as the testing the response or reaction (physical in nature) of the system to the dynamic variables ( the variables which keep changing with time and are not constant) that have been used in the program.

As the name suggests, dynamic testing should be carried out dynamically and not like static testing. To carry out a dynamic test for any program, one has to compile the software, run it and work with it. Working with the software involves inputting data values to the variables. It also involves checking the output if whether or not it is up to the expectations of the programmer.

The actual program output is checked against the desired program output. Input and output is checked for validation of the software. Many methodologies like unit tests, system tests, integration tests and acceptance tests have been developed for dynamic testing.

The idea of dynamic testing is typically based on testing the software during execution of the program and also during its compilation.
- Dynamic testing is totally opposite of static testing.
- The software application must be actually compiled and executed and tested as the dynamic testing is a part of validation process, which is again a part of verification and validation process.
- There are many methodologies that can be used for testing a program dynamically. If you are not comfortable with one technique, you can for the other one.

Functional Test Techniques
- These techniques are commonly known as black box techniques.
- These techniques help in designing test cases which are based on the functions of the software application under test and there is no need to consider the details of the software structure.
- These techniques are used to check for input and expected output.

Black box testing techniques:
There are many black box testing techniques available today. Few have listed below:
- Boundary value analysis
- Equivalent partitioning
- State transition testing
- Syntax testing
- Cause-effect graphing

White box testing techniques:
These are also known as structural test techniques. These are used to check the structural design of the software application for flaws and mistakes.There are many white box testing methodologies present today. They can be used effectively for dynamic testing. Following are some of the white box techniques:

- Branch decision testing
- Branch condition testing
- Branch condition combination testing
- LCSAJ testing
- Modified condition decision testing
- Random testing
- Data flow testing
- Statement testing
- Random testing

Here statement testing technique is one of the structural testing techniques and it is used to examine the components of software components decomposed into smaller parts or modules. Statements can be categorized as executable or non executable and they are tested accordingly. But for this technique you need to provide inputs for the software component, some sort of identification for the statements to be executed and you also need to specify he expected outcome for the module or component. Dynamic testing is carried out by domain experts and professionals.

Programming the Dynamic Analysis of Structures

Dynamic Testing: The Nature and Measurement of Learning Potential

How does stress test execute?

A stress test starts with a load test, and then additional activity is gradually increased until something breaks. An alternative type of stress test is a load test with sudden bursts of additional activity. The sudden bursts of activity generate substantial activity as sessions and connections are established, where as a gradual ramp-up in activity pushes various values past fixed system limitations.
Ideally, stress tests should incorporate two runs, one with burst type activity and the other with gradual ramp-up to ensure that the system under test will not fail catastrophically under excessive load. System reliability under severe load should not be negotiable and stress testing will identify reliability issues that arise under severe levels of load.
An alternative, or supplemental stress test is commonly referred to as a spike test, where a single short burst of concurrent activity is applied to a system. Such tests are typical of simulating extreme activity where a count down situation exists. For example, a system that will not take orders for a new product until a particular date and time. If demand is very strong, then many users will be poised to use the system the moment the count down ends, creating a spike of concurrent requests and load.

How to set up a Load Test using LoadRunner?

The important thing to understand in executing such a load test is that the load is generated at a protocol level, by the load generators, that are running scripts that are developed with the VUGen tool. Transaction times derived from the VUGen scripts do not include processing time on the client PC, such as rendering (drawing parts of the screen) or execution of client side scripts such as JavaScript.The WinRunner PC(s) is utilized to measure end user experience response times. Most load tests would not employ a WinRunner PC to measure actual response times from the client perspective but is highly recommended where complex and variable processing is performed on the desktop after data has been delivered to the client.

The LoadRunner controller is capable of displaying real-time graphs of response times as well as other measures such as CPU utilization on each of the components behind the firewall. Internal measures from products such as Oracle, Websphere are also available for monitoring during test execution.
After completion of a test, the analysis engine can generate a number of graphs and correlations to help locate any performance bottlenecks.

In simplified load test, the controller communicates directly to a load generator that can communicate directly to the load balancer. No WinRunner PC is utilized to measure actual user experience. The collection of statistics from various components is simplified as there is no firewall between the controller and the web components being measured.

Exploratory Testing - Introduction and Overview

Exploratory testing is an interactive process of concurrent product exploration, test design and test execution. This testing is defined as simultaneous test design, test execution and bug reporting. In this approach, the tester explores the system without having any prior test cases or test scripts. It is also called as ad hoc testing, gorilla testing or intuitive testing. In operational terms, exploratory testing is an interactive process of concurrent product exploration, test design, and test execution. The outcome of an exploratory testing session is a set of notes about the product, failures found, and a concise record of how the product was tested. When practiced by trained testers, it yields consistently valuable and audit-able results. Every tester performs this type of testing at one point or the other. This testing totally depends on the skill and creativity of the tester. Different testers can explore the system in different ways depending on their skills. Thus, the tester has a very vital role to play in exploratory testing.

A systematic approach of exploratory testing can also be used where there is a plan to attack the system under test. This systematic approach of exploring the system is termed as formalized exploratory testing. It is a powerful approach but it has not got recognition and is often misunderstood and not gained the respect it needs. In many situations, it can be more productive than the scripted testing.
This testing believes in concurrent phases of product exploration, test design and test execution. It is categorized under black box testing. It is basically a free-style testing approach where you do not begin with the usual procedures of elaborate test plans and test steps. The test plan and strategy is very well in the tester's mind. The tester asks the right question and judges the outcome. During this phase, the tester is actually learning the product as he tests it. It is interactive and creative. A conscious plan by the tester gives good results.

Purpose of Volume Testing and what are its features.

Volume testing belongs to the group of non-functional tests. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system.
- Volume testing refers to testing a software application for a certain data volume.
- Volume testing can (and should) be used in component testing.
- Volume testing will also be undertaken (normally) as part of the User Acceptance test.
- Volume testing is used to find faults and give credible information about the state of the component, on which business decisions can be taken.
- Volume testing might take place to confirm that the central core architecture is the one to proceed with.
- Developers across customers & finish users can do. The tests can be outsourced to a testing laboratory that specializes in performance testing.

Examples:
- Online system: Input fast, but not necessarily fastest possible, from different input channels.
- Database system: The database should be very large. Every object occurs with maximum number of instances.
- File exchange: Especially long files. Maximal lengths. Lengths longer than typical
maximum values in communication protocols.
- Disk space: Try to fill disk space everywhere there are disks.

Volume test is interesting if
• The volume test is not executed before.
• Does the system always has the necessary memory resources?
• Can we guarantee this if several systems share the hardware?
• Is it guaranteed that no larger data volumes than specified will occur?
• Is there a low risk if data volume turn greater than specified anyway but the
system does not work well enough then?

What are the four phases of TestDirector ?

TestDirector use can be divided into four phases:
- Test Requirements Management
Requirements Manager is used to link the requirements with the tests to be carried out. Each requirement in the SRS has to be tested at least once. In SRS, the functional and performance requirements are specified. Functional requirements are generated from use-case scenarios. Performance requirements are dependent on the application.
- Test Planning
In test planning, the QA manager does a detailed planning and addresses the following issues:
- Hardware and software platforms.
- Various tests to be formed.
- Time schedule to conduct the tests.
- Roles and responsibility of the persons associated with the project.
- Procedure for running the test.
- Various test cases to be generated.
- Procedure for tracking the progress of testing.
- Documents to be generated during testing process.
- Criteria for completion of testing.
Test design is done during test planning phase which involves defining the sequence of steps to execute a test in manual testing. The test plan is communicated to all the test engineers and also the development team.
- Test Execution
The actual testing is carried out based on the test cases generated, either manually or automatically. In case of automated testing, the test scheduling is done as per plan. A history of all test runs is maintained and audit trail, to trace the history of tests and test runs, is also maintained. Test sets are created. A test set is a set of test cases. In addition execution logic is also set. The logic specifies what to do when a test fails in a series of tests.
- Test Results Analysis
In this phase, test results are analyzed i.e. which tests passed and which failed. For the tests that failed, an analysis is carried out as to why they failed. Bug is classified based on severity. A simple way of classification is critical, major, minor. A more detailed way of classification is:
- Cosmetic or GUI related.
- Inconsistent performance of application.
- Loss of functionality.
- System crash.
- Loss of data.
- Security Violation.
The bug report is stored in a database. The privileges to read, write, and update the database need to be decided by the QA manager. Based on the bug tracking and analysis tools, QA manager and the project manager can take the decision whether the software can be released to the customer or still more testing is required.