How to Approach QA Testing for an Application You Know Nothing About
Building Quality from Scratch: A QA Lead’s Complete Guide to Test Automation with Java & Selenium
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)
(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?
-
Who uses this software daily? Secondary users – Who uses it occasionally?
-
Who uses it occasionally? Administrators – Who manages the system?
-
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
-
High-level description in your own words Key stakeholders and contacts – Who to ask questions
-
Who to ask questions Primary goals and business use cases – Why the software exists
-
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
Individual banking customers Secondary Users: Banking staff (for support)
Banking staff (for support) System Administrators: IT team managing the banking platform
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
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
of the application Try both valid and invalid actions to understand error handling
to understand error handling Document the user journey step by step
step by step Note any confusing or unexpected behaviors
2.3 Document Your Findings
Navigation flows (screen-by-screen progression)
(screen-by-screen progression) Basic features and expected behavior
Any anomalies or bugs (early observations)
(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
-
What needs to be set up first Test Steps – Exact actions to perform
-
Exact actions to perform Expected Results – What should happen
-
What should happen Test Data – What data to use
-
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
as you explore the application Note any gaps where functionality exists but isn’t covered by tests
where functionality exists but isn’t covered by tests Keep track of critical features that need thorough testing
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?
-
Is there a separate environment for testing? Learn the tech stack – Backend, frontend, APIs, database
-
Backend, frontend, APIs, database Understand deployment flow – How does code get to production?
5.2 Tool Evaluation
Version control – How is code managed?
-
How is code managed? CI/CD pipelines – How is testing integrated?
-
How is testing integrated? Bug tracking – Where do you report issues?
-
Where do you report issues? Test case management – How do you organize test cases?
5.3 Documentation
Access URLs and credentials for all environments
for all environments Tooling ecosystem used by the team
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?
-
What would break the business? High-usage features – What do users do most often?
-
What do users do most often? Data-sensitive operations – Money transfers, personal information
-
Money transfers, personal information Integration points – Where systems connect
-
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
functionality Critical user journeys (e.g., account creation, money transfer)
(e.g., account creation, money transfer) Basic navigation through main sections
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?
-
Does each feature work as expected? Regression Testing – Do new changes break existing functionality?
-
Do new changes break existing functionality? Integration Testing – Do different parts work together?
-
Do different parts work together? Performance Testing – Does the system handle expected load?
-
Does the system handle expected load? Security Testing – Are there vulnerabilities?
-
Are there vulnerabilities? Usability Testing – Is the interface user-friendly?
-
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?
-
What would cost the most if broken? User frequency – What do users do most often?
-
What do users do most often? Complexity – What’s most likely to have bugs?
-
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
-
Login, basic navigation Regression tests – Features that rarely change
-
Features that rarely change Data-driven tests – Same logic, different data
-
Same logic, different data Smoke tests – Quick verification of core functionality
Keep manual for:
Exploratory testing – Finding unexpected issues
-
Finding unexpected issues Usability testing – User experience evaluation
-
User experience evaluation Complex scenarios – Hard to automate workflows
-
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
as you learn more Refine test cases based on actual behavior
based on actual behavior Adjust priorities based on bug patterns
based on bug patterns Expand test coverage in high-risk areas
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!
Осваиваем незнакомое приложение: быстрый старт в QA-тестировании
Начало работы с неведомой системой сбивает с толку, но методичный подход переворачивает проблему в преимущество. Разобраться в бизнес-логике и функционале можно, если сосредоточиться на ключевом — для кого и зачем создан продукт. Готовы обнаружить бизнес-суть за каждой кнопкой?
Определить аудиторию и назначение ПО — основа тестовой стратегии
Изучите документацию, наладьте контакт с ключевыми стейкхолдерами и сформируйте чёткое понимание бизнес-потребностей. Этот фундамент поможет выявить критичные функциональные области и риски. Знаете ли вы, как отсутствие базового понимания может обернуться массой багов?
Эксплоративное тестирование — ваш шанс на глубокий анализ
Исследуйте интерфейс, пробуйте как стандартные, так и нестандартные действия, чтобы выявить ошибки. Фиксируйте каждый шаг и аномалию: это ваш навигатор в мире незнакомого кода. Готовы ли вы бросить вызов непредсказуемым сценариям?
Документирование — ключ к адаптации и системности
Создайте подробную карту функций, тест-кейсы и RTM, чтобы ничего не упустить. Такая документация превратит хаос в структурированное знание и поможет каждому члену команды. Не удивительно ли, что даже в самых сложных проектах порядок рождается из хаоса?
Не ждите чуда — внедряйте системный подход уже сегодня!
Реальные баги могут стоить компаниям миллионы — действуйте!