An in-depth look at the ins and outs of full-stack engineering
By Cristina Barnutiu, QC Engineer, Cognizant Softvision
You may have already encountered the term Full-Stack in development. Full-Stack is specific to web-based applications and refers to the entire system. Since web applications are built using a layered architecture, Full-Stack development implies making both client-side and server-side parts, meaning from the front-end to the back-end and the connection between them.
The front-end layer (or the UI) is built using HTML, CSS, and scripting languages. Although partial logic and validations are written on the front-end, the application core with the business logic and the data models is coded in the back-end layer (most probably in a different programming language). This layer communicates with the front-end layer via web services and API’s. It also communicates with the persistence layer (or the database) by sending or extracting stored data.
The development roles are usually split into front-end and back-end, but a Full-Stack development approach might be more suitable in other projects. Starting from this model, the question is whether QA engineers should similarly be in charge of Full-Stack testing. Should the QA responsibilities include both UI and back-end, or is it best to separate the tasks?
There is this popular misconception that anyone can be a tester since anyone can navigate through an application, click on buttons and find potential bugs. This is not entirely false but somewhat incomplete since testing also involves testing concepts and methodologies and having a critical way of looking at things. However, I believe the time when testers would just navigate the UI is long gone and that today’s testers should be familiar with the application architecture. Having an in-depth understanding of how things work can improve the test strategy — knowing what, where, and how to test different structures is essential in improving the overall quality. I will try to list just a couple of advantages. Thinking outside the box, anticipating issues, or getting involved in risk mitigation (plus many others) is a massive win for any project that puts testing activities into the upper scale of priorities.
Having access to the database will help the tester see if the front-end data is saved correctly. It can also help the tester choose the correct test data for testing if specific information is needed. Testing can be done from the base layer, and mastering database queries is essential in database testing. For instance, let’s say we need to test that only Active users are displayed on the Users page. We can navigate to the Users page and see a list of users, but this does not provide enough confidence unless we query the Users table in the database and filter the data by status ‘Active’ using a Select query. We can then compare the query results with the items we see on the web page to see if they match.
If we were to talk about API testing, I’m sure we could allocate a whole article, and I don’t want to focus exclusively on that type of testing. Still, I believe it is essential for a tester to inspect a web page to view the sent requests, the responses, or the data transmitted through API calls in json format. It is crucial to verify if the API data matches the database entries and the UI’s data. In this way, we can isolate problems and assign them to the appropriate team for fixing (back-end or front-end).
Some projects (such as the one I am currently working on) follow an incremental approach in building an application from scratch. The back-end and the front-end might be developed by different teams and in extra sprints. In these situations, the QA team’s access to the API documentation can validate part of the early phases’ functionalities, even when the UI is not yet available for that functionality. In our case, we have also established an incremental test strategy that includes UI, back-end (database, API), and integration tests corresponding to each development phase.
So, what type of tests can be done on the back-end? Why isn’t the front-end enough to test the API integration? Since the business logic and the application core are on the back-end, I believe back-end testing is far more specific and able to isolate issues earlier. As a tester, you can verify a json structure to see if the response data contains the required fields, the correct data type, and the correct values. You can also see whether the data is sorted or filtered according to business requirements and so on.
Another good example would be the response codes. We do not need the UI to verify the response codes for specific GET, POST, or PUT requests. Testing, in this case, can be easily performed with tools specific to API and web services testing. Some of these include REST-assured (one of the best tools for API testing but which only supports Java), Postman (which is excellent for both automated and manual tests), and Swagger (a user-friendly tool that can be used for both documenting and testing web services).
The UI remains one of the essential components since this is what the users see and interact with. Testers should continue focusing on the UI and the functionalities, but I see UI as just an iceberg of the whole testing process.
Are there any disadvantages or limitations? Of course. Some claim that being responsible for multiple things might be overwhelming and that division of responsibilities is preferable. I believe testing should include but not limit to the user interface. Unit Testing should remain in the development yard, but extending a tester’s responsibilities to back-end or other areas such as performance or security can be beneficial from an overall perspective. A tester who does “all the QA work” will bring value to any project, especially one that follows an Agile methodology. By digging deeper, testers can help in running the debugging process and not just perform bug reporting.
Strong business knowledge combined with minimal technical skills and the right tools is the prerequisites for an excellent Full-Stack tester. A Full-Stack tester does not know everything but rather someone who understands the mechanisms and can find the best test strategies in an end-to-end test approach to ensure a quality product is delivered.
Get more insights from our engineering and design experts on our website!
