Manual and automated tests coexist in a compatible way inside Test Studio where, as a side effect, the transition between them is smooth. At any point during the lifetime of the test, the test resides on an automation scale beginning with a fully manual test up to a fully automated one. Between the two boundaries, a test is called hybrid. This test is a blend between the two extreme types, and it profits from both of their powerful particularities.

A hybrid test is a manual test made convenient for execution. Its convenience is derived from the fact that it mitigates mechanical repetitive tasks that challenge the tester with time and continuous focus. Let's take an example of a login dialog that appears during an application's start-up. Firstly, this operation is repeated in the same manner for all test cases that make up a test suite designated for execution. Secondly, it is mechanical and can even be performed almost unconsciously by a tester. Thirdly, this step is only a bridge to get to the test core, where the inability to achieve it is sufficient to bring the test execution to an end and assert its failure. As you can see in this context, this operation has no reason for it to be carried out manually. On the contrary, all the arguments mentioned previously call for an automation.

In Test Studio, the feature that makes the preceding flexibility available is called fast forward. This feature allows advance operations, similar to the preceding login example, at any point inside the test. Fast forward is mostly useful in the setup and tear down procedures, which are normally used to put the system in a certain state and restore it back after execution.

In the coming test, we will demonstrate the usage of the fast forward feature to automatically simulate operations at the beginning and at the end of a manual test. Create a test called Func-6_FileInfo_Create_Failing_Hybrid under the Manual Test Scripts folder and add the following manual steps to it:

Steps of the Func-6_FileInfo_Create_Failing_Hybrid manual test

Steps 1 to 4 seem to be recurring for all tests and hence they fit the criteria for an automated setup routine. Consequently, let's apply the fast forward feature to them.

Firstly, we need to enable authorization for the File Comparer application so that a login dialog is launched to ask the user for their login credentials before the main application window is displayed. So open the settings.xml file from the application's Bin folder and edit the authorization tag to <authorization>True</authorization.

Back to the test inside Test Studio, click on the Fast forward test button outlined in the preceding screenshot.

The first step of the Fast Forward Manual Test dialog is to choose whether you want to use the forward feature with a WPF Test or a Web Test as shown in the following screenshot. Click on the WPF Test option:

The Fast forward test button

The second step consists of examining further information about the fast forwarding feature. To finish enabling this feature, click on the Close button.

Notice how the ribbon for the test now holds the automation toolkit seen in the previous chapters. For instance, to continue adding manual test steps, you have to use the same procedures for an automated WPF test and that is by clicking on the More button of the Add tab.

The Application tab is available again, so click on the Record button to capture the steps that we want to fast forward when executing the test manually. As usual, map the application executable by clicking on the Configure button of the Application tab and start recording. The File Comparer application is now started and the Login window is invoked before we could use the remaining application functionalities. Enter the username and password found in the preceding procedure steps and then click on the Login button.

Move the recorded steps to the very beginning of the test and disable their matching manual steps as follows:

The Func-6_FileInfo_Create_Failing_Hybrid test in the hybrid mode

After this test is successfully executed, an entry for the file is added to the database. The next time the test runs, the submission will be rejected since the file cannot be committed to the database due to uniqueness constraint on the filename. Therefore, the created entry should be cleared from the database right after the first execution before the test ends.

Since our test has now become hybrid, we can add scripted steps similar to tests based on the automated WPF template. In the Add tab, click on the Script Test button. Move this method to the last step and then edit its signature and body as follows:

This method is supposed to firstly establish a connection to the database, which the application interacts with, and then delete the created row. The connection to the database is specified in the connection string of the using block. As for the query, it is defined as the first line in a T-SQL statement. The query firstly searches for an entry inside the destination table with a filename identical to that entered in the manual steps and then deletes it.

With that we would have guaranteed that neither the repetitive execution of this manual test will be invalidated as a result of filename duplicity, nor the generation of a new filename value is needed upon each execution instance.

Refactor tests

The setup and tear down procedures for the case we have just covered are operations that are likely to be common to other manual tests. Basically, many test cases will involve application login and database restoration and would therefore need some automated steps to accomplish them on behalf of the tester. So, it would be beneficial to find a way that unifies these operations and save the tester's time and maintenance effort in the long run. In general, if you notice such deficiency in your tests or any room for improvement, it is time to pause and shift your automation efforts towards some refactoring. The refactoring that we are going to apply consists of abstracting the definition of the coded steps inside the test and raising it up to a higher level.

As a start, we will extract the automated steps concerned with the application login. So select the first five steps, then right-click anywhere inside the selection, and choose Create Test as Step from the context menu as shown in the following screenshot:

Exporting steps to a new test

In the invoked dialog, rename the test as 'Op_Login'.

The outcome consists of removing the steps and replacing them with a call to an external test that we called Op_Login. Further on in the project, whenever a manual test calls for login procedures, the manual steps can be replaced by Op_Login, which is now accessible and shareable between other manual tests.

We will apply the same concept to the last scripted step responsible for deleting the created record from the database table. However, first we need to update its definition to comply with its targeted purpose. Currently, the query that gets executed in the database deletes the record having the filename, Incident Report. Since not all testing documents are called incident reports, this query is ought to be generalized. We will update it so that it sorts the table in a descending order based on the date the file was created on to pull the last inserted entry to the first row.

Afterwards, we will delete the top first row that, given the preceding information, corresponds with the lastly created file. Consequently, double-click on the coded method and update its implementation to the following code snippet that caters for the provided preceding description:

string query = "DELETE  fn from (SELECT TOP(1) [File Name], CreatedOn  FROM [dbo].[FileInfo] ORDER BY CreatedOn DESC) fn";

using (SqlConnection hrCon = new SqlConnection("Data Source=localhost;Initial Catalog=FC_DB;Persist Security Info=True;User ID=FC_DB_USER;Password=po0$wt;Connection Timeout=30"))
           {
               hrCon.Open();

               SqlCommand hrCommand = null;
               hrCommand = new SqlCommand(query, hrCon);
               hrCommand.CommandType = System.Data.CommandType.Text;
               SqlDataReader sqlDR =  hrCommand.ExecuteReader();
               sqlDR.Close();
               hrCon.Close();
           }

The query has now become general enough to handle any type of file, so right-click on the coded step and again choose the Create Test as Step option. Rename it as Op_DeleteFileInfo. Open the Op_DeleteFileInfo test, and add the following line to the code behind the using block:

using System.Data.SqlClient;

Lastly, delete the disabled manual steps for the Func-6_FileInfo_Create_Failing_Hybrid test. The resulting test is shown in the following screenshot:

Steps of the Func-6_FileInfo_Create_Failing_Hybrid test

Repository maintenance

With the intention of organizing the test repository inside Test Studio and allowing easy navigation inside it in the future, reorganize your tests as shown in the following screenshot by wrapping the newly created tests in descriptive folder names:

Organizing the test project