1. What is a Joint Application Development (JAD) session?
A Joint Application Development (JAD) session is a structured workshop where stakeholders and developers sit down together to define requirements and design solutions. The goal is to compress what usually takes weeks of separate interviews into a few intense, collaborative days.
JAD SESSION
|
+----------------+----------------+
| | |
Business Users Managers Developers
| | |
+----------------+----------------+
|
Requirements
|
Design Solutions
|
Shared AgreementThe format is deliberate. A trained facilitator runs the session. Around the table sit the key stakeholders — business users who know how the work is done today, managers who know the business goals, and developers who know what is technically possible. They work through the requirements together, in real time, resolving conflicts as they arise instead of through a long back-and-forth of documents.
The value of JAD is speed and alignment. Information that would take weeks to gather through one-on-one interviews is gathered in days. Misunderstandings are caught immediately, because the business person is in the same room as the developer when a requirement is discussed. And because everyone participated in the decisions, there is shared buy-in — the users are less likely to reject a design they helped create.
The sessions are not casual brainstorming. They are structured, usually with an agenda, a facilitator, and a documented output. Decisions are recorded, open issues are assigned owners, and a follow-up report confirms what was agreed.
Agenda
|
v
+--------------+
| JAD Session |
+--------------+
|
+----> Discuss Requirements
|
+----> Resolve Conflicts
|
+----> Make Decisions
|
+----> Record Open Issues
|
v
Documented OutputJAD is the right tool when requirements are complex, when different stakeholders disagree and need to talk it out, or when the project simply cannot afford the time a traditional elicitation would take. Its main cost is scheduling — getting everyone in one room — which is why it is used selectively rather than for every project.
2. What are the different types of feasibility studies?
A feasibility study evaluates whether a project is worth doing, and it looks at that question from several angles at once. The classic breakdown is five types, remembered with the acronym TELOS.
FEASIBILITY STUDY
|
+-------------+-------------+
| | |
v v v
Technical Economic Operational
|
+-----------------------------+
|
+-------+-------+
| |
v v
Schedule LegalTechnical feasibility asks whether the project can be built at all. Does the team have the technology, the tools, and the skills? If the project needs a capability the organization does not have and cannot acquire, it fails on technical grounds regardless of how profitable it looks.
Economic feasibility asks whether the project is worth the money. Will the benefits exceed the costs? A project can be technically easy but economically absurd — the most important check for most businesses.
Operational feasibility asks whether the system will actually work in the organization’s daily life. Will the people who have to use it accept it? Will it fit the existing processes? A technically perfect system that the users refuse to touch delivers nothing.
Schedule feasibility asks whether the project can be completed in time. If a regulation takes effect in six months and the system will take a year, the schedule says no, however good the project otherwise looks.
Legal feasibility asks whether the project complies with laws, regulations, and contracts. Data protection rules, industry regulations, and licensing constraints can all kill a project that ignores them.
Consider a company evaluating a new automated billing system. The team checks whether their stack can handle automated billing, whether the system pays for itself within two years, whether the finance team will use it, whether it can ship before the fiscal year end, and whether it complies with tax and data-protection rules.
Automated Billing System
|
+--------------+--------------+
| | |
v v v
Can we build? Is it worth it? Will users use it?
Technical Economic Operational
| | |
+--------------+--------------+
|
Can we ship on time?
|
Schedule
|
Is it legally valid?
|
Legal
|
v
Feasibility ReportA project is viable only if it passes all five. The output is a feasibility report that documents the findings for each dimension and recommends whether to proceed, reshape, or abandon the project.
3. What is requirements traceability?
Requirements traceability is the ability to link every requirement to its origin and to everything that implements and verifies it, in both directions. Each requirement can be followed forward to its design, code, and tests, and backward to the stakeholder or business goal that created it.
Stakeholder / Business Goal
|
v
Requirement
|
v
Design
|
v
Code
|
v
TestsThe links are stored in a traceability matrix — a table with requirements as rows and the related artifacts as columns. For requirement REQ-001 (“user can log in”), the matrix shows the design component that implements it, the code modules that realize it, and the test cases TC-101 and TC-102 that verify it.
+----------+--------+--------+----------------+
| Req ID | Design | Code | Tests |
+----------+--------+--------+----------------+
| REQ-001 | Login | Auth | TC-101, TC-102 |
+----------+--------+--------+----------------+Forward traceability answers “did we build and test this requirement?” Backward traceability answers “why does this code and test exist at all?” A requirement with no test is untested. A test with no requirement is testing something nobody asked for — wasted effort.
FORWARD TRACEABILITY
Requirement -----------------------> Test
| |
v v
Design ---------------------------> Code
BACKWARD TRACEABILITY
Test -------------------------------> Requirement
| |
v v
Code --------------------------------> Business GoalThe value shows up in three situations. Coverage analysis: before release, the matrix proves every requirement was tested, and reveals any requirement with no test. Impact analysis: when a requirement changes, the matrix instantly shows which design, code, and tests are affected, so nothing is missed. Audits and compliance: the matrix is the documented evidence that the project did what it promised.
Without traceability, “is this feature covered by tests?” is an unanswerable question. With it, the answer is a simple lookup. That is why traceability is considered a mark of a mature, disciplined requirements process.
4. What is requirement prioritization?
Requirement prioritization is the process of ranking requirements so the team knows what to build first. It exists because time, budget, and people are limited, and not everything can be built at once.
REQUIREMENTS
|
v
+-------------------+
| Prioritization |
+-------------------+
|
+----------+----------+
| | |
v v v
Business Cost Risk
Value /Effort
\ | /
\ | /
+--------+--------+
|
v
Dependencies
|
v
Final RankingThe ranking is based on a blend of factors: business value, which requirements deliver the most benefit; cost and effort, which requirements are cheapest to build; risk, which requirements are critical or dangerous to get wrong; and dependencies, which requirements must exist before others can work. The team weighs these together to decide what goes first.
The most common technique is the MoSCoW method, which sorts every requirement into four buckets:
MoSCoW
|
+------------+------------+
| | |
v v v
Must Have Should Have Could Have
| | |
+------------+------------+
|
v
Won't Have
This Time- Must have — essential for the product to be viable. Without these, the launch fails. For a shopping site: login, product catalog, checkout.
- Should have — important but not critical. The product ships without them, but they matter. Reports, for example.
- Could have — nice to have if time and budget allow. Dark mode, extra filters.
- Won’t have this time — explicitly out of scope for now, so everyone knows not to expect them.
Prioritization has a second benefit beyond scheduling: it is a communication tool. When stakeholders disagree about what matters, forcing them to sort requirements into priority buckets surfaces the disagreement and starts a conversation about what the product is really for. It also sets honest expectations — the “Won’t have” bucket tells people what is not coming, which is often as valuable as saying what is.
Priorities are not permanent. As the project evolves and the business learns, requirements get re-ranked. The discipline is keeping the ranking visible and explicit rather than letting “everything is urgent” decide the order.
5. What is change request management?
Change request management is the formal process for handling proposed changes to a project — the pipeline through which any new requirement, modification, or removal must pass before it can affect the plan.
Change Requested
|
v
+--------+
| Submit |
+--------+
|
v
+----------+
| Evaluate |
+----------+
|
v
+--------------+
| Approve / |
| Reject |
+--------------+
| |
Approved Rejected
| |
v v
Implement Close
|
v
Track
|
v
DoneThe process has standard steps. Submit: anyone — a stakeholder, a team member — raises a change request describing what changes and why. Evaluate: the team analyzes the impact on scope, cost, schedule, and risk. What does this change require, and what does it put at risk? Approve or reject: a change control board, with the authority to decide, rules on the request based on the evaluation. Implement: approved changes are scheduled into the plan, with the budget and timeline adjusted accordingly. Track: the change’s status is tracked until it is done.
The point of the process is not bureaucracy for its own sake. It is control. Without it, changes arrive informally — a stakeholder mentions an idea in a hallway, a developer “just adds” a small feature — and the project scope grows while the plan stays frozen. That is scope creep, and change request management is the defense against it.
Without Change Control:
Small Change
|
v
Another Change
|
v
More Features
|
v
Scope Grows
|
v
Schedule + Cost Grow
|
v
SCOPE CREEPThe process also forces transparency. Every change is documented, so the history of the project’s scope is knowable. Every change is justified, so random requests get filtered. And every change is evaluated for impact, so the team understands what accepting it really costs before anyone says yes.
Change request management trades a little friction for a lot of safety. The small effort of filling a form and getting approval is nothing compared to the chaos of a project that quietly grew out of control.
6. How should changing requirements be handled during development?
Changing requirements are normal — the question is how to handle them without losing control of the project. The answer is a combination of formal change control and honest communication.
Changing Requirement
|
v
+---------------+
| Write Request |
+---------------+
|
v
+---------------+
| Assess Impact |
+---------------+
|
v
+-----------+
| Decision |
+-----------+
/ \
/ \
Reject Approve
| |
v v
Close Re-plan
|
v
Communicate
|
v
Implement
|
v
Test
|
v
DoneFirst, route every change through the change request process. Whether the request is a tiny tweak or a major pivot, it gets written down and evaluated. This stops changes from entering the project invisibly, which is how scope creep happens.
Second, assess the impact properly. What does the change require in terms of effort, cost, and time? What existing work does it affect or invalidate? What risks does it introduce? A change that looks “small” to the person requesting it can ripple through several modules — the evaluation is what reveals that.
Third, re-plan based on the assessment. If the change is approved, the schedule and budget are updated to reflect it. The change is not squeezed into the existing plan for free; the plan is revised honestly to include it. This is where projects stay realistic instead of silently drifting.
Fourth, communicate the impact. The requester needs to understand the trade — “this feature adds two weeks and changes the release date.” When stakeholders see the real cost of their requests, they often reconsider priorities. Communication also keeps expectations aligned, so nobody is surprised when the date slips.
The alternative to this process is ignoring changes, which produces a product that no longer matches reality, or absorbing every change silently, which produces a project that is always late and over budget. Handling change deliberately — evaluate, decide, re-plan, communicate — keeps the project flexible without losing its footing.
7. What is unit testing?
Unit testing tests the smallest testable pieces of a program — individual functions, methods, or classes — in isolation. The goal is to verify that each piece behaves correctly on its own, before it is combined with anything else.
Program
|
+----------+----------+
| | |
v v v
Function Method Class
| | |
v v v
Unit Test Unit Test Unit Test
| | |
+----------+----------+
|
v
Verified UnitsA unit test works by calling a single function with specific inputs and checking that it returns the expected output. Because the unit is isolated, anything it depends on — a database, a network service, another module — is replaced with a fake, called a mock or stub, so the test exercises only the code under test.
Unit Under Test
|
+------+------+
| |
v v
Input Output
| |
v v
Test Data Expected Result
|
v
Compare
|
+----+----+
| |
Match Mismatch
| |
PASS FAILConsider a function that calculates a discount: calculateDiscount(price, percent). A unit test would call it with a price of 100 and a discount of 10, and assert that the result is 90. Other tests would cover edge cases — a zero discount, a 100 percent discount, a negative price.
Unit testing matters for several reasons. It catches bugs at their source, where they are cheapest to fix. It runs fast — thousands of unit tests run in seconds — so developers can run them constantly, getting feedback within moments of making a change. And it documents behavior: a well-named unit test describes what the function is supposed to do.
The model of testing levels is often drawn as a pyramid, with unit tests at the bottom (many, fast, cheap), integration tests in the middle, and end-to-end tests at the top (few, slow, expensive). The pyramid’s message is that most testing effort should be unit tests, because that is where the best cost-to-value ratio lives.
/\
/ \
/ E2E\
/------\
/Integr. \
/----------\
/ Unit Tests \
/--------------\
/________________\
Many Fast Cheap8. What is integration testing?
Integration testing tests how different components of a system work together. Where unit testing proves that each piece works alone, integration testing proves that the pieces work when connected.
Unit A Unit B
| |
v v
+------+ +------+
| |------------>| |
| A | Data | B |
| |<------------| |
+------+ +------+
| |
+---------+---------+
|
v
Integration TestThe motivation is simple: units that work perfectly in isolation often fail when combined. The interfaces between them might disagree — one module expects a date in one format and another produces it differently. Data might flow incorrectly between layers. Assumptions made in one module might be violated by another. Unit testing cannot see any of this, because it deliberately isolates each piece; integration testing is what exposes it.
Integration testing works by combining real components and testing their interactions. Following the testing pyramid, it sits between the many fast unit tests at the bottom and the few slow end-to-end tests at the top.
There are classic strategies for ordering the integration. Bottom-up tests the lowest-level components first, then adds layers on top. Top-down tests the highest-level components first, using stubs for lower layers. Big Bang connects everything at once and tests the whole assembly together — fastest to set up but hardest to debug when something fails, because the failure could be anywhere.
Bottom-Up:
Application
^
|
Service Layer
^
|
Database Layer
^
|
Lowest Components
^
|
START
Top-Down:
Application
|
v
Service Layer
|
v
Database Layer
|
v
Lowest Components
Big Bang:
Unit A ----\
Unit B -----+----> Connect Everything
Unit C ----/ |
v
Test TogetherConsider a shopping system. The login module and the database layer each pass their unit tests. Integration testing then connects them and verifies that when the login module asks the database for a user record, it actually gets the right data in the right format. That is the interaction neither unit test could check.
Integration testing catches interface bugs, data-flow bugs, and assumptions-mismatch bugs — the class of problems that appear only when components meet.
9. What is system testing?
System testing tests the entire, fully integrated system against its requirements. It is the first level where the whole application is exercised as one complete product, in an environment that resembles production.
Unit Tests
|
v
Integration Tests
|
v
System Testing
|
v
Complete Application
|
v
Requirements VerifiedThe system being tested is not a collection of units or integrated modules — it is the finished application. System tests run the full product, typically end to end, and verify both functional behavior (does the feature do what it should?) and non-functional behavior (is it fast enough, secure enough, reliable enough?).
Consider a shopping site. Unit tests verify the discount function. Integration tests verify the cart talks to the database. System testing runs the whole experience — search, browse, add to cart, check out, receive confirmation — against the actual requirements, to confirm the site as a whole delivers what was specified.
User
|
v
Search
|
v
Browse
|
v
Add to Cart
|
v
Checkout
|
v
Payment
|
v
Confirmation
|
v
Complete User JourneyThe distinction from integration testing matters. Integration testing proves components connect correctly; system testing proves the assembled product meets its requirements. Integration tests might show that the cart and payment modules communicate, but only system testing shows that a user can complete a purchase from start to finish.
System testing is a natural place for both manual and automated testing, and for a strong focus on non-functional qualities — performance, security, usability — that only matter when the whole system runs together.
Its position in the sequence is important. System testing happens before acceptance testing: the team verifies the product against the requirements, and only then do the customers verify it against their needs.
Development
|
v
Unit Testing
|
v
Integration Testing
|
v
System Testing
|
v
Acceptance Testing
|
v
Production10. What is User Acceptance Testing (UAT)?
User Acceptance Testing (UAT) is the final testing stage, where real users verify that the system meets their business needs. It is the last gate before a system goes into production.
Completed System
|
v
+-------------+
| System Test |
+-------------+
|
v
+-------------+
| UAT |
+-------------+
|
Real Users
|
v
Business Scenarios
|
v
+------+------+
| |
Accepted Rejected
| |
v v
Production Fix IssuesUAT is deliberately different from the testing that comes before it. Earlier testing is performed by developers and testers, checking the system against technical requirements. UAT is performed by end users, checking the system against their actual work. They execute their own real scenarios, with their own real data, doing the tasks they will do every day.
The point is that technical correctness is not the same as user satisfaction. A system can pass every system test — every feature works exactly as specified — and still fail the users, because the specification itself did not match how they really work. UAT is where that gap is discovered, while it is still possible to fix it.
UAT usually works in two stages. Alpha acceptance is done by internal users, often the business department that commissioned the system. Beta acceptance is done by a wider group, sometimes including real customers, once the internal users have signed off.
UAT
|
+-------+-------+
| |
v v
Alpha Test Beta Test
| |
v v
Internal Users Wider Users
| |
+-------+-------+
|
v
Final Sign-offThe outcome of UAT is a formal sign-off. When the users confirm the system does what they need, they approve it for production. That approval is the official “yes, this is the product we wanted” — the moment the system becomes acceptable to the people who will actually live with it.
11. What is performance testing?
Performance testing evaluates how a system behaves under a workload — how fast it responds, how much work it gets through, and how efficiently it uses resources. The goal is to verify the system meets its performance requirements before it goes live.
PERFORMANCE TESTING
|
+---------------+---------------+
| | |
v v v
Response Time Throughput Resource Usage
| | |
+---------------+---------------+
|
v
ScalabilityPerformance testing measures a handful of standard metrics. Response time is how long the system takes to answer a request — users experience this directly as “how slow is the site.” Throughput is how much work the system completes per unit of time, usually measured in requests per second. Resource usage is how much CPU, memory, disk, and network the workload consumes. Scalability is how the system behaves as the workload grows.
The testing works by simulating users. Tools generate realistic traffic — hundreds or thousands of virtual users performing the tasks real users would — while the team measures how the system responds. The results are compared against the performance requirements: if the requirement says “the checkout page must respond within two seconds under 1,000 concurrent users,” the test verifies exactly that.
Virtual Users
|
v
+----------------+
| Test Generator |
+----------------+
|
v
+----------------+
| System |
+----------------+
|
+------> Response Time
|
+------> Throughput
|
+------> CPU / Memory
|
+------> ScalabilityPerformance testing matters because slowness is expensive. Users abandon slow sites, and a site that collapses under load loses money at exactly the worst moment. It also finds problems early: a slow database query that is discovered during performance testing costs a fraction of the same discovery after launch.
Performance testing is an umbrella term that covers several specific types — load testing (expected traffic), stress testing (beyond limits), endurance testing (long duration), and spike testing (sudden jumps). They are different tests for different questions, but all share the same goal: know how the system behaves under real conditions before the real users arrive.
Performance Testing
|
+-------------+-------------+
| | |
v v v
Load Stress Endurance
| | |
+-------------+-------------+
|
v
Spike12. What is load testing?
Load testing is a type of performance testing that simulates the expected, normal amount of user traffic and verifies that the system performs well under it. Its question is simple: “does the system handle the load it was designed for?”
Expected User Load
|
v
+-------------------+
| Load Test Tool |
+-------------------+
|
v
+-------------------+
| System |
+-------------------+
|
+----> Response Time
|
+----> Throughput
|
+----> Resource Usage
|
v
Compare With Targets
|
+---+---+
| |
v v
PASS FAILThe test works by generating realistic traffic at the expected level. If a site expects 1,000 concurrent users on a typical day, load testing puts 1,000 simulated users on it — performing the actions real users would perform — and measures response times, throughput, and resource usage. The results are compared against the performance targets. The checkout page must respond in under two seconds; the site must handle 1,000 concurrent users without errors.
Load testing is fundamentally about confirmation rather than discovery. Unlike stress testing, it is not trying to find where the system breaks; it is verifying that the system meets its committed performance under the workload it was built for.
The value is confidence. A system that has passed load testing has evidence it will serve its expected users acceptably. That evidence is essential before launch — it is the difference between “we think it will be fine” and “we tested it at the expected load and it is fine.”
Load testing is also useful for finding subtle problems that appear only under realistic conditions — database contention, connection pool exhaustion, memory growth over time. A single user never sees these; a thousand users do. That is exactly what load testing reveals while there is still time to fix it.
Normal Load
|
v
1000 Users
|
v
System Tested
|
v
Expected Performance?
/ \
YES NO
| |
v v
PASS Investigate13. What is stress testing?
Stress testing is a type of performance testing that pushes a system far beyond its expected limits to discover its breaking point and confirm it fails safely. Where load testing asks “does it work at the expected level?”, stress testing asks “what happens when it is overwhelmed?”
Increasing Load
|
v
+-------------------------+
| |
| System |
| |
+-------------------------+
|
Normal Capacity
|
v
High Capacity
|
v
Breaking Point
|
v
Failure Behavior
|
v
RecoveryThe test works by increasing the load far beyond normal — instead of the expected 1,000 users, it throws 10,000 or 50,000 at the system — and observing what happens as the system is crushed. The goal is to find out where performance collapses, how the system fails, and whether it recovers.
Three things matter in a stress test. The breaking point: at what load does the system stop performing acceptably? Knowing the ceiling tells the team how much headroom they have before trouble. Failure behavior: when the system does fail, does it degrade gracefully or crash catastrophically? A system that slows down gradually, returning errors politely, is far better than one that locks up or corrupts data. Recovery: after being overwhelmed, does the system come back on its own once the load drops, or does it stay down and need manual intervention?
Load
^
| X Breaking Point
| /
| /
| /
| /
| __/
| ___/
|______ __/________________> Time
Normal
LoadStress testing matters because real life overshoots expected load. A flash sale, a viral story, a product launch — any of these can multiply traffic in minutes. The system that has been stress tested knows its limits and is designed to fail safely; the system that has not is discovering its limits live, in front of real users.
The relationship to load testing is complementary. Load testing proves the system is ready for its normal life; stress testing prepares it for the worst day. Both are part of a complete performance-testing program.
Performance Testing
|
+--------+--------+
| |
v v
Load Testing Stress Testing
| |
v v
Normal Load Beyond Limits
| |
v v
Meets Targets? How does it fail?14. What is security testing?
Security testing is the process of identifying vulnerabilities, threats, and risks in an application, so they can be fixed before attackers exploit them. It answers the question “how can someone break this, and what happens if they do?”
SECURITY TESTING
|
+---------------+---------------+
| | |
v v v
Authentication Data Protection Input Validation
| | |
v v v
Authorization Encryption SQL / XSS
| |
+---------------+---------------+
|
v
Session Management
|
v
ConfigurationSecurity testing examines a set of standard attack surfaces. Authentication and authorization — can users access only what they are allowed to? Can an attacker forge a session or escalate privileges? Data protection — is sensitive data encrypted in transit and at rest? Input validation — can an attacker inject malicious input, such as SQL injection or cross-site scripting? Session management — can sessions be hijacked? Configuration — are insecure defaults and exposed debug features left enabled?
The testing takes several forms. Vulnerability scanning runs automated tools that check for known weaknesses. Penetration testing simulates real attacks, with a security expert trying to break in the way an attacker would. Security code review examines the source for dangerous patterns. Each finds a different class of problem, and a thorough program uses all of them.
Security Testing
|
+--------------+--------------+
| | |
v v v
Vulnerability Penetration Code Review
Scanning Testing
| | |
+--------------+--------------+
|
v
Security Weaknesses
|
v
Fix
|
v
RetestThe stakes are high. A security breach can leak customer data, cost millions, and destroy trust — and it can happen to systems that function perfectly in every other way. Security testing is the discipline that catches the flaw before the attacker does.
Security testing is not a one-time event. New code, new features, and new dependencies introduce new risks, so security must be tested continuously, alongside functional testing, throughout the project’s life.
Development
|
v
Security Test
|
v
Fix Issues
|
v
Retest
|
v
Release
|
v
New Code / Features
|
+----------+
|
v
Security Test
Again...Premium Content
Unlock Top 50 Placement Questions - Part 2 and all premium lessons with a subscription.
From ₹199.99/year — See plans