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.
Why is Full Stack not Enough?
Usually, full stack testing provides enough confidence on product quality from both the QA and end-user perspective. 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) currently is a bare minimum for modern quality assurance, but this is not at all enough for a great product. Teams should be motivated and they 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. Under 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 crispy 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 QA standpoint. If an application is not testable, then it will have a huge impact on troubleshooting and the testing costs.
Some of which are:
- Time to develop the test strategy: Teams have to find out what is the possible way to do an e2e test with a limited access and validate the data without direct access to the DB etc.
- Testing time: As standard approaches do not work and 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 technical requirement/development process.
Teams could improve efficiency and extend test scenarios in the following way.
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 few sessions will be useful, but it will not provide enough information to understand the project completely.
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 requirements: There should be no bugs in the functionality and end user should be happy.
What Else Needs to be Tested?
When the question arises on what else is there to test? The answer would be some non-functional tests. There is a list of non-functional tests to be carried out. 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, performance testing technique is implemented.
#2) Speed Test
Simplest tests to see how quickly the system responds to the call/command from a user.
#3) Load Tests
This is similar to 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 system a handles load over a long period. Best way to do it is to emulate user activity cycles for few days to see if the system is able to free the resources it was using for 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 the metrics requires its own on 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 to complete the task like very simple Gatling, simple to use but agile SoapUI to universal Jmeter that has lost of components and scripting abilities.
System Performance Test:
#6) Usability
Ideally, workflow, design and UX feature description is provided to the team. In some cases, the team creates it by itself.
QA’s will be the first users who can provide feedback, but it may not be easy to find the right balance. Design and usability are opened to a wide interpretation and may not have the exactly correct answer and it can waste a lot of time.
The ideal solution here is the document with the company color schemes, preferred fonts, and design patterns. Some things are better when left to the qualified professionals.
#7) Industry Standards
In certain cases, there are some expectations from the users.
A typical example will 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. QA specialist should pay attention in not just to the application he tests, but also on 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 in security testing would be to expertise in the 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 advice. Learning new skills, offering improvements and being interested in the future of the project are few initiatives which 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 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 issue, singe security bug or inability to handle peak load may lead the existing clients to lose hope. And this QA approach requires high motivation of each and every team member and may not work on all the teams, but is worth to give a try.
Welcome to QTP Tutorial 