Software testing has been with us all since programming started, but it took years before this has been identified as a separate, full-time task along with the coding part.

Over the years, I have seen this career path evolve — from the use of Excel sheets to tools such as Test Rail, Test Management or Team Foundation Server. Bug reporting went from tapping the developer or sending the issues through pinging them a message or email, to the use of bug tracking tools, and most of all, from manual testing to automated testing.

For this article, I will be giving an overview on what the MSBG QAs are up to in terms of developing and improving a test automation practice.

The current automation practice is being observed within the use of Dynamics CRM. This idea has been quite a thought for the team. It seemed quite unattainable because the usage of CRM varies on the project.

We pushed through despite the worries, and from the wide range of automated tool choices, it was narrowed down with Coded UI and Selenium.

So, how did we end up using Selenium?

One of our Manila QAs has tried creating test cases on both tools. And here’s what she has observed:

  • Selenium’s runtime is faster than Coded UI’s

Coded UI:

 

Selenium:

  • Multitasking is not allowed during a test run in Coded UI; the tool controls the keyboard and cursor.
  • There is no built-in CSS or XPath selector in Coded UI.

The Setup

  1. Visual Studio. Either of the 2015 or 2017 version works well, both on Professional and Enterprise editions. There was an advice that the Community edition would work as fine as the other 2, but we have not tried it yet. This product can be downloaded from the Visual Studio Downloads page.

 

  1. Selenium WebDriver. Download the latest one. It would be much better to have the webdriver for different browsers to make our testing more flexible, and also for the case of cross-browser testing. They can be downloaded at SeleniumHQ.

 

  1. Extensions  Upon installing VS and Selenium, we will be using the following extensions:
    • NUnit
    • SpecRun
    • Selenium.WebDriver
    • Selenium.Support
    • Specflow
    • SpecRun

These extensions can be installed via Visual Studio in Tools > Extensions and Updates.

 

 

This can also be done when we go to the Solution Explorer and right click on the Solution > Manage NuGet Packages for Solution…

 

Page Object Model (POM) Framework

POM is an object design pattern where webpages are represented as classes, and the various elements on the page are defined as variables on the class. This kind of framework makes a test routine implementation readable and easier to maintain and update.

Why POM?

  1. The codes are cleaner and easier to understand.
  2. Codes becomes less and optimized due to the reusable page method.
  3. Methods get more realistic names which can be easily mapped.
  4. The code is more maintainable and easier to debug.

Specflow and Gherkin Language

Specflow is an open source part of the Cucumber family and uses Gherkin language to easily write an understandable test. It integrates with Visual Studio and supports MSTest, NUnit (2 and 3), xUnit2 and MbUnit testing frameworks.

Gherkin Language

According to Wikipedia, Gherkin is the language designed to be non-technical and human readable, and collectively describes use cases relating to a software system; it is also to provide simple documentation of the code under test.

The purpose behind its syntax is to promote Behaviour Driven Development.

In Cucumber’s site, they defined the language as designed to be easy to learn by non-programmers, yet structured enough to allow concise description of examples to illustrate business rules in most real-world domains.

Syntax/keywords

  • Feature – describes a specific function of the software being tested.

  • Scenario / Scenario Outline – consists a certain flow of events or steps in the feature under test

Scenario-vs-Scenario Outline

Scenario keyword is used when there are no placeholders involved; otherwise, Scenario Outline is used.

Scenario Outline also allows us to place a set of data to be tested. When this is used, don’t forget to add Examples keyword and the table-like information for the data to be used.

 

  • Steps — consists of the sequence of actions to be taken and expected results. Uses the syntax keywords Given, When, And, Then, and But.
    • Given – consists of the pre-conditions and initial state of the test such
    • When – defines the action taken
    • And – Logical, and
    • Then – in a manual testing perspective, this is the same as the Expected Results section of the test cases.

Building the whole testing plot

Each line in our feature file can be defined to specifically declare and/or call the methods, codes needed to run the test properly.

When we place our cursor in a line of our feature file and press F12 from our function keys, it will let the user set or view the codes behind the step selected.

 

When a method name is highlighted in the Steps page and F12 is selected, it will let us define and view the codes using the language bind selected with Selenium (in this case, C#).

 

There are more things that we are excited to discover in this journey, and I can hardly wait to share more of it to our community. We are also looking forward to a stable process soon and have this practice implemented across our projects. But for now, this concludes my overview for the test automation practice.

Thank you!

P.S. – Should there be any thoughts that you would like to share us with and contribute to its improvement, please let us know, it will be a pleasure to hear and learn from you.