Automation Testing approach for Web Based Application

Question

I am automating a website which has multiple modules and involves users of different privileges (say Admin, User Type 1 and User Type 2). I am using Microsoft's Unit Test Tool inbuilt framework with Selenium-C#. I am taking data from Excel sheet for each test case and using Page Object Model for locating all the attributes.

For a general test case, I take data from Excel file and perform field validations(mandatory/optional, text length, data type etc.) My test case pass or fail based on keyword I have provided in my excel data. If TC is positive, and after all operations I am getting desired output(any success message or expected page title), I pass the test case and report using ExtentReports.

I do not have a separate TestBase/Service class for each test. I have just Page Object classes which contain the page factory and unit test classes which contain the test methods. Is this approach correct?

My basic test cases run absolutely fine. The problem comes when a test case depends on the other test case. Say, there's a functionality which gives me a certain output and that output is the requirement for my other separate test case. How do I proceed with this scenario?

Also, can someone validate the above method which I am using for my automation?

P.S: I am new to C# coding.

Answer 1

I do not have a separate TestBase/Service class for each test. I have just Page Object classes which contain the page factory and unit test classes which contain the test methods. Is this approach correct?

Without seeing code, hard to picture exactly what you mean here, but, I feel you should separate your page factory classes from your unit test classes. I put them in separate projects and have the test project reference the page object model project. But, if one project, then I would do something like this: create subfolders in your VS project, one for Pages and one for Tests. The relationship is the Tests reference the pages, but pages do NOT reference tests.

My basic test cases run absolutely fine. The problem comes when a test case depends on the other test case. Say, there's a functionality which gives me a certain output and that output is the requirement for my other separate test case. How do I proceed with this scenario?

There's some red flags here: A purist's view, test cases should never depend on each other. A goal should be each test can stand/run on it's own.

I'm thinking you mean to create reusability. Test Methods are not intended to be "reusable" methods, so likely some simple refactoring and willingness to create stand alone tests will help in this case.

Imagine you have a test case that looks something like this (NOTE the void return type on our test):

[TestMethod]
public void SaveCustomer()
{
    POM.HomePage.Login(user, password);
    POM.HomePage.GoToNewCustomer();
    POM.NewOrderPage.EnterCustomerName(custName);
    POM.NewOrderPage.EnterCustomerAddr(custAddr);
    POM.NewOrderPage.SaveCustomer();
    var custId = POM.SaveConfirmationPage.GetCustomerId(); // customer id generated by system

    Assert.IsTrue(custId.Length == 5);
}

Then we want to create a second test that searches for customer by Id. It is this second test case that may cause us to think, "hmm, I want to get the Customer Id from the first test, and use that in my second test."

[TestMethod]
public void SearchCustomerById()
{
    // Get the customer ID created by first test:  How do I do this?

    // perform customer search
    POM.HomePage.Login(user, password);
    POM.HomePage.GoToSearchCustomer();
    POM.SearchCustomerPage.EnterId(custIdFromSaveCustomerTest);
    /*
    ... rest of test here
    */
}

The test method is a void method, so doesn't return anything (nor should it). One could imagine writing some value to file, that the second test reads. If at all possible, imo, you should avoid this temptation. In our basic example above we could do something like the following to satisfy code reuse:

    [TestMethod]
    public void SaveCustomer()
    {
        var custId = SaveCustomerAndReturnId("Test Save", "Test Address");

        Assert.IsTrue(custId.Length == 5);
    }

    [TestMethod]
    public void SearchCustomerById()
    {
        var custId = SaveCustomerAndReturnId("Test Search", "Test Address");

        // perform customer search
        POM.HomePage.Login(user, password);
        POM.HomePage.GoToSearchCustomer();
        POM.SearchCustomerPage.EnterId(custId);
        /*
        ... rest of test here
        */
    }

    private int SaveCustomerAndReturnId(string custName, string custAddr)
    {
        POM.HomePage.Login(user, password);
        POM.HomePage.GoToNewCustomer();
        POM.NewOrderPage.EnterCustomerName(custName);
        POM.NewOrderPage.EnterCustomerAddr(custAddr);
        POM.NewOrderPage.SaveCustomer();
        var custId = POM.SaveConfirmationPage.GetCustomerId(); // customer id generated by system

        return custId;
    }

In this case, if we run both tests, we create two customers which we might think is not as good as reusing first test's customer, but the advantage is we have stand alone tests, with code reuse.

Answer 2

From the question you posed I assume that you didn't start with a testing framework and are trying to build your own, you have the built in Unit Test Framework but not the all the classes for Clicking buttons with certain text or a certain ID or whatever.

you should start with smaller classes that will extend functionality. like you will want a class that will hold methods that select stuff on the page in different ways.

once you have this class that has all these methods in it, you can build more complex test classes that, let's say, Login to the application. your Login test is a base for other tests because you always need access to the application for any other test that you do after that.

so your next test will pull in that Login Test Class and perform the log in as one of the steps.

your Login Class will be able to create login objects that take username and password parameters so that you can create different login objects for each set of tests.

---

I would create classes for the following items

• Input (Main Class)
  • Text Boxes (class that inherits main class)
  • Radio Buttons
  • Check boxes
  • etc.
• Buttons
• Labels
• Page Level Information
• Tables

you want to be able to say something like var submitButton = Button.GetButtonById(buttonId); and be able to assign to a button object and then be able to submitButton.Click();

you want to learn about the following things in C#

• Methods
• Static Methods
• Classes
• Inheritance
• Object Oriented Programming

anything that you find while looking these things up that you don't know, Google it.

Answer 3

Isolate test data creation/setup from test verification.

In this scenario, I would use the following strategy:

1) Have baseline test data, which is restored (through SQL scripts) before the suite run.

2) Run the automated suite

3) Do any data cleanup as required.

All the tests would be independent to each other and would be having first step as the pre- requisite verification step which will confirm the required data presence(by firing an simple select query).