Introduction
Starting QA testing on a completely new application can be overwhelming, especially when you have no prior knowledge of the system. This guide walks through my systematic approach to understanding and testing an unfamiliar application from scratch. Whether you're a junior QA engineer or transitioning to a new project, these steps will help you build a solid foundation for effective testing.
My Experience Context
I've worked as a QA engineer for insurance applications and have used various banking applications as a user. However, when I encountered Parabank (a banking application), I had zero prior knowledge of its specific functionality. This document captures my thinking process and methodology for approaching a project from scratch.
Step 1: Understand the Purpose of the Software
Objective
Get a high-level understanding of what the software does, who uses it, and why it exists.
Why This Matters
Without understanding the purpose, you'll test blindly without context. Understanding the business goals helps you identify what's truly important to test.
Actions to Take
1.1 Gather Available Documentation
- Ask for product documentation, user manuals, or functional specifications (if available)
- Review any existing technical documentation
- Look for API documentation or database schemas
- Check for user stories or requirements documents
1.2 Identify Key Stakeholders
- Primary users - Who uses this software daily?
- Secondary users - Who uses it occasionally?
- Administrators - Who manages the system?
- Business stakeholders - Who benefits from the software?
1.3 Understand Business Context
- What problem does this software solve?
- What are the primary business use cases?
- What are the critical workflows?
- What would cause business impact if broken?
Documentation to Create
- Software overview - High-level description in your own words
- Key stakeholders and contacts - Who to ask questions
- Primary goals and business use cases - Why the software exists
- Data flow diagram - How information moves through the system
Sample Documentation Based on Parabank Exploration
Software Overview
Parabank is an online banking application that allows customers to manage their personal banking needs through a web-based interface. The system provides core banking functionalities including account management, fund transfers, bill payments, transaction history, and loan applications.
Primary Users: Individual banking customers who need to manage their personal finances online.
Core Purpose: Provide secure, convenient access to banking services without visiting a physical branch.
Key Stakeholders and Contacts
- Primary Users: Individual banking customers
- Secondary Users: Banking staff (for support)
- System Administrators: IT team managing the banking platform
- Business Stakeholders: Banking management team
Primary Goals and Business Use Cases
- Account Management: Customers can view and manage their bank accounts
- Fund Transfers: Customers can transfer money between accounts
- Bill Payments: Customers can pay bills through the banking system
- Transaction History: Customers can search and view their transaction history
- Loan Applications: Customers can apply for loans online
- Profile Management: Customers can update their contact information
Pro Tip
Create this documentation in simple terms that you can explain to someone unfamiliar with the system. This becomes valuable onboarding material for future team members.
Step 2: Explore the Software (Exploratory Testing)
Objective
Familiarize yourself with the interface, workflows, and system behavior through hands-on exploration.
Why This Matters
You can't test what you don't understand. Exploratory testing helps you build mental models of how the system works.
Actions to Take
2.1 Get Access and Basic Setup
- Obtain login credentials and access to the system
- Understand the basic navigation structure
- Identify the main entry points (login, registration, etc.)
2.2 Systematic Exploration
- Navigate through each major section of the application
- Try both valid and invalid actions to understand error handling
- Document the user journey step by step
- Note any confusing or unexpected behaviors
2.3 Document Your Findings
- Navigation flows (screen-by-screen progression)
- Basic features and expected behavior
- Any anomalies or bugs (early observations)
- Screenshots with annotations for future reference
Example: My Parabank Exploration
When I explored Parabank, I documented:
- Login Module - Created credentials and accessed the system
- Account Management - Opened new checking accounts from "Open New Account" page
- Account Overview - Checked account details from "Accounts Overview" page
- Bill Pay - Used "Bill Payment Service" page for bill payment
- Fund Transfers - Used "Transfer Funds" page for money transfers
-
Transaction Search - Explored "Find Transactions" with various search criteria:
- Transaction ID search
- Date-based search (MM-DD-YYYY format)
- Date range search
- Amount-based search
- Profile Management - Updated contact information via "Update Contact Info"
- Loan Applications - Applied for loans through "Request Loan" page
- Logout Functionality - Verified proper session termination
Navigation Structure Discovered:
- Sidebar with main sections:
- Account Services
- Open New Account
- Accounts Overview
- Transfer Funds
- Bill Pay
- Find Transactions
- Update Contact Info
- Request Loan
- Log Out
Step 3: Create Comprehensive Documentation
Objective
Build a knowledge base that you and others can reference for effective testing.
Documentation Types to Create
3.1 Feature Inventory / Mind Map
What to document:
- All modules, features, and screens
- What each feature does
- How features relate to each other
- User personas for each feature
Format suggestions:
- Mind map with main features as branches
- Feature matrix with descriptions
- User journey maps
3.2 Test Scenarios (High-Level)
For each feature, document scenarios like:
-
Login Feature:
- Valid credentials login
- Invalid credentials login
- Blank field validation
- Password reset functionality
- Session timeout behavior
-
Account Creation:
- Successful account opening
- Invalid data submission
- Duplicate account prevention
- Required field validation
3.3 Detailed Test Cases
Create step-by-step test cases for critical areas:
- Prerequisites - What needs to be set up first
- Test Steps - Exact actions to perform
- Expected Results - What should happen
- Test Data - What data to use
- Environment - Where to run the test
Step 4: Create a Basic RTM (Requirement Traceability Matrix)
Objective
Since formal requirements may not exist, reverse-engineer them based on observed behavior.
Note
RTM creation is a complex topic that deserves its own dedicated blog post. We'll cover the detailed process of creating and maintaining a comprehensive Requirement Traceability Matrix in a separate article, as it involves specific methodologies, tools, and best practices that go beyond the scope of this introductory guide.
Basic Understanding
For now, understand that an RTM is a living document that:
- Maps requirements to test cases
- Tracks test coverage
- Evolves as your understanding of the system matures
- Helps ensure no critical functionality is left untested
What to Do Now
- Document observed behaviors as you explore the application
- Note any gaps where functionality exists but isn't covered by tests
- Keep track of critical features that need thorough testing
- Prepare for detailed RTM work in the dedicated blog post
Step 5: Check for Tools & Environments
Objective
Understand the technical ecosystem and available resources for testing.
Actions to Take
5.1 Environment Assessment
- Ask about test/staging environments - Is there a separate environment for testing?
- Learn the tech stack - Backend, frontend, APIs, database
- Understand deployment flow - How does code get to production?
5.2 Tool Evaluation
- Version control - How is code managed?
- CI/CD pipelines - How is testing integrated?
- Bug tracking - Where do you report issues?
- Test case management - How do you organize test cases?
5.3 Documentation
- Access URLs and credentials for all environments
- Tooling ecosystem used by the team
- Deployment flow documentation
Note
If you only have access to a public environment (like I did with Parabank), document that limitation and its impact on testing scope.
Step 6: Identify Risk Areas & Create Smoke Tests
Objective
Focus testing efforts on high-risk, high-impact areas first.
Risk Assessment Process
6.1 Identify High-Risk Areas
- Critical business workflows - What would break the business?
- High-usage features - What do users do most often?
- Data-sensitive operations - Money transfers, personal information
- Integration points - Where systems connect
- Known unstable areas - Features with previous issues
6.2 Create Smoke Test Suite
Smoke tests should verify core functionality quickly:
- Login/logout functionality
- Critical user journeys (e.g., account creation, money transfer)
- Basic navigation through main sections
- Essential error handling (invalid inputs, network issues)
Smoke test characteristics:
- Quick to execute (5-15 minutes)
- High-level functionality
- Critical for business operations
- Should run before detailed testing
Step 7: Gradually Build a Test Strategy
Objective
Develop a comprehensive testing approach that evolves with your understanding.
Strategy Components
7.1 Define Test Types
Based on your exploration, decide which test types to apply:
- Functional Testing - Does each feature work as expected?
- Regression Testing - Do new changes break existing functionality?
- Integration Testing - Do different parts work together?
- Performance Testing - Does the system handle expected load?
- Security Testing - Are there vulnerabilities?
- Usability Testing - Is the interface user-friendly?
- Accessibility Testing - Can users with disabilities use it?
7.2 Set Priorities
Prioritize based on:
- Business impact - What would cost the most if broken?
- User frequency - What do users do most often?
- Complexity - What's most likely to have bugs?
- Recent changes - What was recently modified?
7.3 Decide on Manual vs Automation Scope
Consider automation for:
- Repetitive tests - Login, basic navigation
- Regression tests - Features that rarely change
- Data-driven tests - Same logic, different data
- Smoke tests - Quick verification of core functionality
Keep manual for:
- Exploratory testing - Finding unexpected issues
- Usability testing - User experience evaluation
- Complex scenarios - Hard to automate workflows
- One-time tests - Not worth automating
Step 8: Continuous Improvement
Objective
Refine your approach based on findings and feedback.
Improvement Areas
- Update documentation as you learn more
- Refine test cases based on actual behavior
- Adjust priorities based on bug patterns
- Expand test coverage in high-risk areas
- Share knowledge with team members
Conclusion
Approaching a new application for QA testing doesn't have to be overwhelming. By following this systematic approach, you can build a solid foundation of understanding and create effective test strategies. Remember that this is an iterative process - your understanding and testing approach will evolve as you learn more about the system.
The key is to start with exploration, document everything, and gradually build a comprehensive testing strategy that aligns with business goals and user needs.
Key Takeaways
- Start with understanding - Know what the software does before testing it
- Explore systematically - Document your journey through the application
- Create reusable documentation - Help yourself and future team members
- Focus on high-risk areas - Prioritize what matters most
- Build incrementally - Don't try to test everything at once
- Adapt and improve - Refine your approach based on findings
This approach has helped me successfully test applications I knew nothing about, and I hope it helps you do the same!
Top comments (0)