C# - Deserializing Json without the type

 Say you receive a json string response to an http call like a GET, POST, etc., and now you like to deserialize it. It is not necessary that the data type class of the response object be declared. This can be useful when doesn't know the response type. This can be achieved by using the System.Text.Json.Node directive like in the below example.

PS - System.Text.Json was introduced in .Net Core 3.0 and above. We do not have to use external libraries for it anymore.

        var jsonResponse = @"{""id"": ""3"", ""type"": ""some text here""}";
               
        var resp_ = System.Text.Json.Nodes.JsonNode.Parse(jsonResponse);
        Console.WriteLine(resp_);
        Console.WriteLine(resp_["id"]);

C# - Deserializing json responses for valid and error cases

 Often times when de serializing a JSON we can get a valid response or an error message depending on various factors, say like resource not found, etc., . In these cases the de serialization should work for both the valid and the error cases. We can accomplish that by inheriting the error class into the ValidResponse class.

System.Text.Json was introduced in .Net Core 3.0 and above. We do not have to use external libraries for it anymore.

PS - To work with JSON in .net 6 (.Net Core 3.0 and above) you would need the below directives
using System;
using System.Text.Json;

If trying to de serialize for an http call, you will also need
using System.Net.Http;

Inheriting the ErrorResponse
public class ValidResponse : ErrorResponse     {
        //public string id { get; set; }
        public string type { get; set; }
    }

ErrorResponse object
public class ErrorResponse    {
        public string id { get; set; }
        public string message { get; set; }
    }

Deserializing the json response after an http call say like GET, POST, etc.,
        var resp = JsonSerializer.Deserialize<ValidResponse>(jsonResponse);
       
        Console.WriteLine(resp.message);
        Console.WriteLine(resp.type);

What to automate - Software Automation

    Everyone in the IT industry these days more or less know what software automation is and what the QA team work on. Software Automation QAs know how to go about automation and even manage them. Before getting into all these, the prior aspect is to identify test cases which need to be automated. In Agile methodology one of the key aspect for a QA resource is to identify which all manual test cases needs to be automated when writing them itself. Some manual test cases can be one off's like say visual ones like the fonts should be italic or the button should be cyan in color. These one off's need not be automated. There can be ones related to the functionality like say the login functionality which can be automated. If doing modular programming for automation this login module or method can be used in conjunction with the other aspects of automation as well like say updating personal details after login to the system.

    Regression test cases are ones which deserve automation almost 100% of the time. These tests include checking the system end to end with different flows like say create an account, add funds to the bank account, add a product and checkout, etc., to name a few. Other test cases which are more important to be automated can include the Smoke/ sanity test cases like check if able to launch or navigate to the app on the browser and perform a simple login.

Software bug practices

    A bug or a defect is an issue identified when trying to test a software or a website. When developing an application, the developed application is not meeting the acceptance criteria of the software requirement(s) a bug can be raised as well.

Fields in the software bug

a. Name - One line(r) to describe what the bug is really about

b. Description or steps -
    First para can have a brief description about what the bug is about.

    The steps to reproduce the bug in sequence. This can be organized into three columns. The first column with the step. The second column with the Actual Result and the last column with the Expected result like in the test cases.

c. Pre - requisites
    Steps to be done before running the actual steps. This can be running other test case(s) as well. If yes then the test id or a html link to them would suffice.

d. Screens
    of the actual issue can be attached to the Actual result column.

Software QA Automation framework/ scaffold/ setup

    When writing automated test cases the first and foremost part is to setup the scaffold or write the framework for writing the test cases. Since now a days we have mostly the websites being built, we will focus on the rough framework for it.

    We will use the Page Object Model or called as the POM model for writing the framework. Let's say the website has ten links for ten different pages on it. We are supposed to have one POM for one page each. These pages can be like Home, Products, ContactUs as a class each and so on.

    Each of these page objects contain the various objects in that page, say like the links, text boxes, buttons, text fields and so on.

    Since the header and the footer menus are a part of almost all the pages in the website, we can declare an abstract Base class which holds these link elements or objects. This Base is then inherited by all the other pages having the header and the footer menus in them.

Drawbacks of POM

    When using POM, one must note that when writing tests, each page object has to be initialized and actions be performed on them. When loading/ initializing each page object to the memory, the memory increases and this could slow the automation run(s). In some cases, one may want to perform only one operation on one page and don't have to load the other objects of that page.

Test support libraries usage

    Say if you are using NUnit which is a very good framework for writing your automated tests in C#. The browser initialization and using part can be done in the base tests file or tests fixture file and say each tests file/ class can have tests for each web page or similar. These page test(s) file can inherit the base test file and use the browser initialized from it.

    Make use of the attributes for tests like the TestCase, Order and all to make the tests report and run better

[TestCase = "Check links on Products page", Order(6)]
public void CheckLinksProductsPage(){}

Advices for better automation

    Keep the framework as loosely coupled as possible. What I mean by this is may be not to modular as well like writing independent methods to perform a task. I know may be one or two tests can use it but if not many then it may not be worth having that function at all. Having a method for a login function taking username and password makes sense as many tests can depend on these. This can help perform or even be easy to write robust tests. Otherwise the framework could be cumbersome to use and to write tests with it.

    Try data driven approach for running one test with many sets of data. Login to a site can be a very good example of this. User can have positive and negative test data and verify the results in the same test and trying to obey the DRY principle(s).

    Data structures used for storing data be light weight for large data sets say like using a simple array object instead of using dictionary or lists or similar which are mutable and these can slow test run(s).

    Avoid running UI tests in parallel as these can step on each other and affect the test run(s).

    

Software QA basics

Software testing can be categorized or organized into different processes or parts depending on the stage at which it is being performed.

Smoke/ Sanity Testing - Usually in the initial/ end stage of product development, when the product is being newly built or about to be launched. Perform a basic test to see if the software is loading/ starting/ launching depending on the software. Simple tests can include testing login or a basic check with most common functionalities are up and working fine.

Functional testing - test the software against the requirements in the product development cycle or in the sprints in the Agile methodology. This includes writing of the manual test cases before the feature/ requirement is ready and running the manual test cases once the feature is ready. If time permits, automated test cases can be added and run instead or both. These test cases can be vetted and organized for regression testing as well.

Regression testing - test cases written/ developed during the functional testing phase are organized and run before the release of the feature/ the whole product itself. This is done usually before the launch of the feature or the product to make sure that subsequent features added to the software has not introduced any bugs or issues.

Priority testing - testing is done when you have large suite of regression tests. Now, say a single feature is developed and the whole regression suite need not be run. A traceability matrix can be prepared mapping each of the testcases to its features. Only the testcases matching to its feature can be run. Ambiguously testcases related to a particular feature can also be run from the regression suite which may depend on the tester's knowledge and experience of the test cases.