Software Testing and Quality Control

The ASAP Team performs penetration testing during the testing and rollout phase, which involves simulating real-world attacks to identify security weaknesses. Integration and system testing (options A and B) are typically done by the QA/testing team, while unit testing (option D) is done by developers during coding. Penetration testing is specifically focused on security.

The Development Team is responsible for fixing security vulnerabilities found during testing because they own the codebase and have the technical expertise to implement fixes. The ASAP Team identifies vulnerabilities, the Testing Team discovers them, and Project Management oversees the process, but none are responsible for the actual remediation work.

Penetration testing involves simulating real-world attacks on a system to identify security vulnerabilities before malicious actors can exploit them. The ASAP team specializes in security assessments, making penetration testing the most appropriate type of security-focused testing during the rollout phase.

Application security must be integrated throughout every phase of development. Thinking about security only during testing is too late, and focusing only on design or development misses crucial aspects. Security considerations should begin at requirements gathering and continue through deployment and maintenance.

White-box testing involves examining and testing the internal logical structures, code, and design of an application. Black-box testing focuses on inputs and outputs without knowledge of internal code structure. The key difference is access to and understanding of the internal workings.

White-box testing involves analyzing source code and internal logic. Using regular expressions and pattern databases to scan code for suspicious patterns is a static white-box technique, as it requires access to and examination of the underlying source code.

Before conducting any penetration test, obtaining explicit written permission from system owners is not just a best practice - it's a legal and ethical requirement. Unauthorized penetration testing, even for benevolent purposes, is illegal. Monitoring systems (A), creating test plans (D), and identifying weaknesses (C) all come AFTER securing proper authorization. Permission protects both the tester and the organization.

Nonfunctional criteria (or nonfunctional requirements) describe quality attributes and constraints rather than specific behaviors or features. Availability is a classic nonfunctional requirement - it specifies how available the system must be (e.g., 99.9% uptime). Requirements, defect density, failure modes, and specifications are either functional requirements or quality metrics, not nonfunctional criteria themselves.

WinRunner is a functional GUI testing tool, not a performance testing tool. OpenSTA, IBM Rational Performance Tester, JMeter, and LoadRunner are all specifically designed for load and performance testing of systems under stress.

Load testing specifically evaluates system response times and behavior under expected production-level user load. It validates that the system meets performance requirements for normal operations. Stress testing uses beyond-normal loads, while endurance testing focuses on sustained load duration.

Performance testing measures response times, throughput, and other performance characteristics at a specific load level, often starting with low loads to establish baselines. Unlike load testing (which targets production loads) or stress testing (which exceeds normal capacity), performance testing can occur at any load level to understand system behavior.

Stress testing evaluates system behavior under loads beyond normal operational capacity, often reaching breaking points. It identifies failure modes, bottlenecks, and recovery characteristics. Unlike load testing which uses expected production loads, stress testing intentionally pushes beyond to test system limits and failure handling.

Endurance testing, also called stability or soak testing, validates that the system can sustain expected loads continuously over extended periods without performance degradation or resource exhaustion. It identifies memory leaks, connection pool issues, and other problems that only manifest under prolonged operation.

A test scenario describes the sequence of events, conditions, and user flows that occur during a testing session. It documents what happens from start to finish, including user actions, system responses, and validation points. Options A, B, and D describe specific technical mechanisms (rendezvous points, playback, recording) rather than the overall scenario.

Client-side data caching artificially improves performance test results because cached responses avoid server requests entirely. This masks true server capacity and response times. Unlike production where users have diverse cache states, performance tests should reflect worst-case uncached scenarios to accurately measure server capabilities.