Frontend (FE, UI)

The application that provides a graphical user interface that the end user works with - he clicks, enters the data, submits, reads, etc. As testers we need to know following features and facts in case of frontend in order to we to be able to discover the defect causes in the situations when something does not work. Theoretically we can also find there the bugs despite everything works well :)
Our app is implemented in Vue.js.

• Browser Developer console

  In the chrome browser we can open it by pressing F12. In other browsers the console looks very similar and opening is also by pressing F12 or we can just open it from the browser menu by clicking on the button with the label "Developer console/tools" or something like that.

  • "Network" tab - On the network tab we can watch the FE communication - FE - BE, images and javascript downloading etc. In our case when we test the application and we need to check also the FE integration this tab is crucial.
    We can observe the calls to BE that end in an error state. We can look for the unexpected http status like 4XX, 5XX and others. Usually we expect 2XX statuses. When the call fails then it is highlighted with red color in the console and we can investigate where is the bug. It can be anywhere - on FE, BE or DB, or in the communication itself (internet connection, network issues).
    Http error code and the repsonse are the main information sources to investigate. We can find the answers there.
  • "Console" tab - We can figure out here the FE implementation discrepancies. We can meet here the errors for example like - something "undefined" which means the FE uses uninitialized variables or objects. We can also meet the failed calls to BE which tells us that we should also check the network tab for some calls in red.
  • "Application" tab - we can view into the local storage of the browser or to the session storage. There can be valuable information regarding some stuff you are testing. It can be handy one day.

When something is failing on UI or does not work as expected use mainly first two tabs mentioned above. You will get valuable information from these sections of the browser developer console that helps you to understand the cause of the bug and it helps you to address the bug properly.

Backend / Web service (BE, API)

The system sitting under the FE that provides the data to UI app upon the UI request. It is an application running on the server (in case of our application it is java application) that hasn't any graphical interface but it has an API that UI app is using for getting the data and displaying them on the graphical interface. It receives and sends the data to FE on one side and it sends and receives the data to/from DB or other backends on second side. See the diagram above that represents the architecture and the data flows.
BE API (BE communication interface) can be implemented in two most often ways described below. In both cases the communication between FE and BE runs via HTTP protocol which means that the calls contain always following parts - host/endpoint, http headers (Content-type, Authorization etc.) and the body (containing the application data).
From the tester's perspective it does not matter if the BE API is implemented using REST or SOAP. It is still http communication between FE and BE where can be the discrapencies in data, validations and others.

• REST web service
  • The format of the data sent in the http body is in JSON in most cases.
  • Every operation has own endpoint (ie: POST "http://host.cz/service/v1/customer" - saves the customer).
  • The http operations are used in following way:
    GET - I am querying the data
    POST - I am sending the data, I am sending new object
    PUT - I am updating existing object
    DELETE - I am deleting the data
    In ideal case REST implementation uses the http methods that correspond with the operations with the data (get data, update data, save data, delete data). Of course it depends on the BE implementation and theoretically all the operations could use http POST method but in such case it would not be a correct REST implementation.
  • BE documentation (what methods I can use on the API, what data and what format I have to send, what data types etc.) can be written in swagger, Apiary or also in confluence or in classic document as .doc or .pdf.
    Swagger is used very often and his advantage is that you can call the backend operation directly from there. You can use predefined test data sets etc. and it can be useful for the manual testing of the BE. You can use swagger in this way in our application as well. It is available there after the registration.

HTTP request - REST example
POST https://smartqa-findthebug-app-2pjiue27aq-lm.a.run.app/api/v1/customer HTTP/1.1
Accept-Encoding: gzip,deflate
Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdW
Content-Type: application/json
Content-Length: 358
Host: smartqa-findthebug-app-2pjiue27aq-lm.a.run.app
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/16.0.1)

{
"firstName": "test",
"lastName": "test",
"dateOfBirth": "1991-09-13",
"sex": "MALE",
"email": "test@test.com",
"phoneNumber": "12345",
"primaryAddress": {
"street1": "test 12",
"street2": "test 13",
"city": "test",
"zip": "123456",
"country": "ANDORRA"
},
"mailingAddress": null
}


HTTP response - REST example
HTTP/1.1 201 Created
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers
location: /api/v1/customer/6fe3208b-476f-4b4c-87ce-5ee18ad8cc10
pragma: no-cache
expires: 0
x-frame-options: DENY
content-type: application/json
Content-Length: 342

{"id":"6fe3208b-476f-4b4c-87ce-5ee18ad8cc10",
"firstName":"test",
"lastName":"test",
"email":"test@test.com",
"phoneNumber":"12345",
"dateOfBirth":"1991-09-13",
"sex":"MALE",
"primaryAddress":{"id":"f79267d8-7219-4a43-b031-3a00ae09b0b0",
"street1":"test 12",
"street2":"test 13",
"city":"test",
"zip":"123456",
"country":"ANDORRA"},
"mailingAddress":null}


• SOAP web service

  In case of SOAP there is always used the http method POST for the communication to the API from the client side. In the http request body there is always the data and therefore from this point of view it makes sense that it is using only POST. SOAP web service has one endpoint. The operation that we call is specified in the http message body itself.
  Find the publicly available SOAP service HERE.
  You can try to download and install SoapUI app and to import the WSDL file (link above). SoapUI will generate SOAP project for you and you can call the BE operations simply from there. You can check how the requests and responses look like. You have also possibility to view the raw http request and response which is very helpful.

  • Data is sent and received in the XML format - XML always contains following tags (besides the ones we define for the data exchange in the XML body part) - Envelope, header, body. The XML structure is defined by the SOA protocol.
  • One web service has only one endpoint. Particular operation that we want to call we define in the http request body itself together with the data.
  • SOAP service is described in deepest detail in WSDL (web service description language) document. Everything regarding service, data, operations is decribed there. Therefore you can just take this WSDL xml file and import it to the SoapUI application and SoapUI will create for you the sample requests for all the operations that the service offers. After that you can start to test the service manually from SoapUI.

HTTP request - SOAP example
POST http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
Content-Length: 326
Host: webservices.oorsprong.org
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/16.0.1)

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://www.oorsprong.org/websamples.countryinfo">
<soapenv:Header/>
<soapenv:Body>
<web:CapitalCity>
<web:sCountryISOCode>CZE</web:sCountryISOCode>
</web:CapitalCity>
</soapenv:Body>
</soapenv:Envelope>


HTTP response - SOAP example
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
Web-Service: DataFlex 19.1
Date: Wed, 19 Oct 2022 14:01:29 GMT

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<m:CapitalCityResponse xmlns:m="http://www.oorsprong.org/websamples.countryinfo">
<m:CapitalCityResult>Prague</m:CapitalCityResult>
</m:CapitalCityResponse>
</soap:Body>
</soap:Envelope>


Why the application is divided into FE and BE? Why everything is not implemented together in FE for example? It could be.
FE application could directly access the database or other systems without an extra intermediator. But in that situation there would be an inconvenience during the changes or fixes deployments. You would have to deploy whole FE application despite the fact that you would do the changes that are not related to UI.
The history and experience has shown that it is better to separate the layers of the application in order to be more agile during the changes or fixes implementation across these layers.

Database

In the database the application keeps all the data that we want to keep. Backend provides this data to FE and sends the FE data to DB in case of need. In our application we use the relation SQL database postgres. You can view the data directly in the database in our app. You will get the direct access.