Maximizing Quality by Going Above and Beyond Full Stack Testing

Here’s how to maximise quality beyond full stack testing:

Quality expectations are increasing day by day and the search for perfection will never come to an end, thereby raising the bar on Product Quality and End-user experience.

An application that just “does the job” is not enough anymore for an average user and even expectations from the professional tools designed for a narrow range of users are growing gradually. Market demand is changing rapidly and QA processes should adapt to it accordingly.

Maximising Quality Beyond Full Stack Testing

Why is Full Stack not Enough

Usually, full-stack testing provides enough confidence in product quality from both the QA and end-user perspectives. However, some aspects of it are not covered. Reasons may be different like not mentioned in the requirements, not obvious or the QA team is just not aware of how to do these tests or what is the acceptance criteria, etc.

Functional testing on all layers (backend/frontend) is currently a bare minimum for modern quality assurance, but this is not at all enough for a great product. Teams should be motivated and must do all they can to deliver the best possible product quality and end-user experience.

In an Agile approach, relatively small teams work on small pieces of functionality in a short sprint. In such cases, tight communication between the team members is possible without destroying the process. This, in turn, could help to share knowledge, have discussions on code improvements, or just will help to ask the right questions to the product owners.

When to Start Testing

The crisp answer to this question will be to start as early as possible. In some cases, thinking about the QA at the ideal stage can point out weak architecture places and may require some information from a QA standpoint. If an application is not testable, then it will have a huge impact on troubleshooting and testing costs.

Some of which are:

• Time to develop a test strategy: Teams have to find out what is the best way to do an e2e test with limited access and validate the data without direct access to the DB etc.
• Testing time: Since the standard approach does not work, the team has to use a workaround.
• Troubleshooting costs: Time to reproduce the defect will grow.

Going Above and Beyond Full Stack Testing

The best bugs are the ones that were caught early even before the implementation. This is considered to be the prime achievement of proactive testing and the right QA team involvement in the creation of the technical requirements/development process.

Teams can improve efficiency and extend test scenarios in the following ways:

Stages where testing can be performed:

Requirements review with the developer & Product owner/field expert: This is the perfect opportunity for the QA team to learn more about the business rules & the value behind a project, and also have a direct discussion with PO about the requirements. Whereas one or a few sessions will be useful, they will not provide enough information to understand the project completely.

The best ways are to do some exploratory testing, dig into the code, and read about the field. Upon completion of the session, one can ask educated questions to clarify some application-specific questions.

Architecture review: This, in turn, will be helpful for both the developers as well as the QA. QA should be aware of architecture, its limitations, bottlenecks, and the various testing approaches. Developers, on the other hand, need to know what test scenarios a QA plans to execute and either extend them or confirm weak points in architecture.

At this stage, the team fully understands the requirements: There should be no bugs in the functionality and the end-user should be happy.

What Else Needs to Be Tested

When the question arises of what else is there to test? The answer would be some non-functional tests. Here is a list of non-functional tests to be carried out. A few of which are briefed below.

Lots of Non-Functional tests:

#1) Performance Test

There are multiple aspects of the system performance that may drive the users crazy. Hence, the performance testing technique is implemented.

#2) Speed Test 

Simplest test to see how quickly the system responds to a call/command from a user.

#3) Load Tests

This is similar to a speed test, but with a different count of clients to see if the system can handle a production-like load.

#4) Stability Tests

This is a type of load test that checks how well the system handles load over a long period. The best way to do it is to emulate user activity cycles for a few days to see if the system is able to free the resources it was using for the peak user activity.

#5) Scalability Test

Architecture-specific tests for clustered applications to see if the system can have a stable flat response time with an increasing load.

Each of these metrics requires its own test strategy. Strategies for these tests are defined based on the load profile and its expected user count.

In some cases, Rise-up – Cool-down tests (load varying over time) are used to see if the system can get to the normal state after increased load (higher than nominal).

There are multiple tools that can help you to complete the task like very simple Gatling, simple to use but agile Soap UI to universal Jmeter that has loss of components and scripting abilities.

System Performance Test:

#6) Usability

Ideally, workflow, design, and UX feature descriptions are provided to the team. In some cases, the team creates it by itself.

QAs will be the first users to provide feedback, but it may not be easy to find the right balance. Design and usability are open to a wide interpretation and may not have the exact correct answer and it can waste a lot of time.

The ideal solution here is a document with the company color schemes, preferred fonts, and design patterns. Some things are better when left to qualified professionals.

#7) Industry Standards

In certain cases, there are some expectations from the users.

A typical example would be the login page. The user has certain expectations and creativity like swapping login and password inputs that will not go well.

Some design elements/styles are also becoming a part of the user expectation and should be kept in mind. A QA specialist should pay attention not just to the application he tests, but also to the overall direction, that the IT world is taking.

#8) Security Testing

The most complex aspect of testing that rarely gets enough attention and requires very high competence in IT and also time is the Security testing technique. There is a limited count of standard tests that can be done on all the other tests that are platform/application-specific.

Data encryption, access limitations, SQL injections are pretty simple tests, but usually, exploits are using different types of bugs. The best way to do security testing would be to have expertise in architecture and reading.

There are many useful articles available on different types of security attacks and how to avoid them, reading which could make the coffee break a more interesting one.

#9) Being Initiative

This is one of the most important pieces of advice. Learning new skills, offering improvements, and being interested in the future of the project are a few initiatives that one can implement. Learning about the technology stack used in a project will help to choose an efficient test strategy that will include only the relevant scenarios and increase the efficiency of testing.

This is what allows us to go “above and beyond” apart from simply completing the tasks from 9 am to 5 pm.

Conclusion

Quality assurance during the earlier stages of a project can be a very cost-effective one. However, going above and beyond can truly raise the bar for product perfection.

Single usability issues, single security bugs, or the inability to handle peak load may lead the existing clients to lose hope. This QA approach requires high motivation from each and every team member and may not work on all the teams, but is worth giving a try.