CodedUI Automation tool

Coded UI is an UI test automation tool provided in Visual Studio 2010. Below are the features:

v   Record and Playback support

v   Generated code can be customized

v   Data parameterization (Data driven approach)

v   Assertions (similar to checkpoints in QTP)

v   Object synchronization (‘Wait’ statements)

v   Execute or run the automated tests

v   No built-in mechanism for handling events like unexpected dialogs

After recording a scenario, the following files will be added to the CodedUI project:

File	Description	Editable ?
CodedUITest1.cs	The default name for the file is CodedUITest1.cs. This is the file in which all the Test Methods are added	Yes
UIMap.uitest	An XML file has all the information about the recording including actions, objects and data.	NO (In future, MS may have editor for this file)
UIMap.Designer.cs	This file contains the code generated by the tool based on the recording in UIMap.uitest file (a.k.a. code behind file).	NO. Any edits to this will be lost
UIMap.cs	The main class generated by the tool is UIMap. This is partial class and is split into ‘UIMap.Designer.cs’  and ‘UIMap.cs’. While UIMap.Designer.cs contains code generated by the tool and should not be edited, the UIMap.cs file is the place where you would place all your customization	YES

The following assemblies are added as reference to the CodedUI project: 

v   Microsoft.VisualStudio.TestTools.UITesting (ApplicationUnderTest, BrowserWindow, Keyboard, Mouse, PlayBack, ControlType, UITestControl, etc.)

v   Microsoft.VisualStudio.TestTools.UnitTesting (Assert, StringAssert, Collection Assert)

v   Scenario to record: Browse google, search for a company and    ensure that company name and it’s URL is present in the first link

v   Microsoft.VisualStudio.TestTools.UITest.Common

v   Microsoft.VisualStudio.TestTools.UITest.Extension

Forums for few Test Automation tools

Tool	Forums
QTP	www.sqaforums.com www.mercuryquicktestprofessional.blogspot.com www.knowledgeinbox.com (by Tarun Lawani) www.msdn.microsoft.com www.advancedqtp.com/forums www.learnqtp.com/forums www.qtp.blogspot.com
Selenium	http://www.sqaforums.com/postlist.php?Cat=0&Board=Selenium http://seleniumhq.org/docs/ (not a forum but guide to Selenium learning) http://groups.google.com/group/selenium-users http://groups.google.com/group/selenium-ruby(Forum for Selenium-Ruby user) http://stackoverflow.com/questions/tagged/testing+selenium
TestCompl-ete	http://www.automatedqa.com/forums (Official forum for TestComplete) http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB43
CodedUI	http://social.msdn.microsoft.com/Forums/en-US/vsautotest/threads http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB58&page=1
Rational Tools	Rational Robot: http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB11 http://tech.groups.yahoo.com/group/RationalUsers/   Rational Functional Tester: http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB47 http://www.ibm.com/developerworks/forums/forum.jspa?forumID=322
Froglogic  Squish	http://www.sqaforums.com/postlist.php?Cat=0&Board=Squish
RIA Test Tool	http://www.riatest.com/forums.html
Eggplant	http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB60 http://www.testplant.com/phpBB2/index.php

Hybrid Test Automation Framework

Hybrid Test Automation

The most commonly implemented framework is a best combination of all the techniques. It combines Keyword Driven, modular, Library and Data Driven frameworks. Hybrid Testing Framework allows data driven scripts to take advantage of the powerful libraries and utilities that usually accompany a keyword driven architecture. The framework utilities can make the data driven scripts more compact and less prone to failure. Tests are fully scripted in a Hybrid Testing Framework thus increasing the automation effort. Hybrid Testing Framework also implements extensive error and unexpected windows handling. It is used for automation of medium to large applications with long shelf life. 

Advantages:

§   Fastest and less costly way to develop the automation scripts due to higher code re- usability

§    Utilizing a modular design, and using files or records to both input and verify data, reduces redundancy and duplication of effort in creating automated test scripts

 

Disadvantages:

§    No reporting mechanism to maintain reports for test results, error logs

§    No separate function libraries for common code and business logic code

Data-Driven Framework 

Data-driven testing is a framework where test input and output values are read from data files (data pools, ODBC sources, CSV files, Excel files, DAO objects, ADO objects etc.) and are loaded into variables in captured or manually coded scripts. In this framework, variables are used for both input values and output verification values. Navigation through the program, reading of the data files, and logging of test status information are all coded in the test script.

This is similar to table-driven testing where test case is contained in the data file and not in the script; the script is just a "driver," or delivery mechanism, for the data. Unlike in table-driven testing, though, the navigation data isn't contained in the table structure, In data-driven testing, only test data is contained in the data files.

                  

Advantages:

§    Data sheets can be designed while application development is still in progress

§    Reduces data redundancy

§    Data input/output and expected results are stored as easily maintainable text records in    database

§    Changes to the Test Scripts do not affect the Test Data

§    Test Cases can be executed with multiple Sets of Data

Disadvantages:

§    Requires database proficiency

§ Maintenance of database is required

Library Framework

Test Library Architecture

The test library architecture framework is very similar to the test script modularity framework and offers the same advantages, but it divides the application-under-test into procedures and functions instead of scripts. This framework requires the creation of library files which has reusable code represented in modules, sections and functions of the application-under-test. These library files are then called directly from the test case script.

           

Advantages:

§     Performance of automation scripts increases due to higher code re-usability

§    Functionality changes can be accommodated easily by updating only the specific "Business Function" script

§   Object recognition changes can be easily accommodated in tools without inbuilt object repository

Disadvantages:

§    Technical expertise is necessary to write Scripts using Test Library Framework

§    More time is needed to plan and prepare test scripts

§    Cannot drive the data from database

Modular Framework

Test Script Modularity

The test script modularity framework requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.

Of all the frameworks, this is the simplest to grasp and master. It's a well-known programming strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test script modularity framework applies this principle of abstraction or encapsulation in order to improve the maintainability and scalability of automated test suites.

Advantages:

§    Fastest way to generate script

§    Modular division of scripts leads to easier maintenance

Disadvantages:

§   Cannot make use of reusable libraries

§   Cannot drive the data from database

Keyword Driven Framework

Keyword-Driven or Table-Driven Testing

Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords which are independent of the test automation tool used to execute them, and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.

There are 2 basis components in Keyword Driven Framework viz. Keyword, Application Map.

What is a Keyword or Action?

Keyword is an Action that can be performed on a GUI Component. Ex. For GUI Component Textbox, some Keywords (Action) would be InputText, VerifyValue, and VerifyProperty and so on. 

What is Application Map or Control?

An Application Map provides Named References for GUI Components. Application Maps are nothing but ‘Object Repository’. 

Example:  The following table represents Keyword driven framework for ‘Calculator’ application. The "Window" column contains the name of the application window where we're performing the mouse action (in this case, they all happen to be in the Calculator window). The "Control" column names the type of control the mouse is clicking. The "Action" column lists the actions taken with the mouse (or by the tester). And the "Arguments" column names a specific control (1, 2, 3, 5, +, -, and so on).

Window	Control	Action	Arguments
Calculator	Menu		View, Standard
Calculator	Pushbutton	Click	1
Calculator	Pushbutton	Click	+
Calculator	Pushbutton	Click	3
Calculator	Pushbutton	Click	=
Calculator		Verify Result	4
Calculator		Clear
Calculator	Pushbutton	Click	6
Calculator	Pushbutton	Click	-
Calculator	Pushbutton	Click	3
Calculator	Pushbutton	Click	=
Calculator	*	Verify Result	3

Advantages:

§    Detail Test Plan can be written in Spreadsheet format containing all input and  verification data.

§    Prior to the Detail Test Plan being written, if "utility" scripts are created by people who are well versed with the automated tool’s and Scripting language, then the tester can use the Automated Test Tool immediately via the "spreadsheet-input" method, without needing to learn the Scripting language.

§    The tester needs to learn only the "Key Words" required, and the specific format to use within the Test Plan. This allows the tester to be productive with the test tool very quickly, and allows more extensive training in the test tool to be scheduled at a more convenient time.

Disadvantages:

§    Development of "customized" (Application-Specific) Functions and Utilities requires proficiency in the tool’s Scripting language.

§    If application requires more than a few "customized" Utilities, the tester has to learn a number of "Key Words" and special formats. This can be time-consuming, and may have an initial impact on Test Plan Development. Once the testers get used to this, however, the time required to produce a test case will be greatly improved.