Testing Your MVP
“Making mistakes should
not
be a mistake”
Testing software or an application is incomplete
without a pinch of humour. Do you know why?
Because it is the most exhausting job of all
(Do not tell our team that we said this😜),and
we are trying to keep up the spirits for our
Quality Analysis and Testing team.
Testing software or an application is
incomplete
without a pinch of humour.
Do you know why?
Because it is the most
exhausting job of all
(Do not tell our team that
we said this😜),and
we are trying to keep up the
spirits for our
Quality Analysis and Testing
team.
The development team pushes the MVP to the next level for the quality analysis and testing team to find bugs (improper function of the code), any design discrepancy, and unknown errors raised due to ripple effect.
The testing process is guided by set
procedures and the use of
standard
documents such as test plans, test cases,
and strategies.
Along with natural human talent, i.e., eyes
for finding errors in others’ work, our team
uses automated testing tools and
frameworks to test the applications.
There is more to test between feeding the
input into the system and getting the
output.
Parameters for quality test an MVP
The quality is not in the eyes of the beholder but has to be in the product itself. Here are our top 5 quality parameters for testing an MVP:
Functionality
Intended input must produce the expected output.
Design
Must be implemented as per the documentation.
Scalability
The design and functionality of the application must support the scaling requirement of the business.
Optimized
The code and use of APIs must be optimized to have a cleaner, efficient, and easy-to-understand environment for all future developments.
Reliability
The MVP must also behave failure- free in a customer-oriented environment, rather than just saying, “It was working just fine on your development systems.”
Security
Integrity features must be paid special attention to check any security loopholes in the MVP that may lead to the misuse of the system.
The parameters mentioned above show that the testing provides 360-degree coverage and caters to every aspect of the MVP that might go wrong.
As already mentioned, the testing process has to follow set protocols and standard procedures, such as
- Building testing strategies
- Making test plans
- Writing test cases and running them in the testing environment.
- Quality check for stability in a client’s work environment.
Before beginning with the processes mentioned above, the team has one more thing to do – referring to the SRS document.
The Omnipresent SRS (Software Requirements Specification)
Remember SRS – the bible of application
development. It has to be revisited by Quality
Analysts to match the
requirements with what
the developer has submitted for testing. The
team must refer to the functional design
requirements from the SRS to understand the
system’s expectations and design testing
scenarios.
The test scenarios are typically the one-liners that specify “what to test” for specific functionality. On a broader scale, the review of SRS leads to the following:
- Understanding all the functional processes of the MVP and knowing what is to be tested.
- Dividing the testing tasks among the team members.
- Knowing any pre-requisites needed before testing.
- Clarity upon the functions of the system, if any.
The SRS review is done in the presence of business analysts and developers to ensure that the quality analysis team is referring to the correct version of the SRS document.
The quality analysis team is left alone with these specifications to carry out further testing tasks, which begins with preparing the strategies for the testing.
What kind of strategies are needed here?
Let’s explore
DevOps Approach
Many development teams now use a methodology known as continuous testing. It is part of a DevOps approach – where development and operations collaborate over the entire product life cycle. The aim is to accelerate software delivery while balancing cost, quality and risk. With this testing technique, teams don’t need to wait for the software to be built before testing starts. They can run tests much earlier in the cycle to discover defects sooner, when they are easier to fix.
Application testing strategies for the MVP
As an organization, Anuyat believes in defined work protocols and best practices to make the functioning go smooth. Preparing the test strategy is a part of this culture.
The Project Manager prepares Anuyat wide test strategy to define the application testing techniques that need to be followed while analyzing the system's quality. It lists the testing objective and the process for achieving that objective in a “Test Strategy Template”.
Parameters to Strategize
Objective & scope
Though the SRS document already mentions the main expectations of the application, it still needs to be restated in the strategy document.
Platform
Desktop
Must consider analyzing the User Interface (UI), business logic, databases, reports, data flow, overall performance, hardware & software integration, security aspects, integrity & usability of each function, and roles & rights.
Web
Along with functional testing, the focus is majorly shifted to the application's performance, load, and online security.
For customer experience, cross-browser testing, multilanguage support, stress testing, and Beta testing are also a part of the web application testing process.
Mobile
The primary concern for testing a mobile app is mobile screen compatibility. Hence, UI testing must be rigorous. It is combined with regression, functional, and security testing.
Approach & Testing
There are multiple questions being answered while strategizing on this parameter. What is the test process, how is defect management handled, what will happen if the team receives a change request, what are the activities while executing a test case, what will be used as test management & automation tools, and so on?
Test Environments
Test environments are nothing but a setup of technological tools to test the application. The strategy is formulated to decide how many different testing environments are needed. At Anuyat, we maintain four testing environments, namely
- Dev environment
- QA environment for tester and quality analysis
- Client's Replica for User Acceptance testing
- Live environment to check how things look at customer's end
For each environment, the strategy must define the access rights, setup configuration & system requirements, test data, and data backup & restoration techniques.
Release, review & approve
Keeping track of the release version of the application is more important than you might think. In the absence of this information, there will be incidents of wrong application releases being available in different test environments, and one can imagine the chaos.
The release management must define where the team can find the latest application build, where it should be deployed, and where the team will find the build for the production environment.
This plan document also includes information about who is responsible for “go” and “no-go” approvals for the release on the production environment.
Need for a test plan for an
MVP
While the test strategy is done at the organizational level, test plans are more specific to the application’s requirements. But they are tightly coupled together as the latter is the extension of the former in terms of project specifications, using the pre-defined strategies.
A good test plan has the following
components:
Scope
Defines the features to be or not-to-be tested and all the dependencies.
Objectives
Specify the reason for the testing – is it a validation of bug fixes or because new features are added, or there is a revamp of the application.
Focus
Outlines the aspect of testing as in whether the security, functionality or usability, reliability, performance, or efficiency is tested.
Testing Techniques
Are well-defined methods and are used to explore
the distinct aspects of the application.
- Smoke testing: This is a basic and the first test to ensure there are no crashes in the application, and hence, it is suitable for further testing.
- Sanity testing: After the successful Smoke test, a Sanity test is done to verify if a specific module is working correctly and is suitable for complete testing.
- Regression testing: Finally, the Regression test verifies the bug fixes and/or updates and checks for any malfunctioning in the other areas of the application due to fixes and changes.
- Security testing: A parallel test made to identify the security weaknesses and vulnerabilities in source code.
Schedule
for who, when, where, how is added in the test plan to provide more specific timelines to the team.
Until here, a solid foundation is laid for the testing team. Now they are all-powerful to
proceed with the writing test cases for each specific module and function of the
application that needs to be executed.
In simple words, “Time for the real action.”
Write Test Cases
Test cases are real actionable information that touches the application at the unit level of its functions.
Test cases have deep-rooted and wide scope; they can include anything from explaining the use of a variable to checking the successful message display after a checkout process.
Programmers
VS
Testers
Since designing test cases is an elaborative process, the best way to cover all the aspects of the
application is to divide the test cases based on their purpose.
This is what the categorization will look like:
| Type of Test Case | Details | Step | Expected result | Status |
|---|---|---|---|---|
| Functionality | The phone number field must accept 10 digits |
Input more than 10 | Must produce an error message |
Pass or Fail |
| Security | The OTP must be sent on the registered number to allow user login |
Check if the sent OTP leads to user account page |
Correct OTP must open user account’s dashboard, other an error message must be displayed |
Login successful or failed |
| Usability | Check if all the links on the screens are working |
Click the links on the screen |
All links must redirect to the designated URLs |
Pass or fail |
| User Interface | The progress bar must appear after user pushes the “Submit” button |
Enter correct details and click the “Submit” button |
Progress should appear while the user waits for the information to get submitted |
Pass or fail |
All the test cases are executed in the test environment, using test management and product management tool - Jira. It is an automated tool that has automated capabilities to find defects, raise environmental issues and provide a collaboration platform for all the team members.
Anuyat’s focus on building secure MVPs
MVP security is multifaceted in nature, taking care of things at features level as well as, server-side.
- Data Encryption – to provide a secure flow of critical data on the network.
- Safe production environment – reliable server space, well-guarded with authentication and log services.
- Authentication – at the application level, to control unauthorized access.
- Firewalls, Web Application Firewalls (WAF), and Intrusion Prevention Systems (IPS)
- Secure application code – built on licensed development platforms.
- Secure APIs – which are fully functional and bug-free.
- Reliable AWS instance - to provide uninterrupted and fail-proof cloud services.
- Secure Sockets Layer (SSL certificates) - for safe browser communication through the applications.
Towards the bugs
Resolution and Reporting
Towards the bugs
Resolution and Reporting
With the help of team collaborating and automation tools, there is a back & forth exchange of the bugs reporting and resolution statuses. The quality analyst must agree on closing the issue or bug after it has been resubmitted for testing by the developers. The project is moved to the production environment after the first round of testing, only after the developer, testers, and client approve the build.
A stable build of the application is gradually available for delivery after a few internal testing phases in the development environment. And the QA team has just one more thing to do- create a Test Closure Report (TCR).
A Test Closure Report
A formal document prepared by the testing team to
provide the summary of all the tests conducted during
the different testing phases, detailed analysis of all the
bugs reported and their statuses, test cases that were
executed, along with the number & density of bugs found.
Engineers at Work
Sonali Salunkhe
Quality Manager
Prachi Sarade
Quality Analyst
Vivek Gaikwad
Quality Analyst
We recommend you use our mvp.wiki platform to estimate the scope and the cost
associated with it. It is a self-estimation MVP platform, with simple interfaces and fewer
steps.
CONTACT US
You can reach out to us on
Offerings
Help
Case Studies
Useful Links
Anuyat © . Powered by www.anuyat.com