Recording Selenium Test Execution

After long time, got few min to think about new blog. There are many blog available for each and every solution but I was thinking to have few which is either not available or very limited information available over internet. I have free version of sauce lab and I am always fascinated by this kind of tool and I would love to build such tool sometime in future. There is one feature that is recording the session is always attracted me. I tried to find some resources which can help me to achieve so in my framework.

I found Microsoft expression encoder to do recording your screen. You can use their dlls to add into your C# based framework to execute and record the session. In you framework you can write a method which starts recording since beginning and later during cleanup task, you can have some login to determine if you want to save recording or not. For example, I my framework, I start recording based on my configuration file and in teardown methods, I check if there is an error or not. if yes then I encode into wmv format else I discard recording.

Follow following steps to have code and settings into framework:

Step 1:

Install Microsoft Encoder Expression: Refer for that ( Once you install, you may get following folder in installation location. C:\Program Files (x86)Microsoft Expression. If you try to explore few folders inside this folder you will find SDK folder @: C:\Program Files (x86)\Microsoft Expression\Encoder 4\SDK, where you can see Microsoft.Expression.Encoder.dlls which you can use in your framework code.

Step 2:

Include dlls given in SDK folders into your framework. You can write a method and call that. I have a key value pair in my framework config file and I can decide if I want to do recording or not.  In your test’s [setup] method, you can call this method which will start recording at the beginning of the test.

using System;



using OpenQA.Selenium;



using Microsoft.Expression.Encoder.ScreenCapture;

using System.Drawing;

using Microsoft.Expression.Encoder.Profiles;

using Microsoft.Expression.Encoder;

namespace FRAMEWORK


    //Call this method in setup method.   
    public static void StartRecordingVideo()


        //Provide setting in config file if you want to do recording or not.
        if (testEInfo.isRecording)


            job = new ScreenCaptureJob();

            job.CaptureRectangle = Screen.PrimaryScreen.Bounds;

            job.ShowFlashingBoundary = true;

            //provide the location where you want to save the recording.
            job.OutputPath = AutomationLogging.newLocationInResultFolder;





Step 3:

Now your test started and in the background your screen recording going on. once you reach to the [teardown] method. you can decide if you want to keep the recording or not. In my case I want to keep recording only if there is test failure so my developers can review else there is no point of having recording if tests are passing. To do so I have following method in above code which I call in code at the very end.

public static void StopRecordingVideo()
            if (testEInfo.isRecording)
                string filename = job.ScreenCaptureFileName;
                if (AutomationLogging.countOfError > 0)
                    MediaItem src = new MediaItem(filename);
                    Job jb = new Job();
                    jb.OutputDirectory = AutomationLogging.newLocationInResultFolder;
                    string output = ((Microsoft.Expression.Encoder.JobBase)(jb)).ActualOutputDirectory;



during encoding, you may notice that encoder is eating little more memory and you system may little slow. Try at your end and let me know if you have any question.

API Testing

API stands for Application Programming Interface. API enables two separate software system to communicate with each other. API contains methods and routines used by the system that other systems call and get the result to consume in the own system.

API testing is totally different from GUI Testing and it focuses on Applications business logic layer.  This testing does not care about the look and feel of the application.

Setup of an API Environment:

Usually, setting up the API Test Environment is not that easy because it doesn’t involve any User Interface.  You need to configure the environment based on the application requirements. You need to study the web-services document provided by developers and then design the setup. Using API code, you should make the specific call to API and consume the output for doing verification or other depended API calls.Output could be status (say OK or Error) or any kind of Data (object id) that to call another API method.

Ideally API should catch and handle the problem instead of just failed. If the input is not correct it will let you know the status with great detail like ‘Incorrect request” etc. In a very easy way, I can say, you send a request message to web services and after processing, web service sends you back a response based on that input. It could be ‘Bad Request’ if the message sent incorrectly and contains response in a specific structure based on the architecture of the web services. This response should contain enough information to understand the output and correct if there is some problem with the request.

To understand the API call, let’s see a basic example;

Consider, API functions, which are for an e-commerce web service cart web services;

AddItemToCart(ItemType item, float price, int count)

Once you look at the method, AddItemToCart, you need to pass an item of type ‘ItemType’, price in ‘float’ and count of items in ‘int’ data type to add items to the cart. The output should capture all output message and you need to parse them and get the desired response.

Approach to API Testing:

For say, if you going to test end to end scenario for a purchasing an item, you would be using few API calls.

  1. AddItemIntoCart()
  2. Checkout(), if Item added to Cart.
  3. MakePayment() if you are able to add the item to checkout step.
Based on output response of each API method you proceed to the Next.

API Test Tools:

There are various free and paid tools available in the market, which are specifically designed to test various API for the database application, mobile apps, desktop apps etc. You can download free tools as an extension or as standalone and access web services via the tool. These tools can emulate all or part of the environment in which the API would typically operate. It is not necessary that the tool can emulate all the API calls you need, but I am sure you will find the tool that can do most as per your need. SOAPUI, POSTMAN, Parasoft soaTest are few tools, which you can try.

Dark side of a Software Development Engineer in Test (SDET)

A lot of people have an opinion that a software development engineer in the test is a more difficult, more responsible, more skilled position than that of an automation QA engineer who is actually just a ‘tester’. It’s because the SDET is almost a software developer: he deeply knows programming languages, design patterns, algorithms. He can create a high-quality, maintainable, and performant code. He creates tools for automated testing, writes his own frameworks – such kind of work is more complicated and, therefore, should be better-paying. That’s why many automation test engineers like to name themselves an SDET, alluding to their high skills and value.

Sure, everything said above is true, if and only if the SDET also has a deep knowledge of software testing methodologies and APPLIES it to his work. Unfortunately, in real life you can see the following situation:

There are two QA teams on a project – manual testers and automation testers (who proudly consider themselves SDETs). The manual team creates a set of test cases and passes them to the auto-team for automation. The automation team develops its own framework, converts the test cases to automated ones, writes test scripts, and runs them.

As you can see, there are two different roles: 1 – the team of highly skilled manual testers who write test cases and are responsible for the product quality, 2 – high skilled developers who convert manual test cases to automated scripts. Obviously, the manual test cases and the programming code will be much qualitative in terms of an architecture and design.

But, there are also some cons:

When the automation team receives manual test cases as an input and produces automated scripts as an output only, it means that the team is not responsible for the product quality. It’s because they cannot be responsible for the product test coverage, test strategy, or test design quality – they do not do this. And it also means that the AUTO-TEAM is the only one in the project who IS NOT RESPONSIBLE FOR THE PRODUCT QUALITY!!! And therefore it is not motivated to give the product of high quality. Their goal is tons of test reports marked ‘passed’.

Simple example. Assume there is a defect found in the production branch.

Customer: why has it happened and who is responsible for that?
Manual QA: I created a fine test case that covers everything you need, including the found defect. Then I passed the test case to the automation team. They converted the test case and ran it.
Automation QA: I covered all the requirements and all are reports are green (all the tests are passed).
Customer: But there is a defect!
Manual QA: If you run my test cases manually, you will catch the defect.
Automation QA: Our tools cannot catch such kind of bugs and It’s not my fault that the manual QA did not foresee that and did not provide a more suitable scenario. All my scripts exactly repeat the test cases, every single step.

To avoid a problem similar to the one described above, the SDET must have and apply his/her knowledge of manual software testing. He must be at the heart of the software development process as the customer’s advocate. In addition, he must be responsible for the product quality. So, any SDET must have a very deep knowledge of manual testing and preferably some working experience in this position. Sure, now he does pure automation and writes the code like a developer but he also must take part in the development of the test strategy, create his own test plans and test cases and be responsible for his part of the work.

If you hear someone calling himself an SDET, whereas this function is limited to the development of testing tools, you should know that this person must have come to the software testing from the development field (or always dreamt to be a developer but lacks qualification) and has an insufficient knowledge of software testing and reluctance to study it.

So, make your own conclusions but note that everything written above is only my personal opinion.