Framework defines the organizationís way of doing things according to their standards. It gives the scope, structure and flow of a project. In automation testing perspective, It is developed inorder to maintain scripting standards which results in team consistency and prevents individuals to follow their own coding standards to avoid the duplicate methods.
For Example: Consider that an application needs to be automated by say 4 people and if the process of automation does not follow any framework then all the 4 people will define their own methods and place those files in their own folders which will raise confusion and no consistency in the team. In the otherway if they follow a process like maintaining a folder for one module and another folder for the other module. All the common actions/methods of different modules should be placed in some other folder with the name that can give exact meaning of common things. This process of managing the flow is nothing but a Framework.
The Framework ITCheers talks about might more often be referred to as the QA/Test Strategy, in other words the governance of how QA operates with defined processes described by structured procedures.
I think what Basamma is referring to is the concept of an automation framework for a test automation tool, potentially making use of developer-type hooks into the application under test, frigging stubs for incomplete modules, defined interfaces from which to read source data, and so forth. That sort of thing is extremely valuable and need to be set up in direct consultation with the developer teams, as well as your process managers. Hope that helps.
IMHO, I would first understand what a 'framework' means and then apply that concept to 'Automation Frameworks'. A framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.
So applying this concept to 'Test Automation' we can say that Test automation framework has to be something which could
- Guide testers to write automated scripts.
- Support the extension/addition of automated scripts.
It implies that when we are writing test automation scripts then we should be able to
- understand how our automated code modules will be interacting with each other(eg by using common libraries, classes etc.).
- understand how the automated scripts will be interacting with application under test(eg. through the UI or interfaces)
- understand how are we going to drive the automated scripts( eg. using Data Driven testing or Key word driven testing).
- understand how the different check results will be reported.
- Understand how the automated scripts will handle changes to the application.
- Any other requirement.
Based on the above points we will be able to come up a 'Framework' which will be
- a well defined approach of interacting with the application using the scripts
- a well defined process of driving the scripts
- abstracted upto sufficient level for easy automation writing.
- Modularised/ refacotred to an extent that there is a set of reusable libraries/components and classes.