Continuous Integration for QA

The Agile practice has completely changed the QA approach. Sprint iterations brought new practices to deliver the software quickly and with trusted quality. With the given limited time and dynamically  changing environment challenges the QA. Continuous integration practice  is the blessing in disguise.

Continuous integration enforces a discipline to integrate the tests more frequently and offers the benefits like reduced manual effort of running tests, easier trouble shooting, produces deployable working software at any point of time. It also helps to get the confidence in the software, provides better visibility of software health and transparency.

 

Continuous integration tools are evolved over the time. In the initial days, I remember using Cruise Control. Cruise Control had its own limitations like not able to detect the hanging builds, showing the test status in live. But the next generation tools are evolved with many features incorporated and fulfills all needs of CI users. I personally admired by TeamCity, as it offers great set of features and provides many build runners like command line runners, Junit, NUnit etc. In the recent past Jenkins is gaining momentum due to lot of features for free of use!

The general approach to hook in your tests into continuous integration tool is:

• Create a CI QA project in CI tool.
• Configure the source control in your QA project.
• Configure list of agent machines in the CI pool to run the test.
•  Choose the build runner. For example, if your tests are written in Junit use a Junit build runner. It can be NUnit or CLI runner depends on your need.
•  Create an ANT/MSBuild script and add this as a driver script in your CI QA project.
• Create a run decency or build chain dependency.
• Create publish rules.

TDD Vs BDD

Test Driver Development (TDD) refers to a process by which you develop and test your code. In TDD approach, development process starts from writing the test before coding and run that test along with another tests that fails, because the specified functionality doesn’t exist. Now, write the minimum amount of code that can make the test to pass. After that, restructure or remove duplication in the existing code without changing its behavior.  Repeat this loop over and over until feature completion. It means that we are repeating the process from RED-GREEN-REFACTOR in a cycle.

                                      

Behavior Driven Development (BDD) is the enhancement of TDD, by which you can approach development and testing. Unlike TDD, BDD is more focused on how you test than when you test. In BDD, your tests are focused on behavior rather than implementation. It means that tests have to been written how the customer’s / user’s will use the software or expected experience, for the given input whether they receive the expected result. i.e., if I click on “Login” button on, I expect user should be able to login with valid credentials else should be able to see proper error message. 

                                 

TTS Tips: Explicitly adding element to element repository and understanding it's auto generated meta data

There are mainly two ways to add element to element repository:

1. By recording test step (See my post about this here)

2. By adding element explicitly to element repository

There are two ways to explicitly add element to element repository:

A. From the browser

B. From the recorder

A. From the browser:

To do this, first we have to select "Highlight Element" in the recorder. Once it is done, we should able to highlight the elements in the browser.

Do following steps to add element to element repository,
a. Go to required element and mouse over it then you should able to see list of options.

b. Select Add to Elements, then friendly name pop-up will be populated.

c. Enter friendly name and click on Add Element.

B. From the recorder:

Do following steps to add element to element repository,

a. Go to recorder and search for required element in the DOM.

b. Right click on the DOM and select "Add to Element Repository", then friendly name pop-up will be populated

c. Enter friendly name and click on Add Element.

We can use this added elements to crate record test step(regular test step). As recorded test step is created from element repository element, the element will not be deleted when we delete recorded test step. By adding element explicitly, if any coded step interacted with this element doesn't causes test case failure. These type of elements should explicitly delete by us from element repository. In the auto generated meta data file (.tstest), you can find these type of elements under "IndependentDescriptors".

We can do required updates here, they will reflect on element repository.

The advantage of first approach is, we no need to worry about element repository clean up where as in second approach, we have to spend some time on element repository clean up if required. Anyhow, in both cases, if we delete test case then the elements bounded with that case will be deleted automatically from element repository.