QA·Field Manual
DARK
SE401 · Software Quality Assurance & Testing · Advanced Topics

Testing doesn't stop
at the desktop app.

Everything you learned about testing — functionality, usability, security, performance — still applies. But the web adds browsers, servers, and caches to break in new ways, and mobile adds screens, batteries, and networks that come and go. This is the field manual for testing things that live in a browser tab or in someone's pocket.

6 web testing types
Selenium automation
Native / Web / Hybrid apps
7 mobile testing types
BROWSER ↔ SERVER Client Server MOBILE handheld iOS HYBRID ANDROID
§ 01 — THE FOUNDATIONAL DISTINCTION

Website vs. Web Application

Get this one right first — every testing decision downstream depends on which of the two you're actually looking at.

📖
Memory hook
"A website is a book. A web app is a conversation."
A book (website) reads the same to everyone. A conversation (web app) changes depending on what you say back to it — that's your input driving dynamic output.
Website

A collection of related, static web pages

A collection of related web pages, including multimedia content, typically identified with a common domain name, and published on at least one web server. Notable example: wikipedia.org. So — a website is informational.

Web Application

A client–server program with logic behind it

A client–server computer program which the client (including the user interface and client-side logic) runs in a web browser. Common web applications include webmail, online retail sales, and online auction. So — a web application is interactive.

Website — static pages
Every user sees the same information every time. Flow: user → page 1 → page 2, no branching based on the user.
Web App — dynamic pages
Every user sees different information depending on their input. Flow: user input → the web app processes it → dynamic output tailored to that user.
§ 02 — WHAT IS WEB TESTING

Checked end-to-end, before it ever goes live

Web testing is a software testing practice to test websites or web applications for potential bugs. A web-based system needs to be checked completely from end-to-end before it goes live for end users. It is performed before making the web application alive — by performing web testing, we make sure the site or app is functioning properly and can be accepted by real-time users.

Why is web testing challenging?

interoperability

Web-based systems and applications interoperate with many different:

OS
Operating systems
BR
Browsers
HW
Hardware platforms
CP
Communication protocols
The search for errors across all of these combinations represents a significant challenge — new technologies make web applications rich, but they become more difficult to test.
§ 03 — THE SIX WEB TESTING TYPES

One wheel, six lenses to test a site through

Some or all of the following testing types may be performed depending on the web testing requirements.

🎡
Memory hook
"Fun Users Interact Compatibly, Performing Securely"
Functionality · Usability · Interface · Compatibility · Performance · Security
⚙️

1. Functionality

Links, forms, cookies, HTML/CSS, database — does it do what the spec says?

🧭

2. Usability

Navigation and content — is it easy to understand and learn?

🔌

3. Interface

Do the web, application, and database server layers talk to each other correctly?

🖥️

4. Compatibility

Browsers, operating systems, hardware — does it perform the same everywhere?

5. Performance

Response times, load, stress, and crash recovery under traffic.

🔒

6. Security

Unauthorized access, sessions, SSL/HTTPS — is sensitive data protected?

§ 04 — FUNCTIONALITY TESTING

The biggest of the six, broken into five sub-checks

Testing the features and operational behavior of a web application to ensure they correspond to its specifications.

1.1 Check all the links

links
  • Test the external links from all the pages to a specific domain under test.
  • Test all internal links between web application pages.
  • Test links used to send email to admin or other users from web pages.
  • Test to check if there are any orphan pages — pages with no incoming links.
  • Finally, check for broken links in all the above-mentioned link types.

1.2 Test forms

forms

Forms are part of any website used for receiving information from users and to interact with them. Check:

  • All the validations on each field.
  • Default values of the fields.
  • Wrong inputs to the fields in the forms.

1.3 Test cookies

cookies

Cookies are small files stored on a user's computer, holding data specific to a particular client and website, accessed by the web server or the client.

  • Test by enabling or disabling cookies in a browser.
  • Test if cookies are encrypted before being written to the user's machine.
  • Test if cookies are deleted when they are not needed anymore.

1.4 Test HTML & CSS

markup
  • Checking for syntax errors.
  • Check if the site is crawlable by different search engines.
  • Readable color scheme and fonts.
  • Standards compliance (e.g. W3C and ISO).

1.5 Database testing

database
  • Data validity: test if any errors are shown while executing queries.
  • Data integrity: check for errors while editing, deleting, modifying data.
  • Check response time of queries; confirm queries execute correctly.
  • Check retrieved data is shown accurately in the web application.
Example functionality scenarios straight from the deck: all mandatory fields must be validated; the system must not show an error for optional fields; numeric fields must reject alphabets with a proper error message; a pop-up ("This field is limited to 500 characters") must display at the field's max size; update/delete actions need a confirmation message; input fields must be tested against special characters.
§ 05 — THE OTHER FIVE WEB TESTING TYPES

Usability, Interface, Compatibility, Security, Performance

2. Usability Testing

human ↔ system

The process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction. Basically, system navigation and content are checked in usability testing.

2.1 Navigation

How a user surfs the pages — buttons, boxes, links. Menus/buttons/links to other pages must be easily visible and consistent across all pages. The app should be easy to use and navigate.

2.2 Content

Content should be logical and easy to understand — check for spelling errors. Dark colors annoy users and should be avoided in the site theme. All anchor text links should work; images should be placed properly with proper sizes.

Exam scenarios to remember: tool-tip text on every field · standard button format/size · a home link on every single page · confirmation message for every interaction · scroll bars appear only when required · every field/button reachable by keyboard shortcuts.

3. Interface Testing

three layers

The main layers in a web application are the Web server, the Application server, and the Database server. Interface testing checks that all interactions between these layers execute properly, and that interactions between different pages in the application are also checked.

4. Compatibility Testing

cross-environment

Used to determine if your software is compatible with other elements of a system with which it should operate — e.g. Browsers, Operating Systems, or hardware. The purpose is to evaluate how well the software performs under different browsers, operating systems, hardware, or software.

Scenarios: test in IE, Firefox, Chrome, Safari and Opera; test HTML-version-to-browser compatibility; images/fonts/JS/animated GIFs display correctly across browsers.

5. Security Testing

sensitive data

Vital for web applications that store sensitive customer information like credit cards, IDs, and passwords.

  • Unauthorized access to secure pages should not be permitted.
  • Restricted files should not be downloadable without appropriate access.
  • Sessions are automatically killed after prolonged inactivity.
  • SSL certificates redirect the site to encrypted SSL pages.

6. Performance Testing

under load

Ensures your site works under all loads.

  • Response times at different connection speeds.
  • Load test — behavior under normal and peak loads.
  • Stress test — find the break point beyond normal load at peak time.
  • Test how the site recovers after a crash caused by peak load.
§ 06 — WEBSITE TEST AUTOMATION

Let the machine do the repetitive clicking

Automation testing helps relieve the bulk of tedious and repetitive human tasks. With the right test automation framework or tool, QAs can automate repetitive browser actions like interacting with web elements or filling out long HTML forms — saving time and effort, getting faster and accurate results, increasing software efficiency, and freeing the team to focus on innovation.

Faster feedback

📈

Improved test efficiency

💰

Reduced expenses

♻️

Reusability of test cases

🚀

Faster time to market

Selenium

web only

Selenium is an open-source testing tool for web applications. Any web application can be tested on web browsers with this automation testing tool.

Key limit to remember: Selenium can test only web applications — it is not useful for mobile or desktop applications.
Test scripts written in
JavaPythonC#PHPRubyPerl.Net
Runs on / with
WindowsMacLinuxFirefoxIEChromeSafariOperaJUnit
Setup Selenium: Eclipse IDE (or another IDE) → Selenium Client and language WebDriver bindings → configure Selenium WebDriver with Eclipse.
§ 07 — MOBILE APPLICATIONS

Three ways to build for a phone

A mobile application is a software application developed specifically for use on small, wireless, handheld mobile devices such as smart-phones and tablets — available through distribution platforms like the App Store (iOS) or Google Play Store, on the two main platforms: iOS and Android.

🧩
Memory hook
"Native is fast, Web is easy, Hybrid is both."
Native = platform-specific, fastest, most reliable. Web = a website dressed up for mobile, quick to build, slower. Hybrid = installed like native, but web technology on the inside — the middle ground.
📱

Native Apps

Installed through mobile platform stores (Google Play / App Store). Platform specific. Offers the fastest, most reliable, most responsive experience. Example: App Store, Settings.

🌐

Mobile Web Apps

Server-side apps accessed on mobile via browsers (Chrome, Firefox) over a mobile or Wi-Fi network. Simpler and quicker to develop than native — but slower and less intuitive.

🔀

Hybrid Apps

A combination of native + web app — installed like a native app, but web app on the inside. Run on-device or offline, written with HTML5 and CSS. Example: Netflix.

§ 08 — MOBILE TESTING VS. MOBILE APPLICATION TESTING

The hardware vs. the software running on it

Mobile Testing

Testing the device — the hardware

Testing the mobile device itself: internal processors, internal hardware, screen sizes, resolution, space/memory, camera, radio, Bluetooth, WIFI, etc.

Mobile Application Testing

Testing the apps — the software

Testing the applications (software) that work on mobile devices and their functionality — a process by which application software developed for handheld mobile devices is tested for its functionality, usability and consistency. Can be automated or manual.

Why testing mobile apps matters
Forecast mobile users worldwide climbs steadily, ~6.95B (2020) toward ~7.49B (2025*). Mobile traffic is up 222% in the last 7 years — from 16.2% share of combined worldwide traffic in 2013 to 53.3% in 2019. More users on more devices means more surface area for bugs to hide in.
Challenges in mobile app testing
  • Variety of mobile devices in the market (HTC, iPhone, Samsung, etc.).
  • Diverse mobile operating platforms (iOS, Android).
  • Different network service providers.
  • Different input methods.
  • Hardware compatibility.

Mobile environment test design considerations

4 areas
AreaComment
ConnectivityDevice provisioning, network speed, network latency, network availability in remote areas, service reliability.
Diversity of DevicesNumerous web browsers to test, multiple versions of runtimes for Java or other languages.
Device ConstraintsLimited memory or processor, small screen size, multiple operating systems, multitasking capabilities, data cache sizes.
Input DevicesTouch screens, stylus, mouse, buttons, rollers.
Installation & MaintenanceInstalling and uninstalling, patching, upgrading.
§ 09 — MAJOR TYPES OF MOBILE APP TESTING

Six on the wheel, plus recoverability and the rest

🎯
Memory hook
"Few Locals Perform Security Compatibility Usability"
Functional · Localization · Performance · Security · Compatibility · Usability — the six-spoke wheel from the slides, plus Recoverability and other scenario groups covered separately.

Functional Testing

interactions + transactions

Consists of testing user interactions and testing the transactions. Relevant factors: type of application (banking, gaming, social, business), target audience type (consumer, enterprise, education), distribution channel (Apple App Store, Google Play, direct distribution).

Scenarios to know: mandatory fields work as required and are displayed distinctively from non-mandatory fields · app behaves correctly on start/stop · app minimizes on an incoming call · phone can store/process/receive SMS while the app runs · multitasking works as required · social sharing/posting/navigation works · payment gateways (Visa, Mastercard, PayPal) work · truncation errors stay within an affordable limit · appropriate error messages ("Network error. Please try after some time") on network failure · other apps aren't starved of memory · app resumes at the last operation after a hard reboot or crash · works across 2G/3G/4G/5G · regression testing uncovers new bugs in existing areas after changes.

Performance Testing

load

Ensures the app performs acceptably under certain performance requirements, such as access by a huge number of users or the removal of a key infrastructure part like a database server.

  • Performs correctly under peak, average, minimum user loads.
  • Client-server config gives optimum performance.
  • Identify application/infrastructure bottlenecks.
  • Battery life supports the app under projected load.
  • Performance holds when switching WIFI ↔ 3G/4G/5G.
  • Battery consumption, memory leaks, GPS/camera use stay within guidelines.

Security Testing

data & network

Ensures the application's data and networking security requirements are met as per guidelines.

  • Withstands brute force attacks (automated trial-and-error to guess a username/password/credit-card number).
  • No sensitive content/functionality without proper authentication.
  • Strong password protection; no session expiration gaps.
  • Prevents SQL injection; validates certificates (certificate pinning).
  • Protects against denial-of-service, buffer overflows, malicious client-side and runtime injections.
  • Regular audits for data protection analysis.

Usability Testing

quick & easy

Performed to have a quick and easy-to-use app rather than a slow, feature- heavy but difficult one. Goal: easy-to-use, intuitive, similar to widely-used industry-accepted interfaces.

  • Buttons sized for big fingers, placed consistently, natural/consistent icons.
  • Same-function buttons share the same color.
  • Tap zoom-in/zoom-out enabled; keyboard input minimized appropriately.
  • Undo/back available within an acceptable duration.
  • Contextual menus not overloaded; text short, clear, readable font size.
  • App re-opens in the same state; strings localize when translation is available.

Compatibility Testing

size, OS, hardware

Ensures the app is tested across all devices — since mobile devices differ in size, resolution, screen, version, and hardware — so it works as desired everywhere.

  • UI matches the device's screen size — no partially invisible or inaccessible text/controls.
  • Text is readable for all users.
  • Call/alarm functionality works while the app runs — app minimizes/suspends during a call, resumes after.

Recoverability Testing

crash & interrupt
  • Crash recovery and transaction interruptions.
  • Validate effective app recovery after unexpected interruption/crash.
  • Verify how the app handles a transaction during a power failure (battery dies, sudden manual shutdown).
  • When a connection is suspended, the system re-establishes it to recover data directly affected by that suspension.

Other testing scenarios

install / uninstall / misc
  • Installation testing — app installs in a reasonable amount of time with required criteria.
  • Uninstallation testing — app uninstalls in a reasonable amount of time.
  • Network test cases — network performs under required load and supports all necessary apps during testing.
  • Continued keypad entry survives interrupts and network issues.
  • Charger effect while an app runs in the background.
  • Low battery + high performance demand; battery removed mid-operation.
  • Battery consumption by the app; check for application side effects.
§ 10 — MANUAL OR AUTOMATED MOBILE APP TESTING

Both are widespread — the choice is contextual

Both manual and automated testing can provide good results. The choice should be based on the company's preferences and capabilities. Manual testing will not be entirely replaced by test automation — there are certain situations when manual control is the better option.

Manual TestingAutomated Testing
Advantages Cost-effective in a short-term period · more flexible · better simulation of user actions Cost-effective in the long-term · running process is faster · reused easily · test results easy to share
Disadvantages Difficult to reuse · running process is slow · some cases can't be executed manually Automated tools may have limitations · less efficient at defining user-friendliness or positive customer experience

Universal mobile testing tools

Android + iOS
Universal (Android & iOS)
  • Eggplant — industry-leading test automation and monitoring platform.
  • Ranorex — automated tool for mobile, web, and desktop solutions.
  • Appium — open-source test automation framework for native, hybrid, and web solutions.
  • Kobiton — AI-powered tool for manual and automated testing.
Platform-specific
  • Selendroid — test automation framework for native or hybrid Android apps.
  • iOS Driver — open-source tool for iOS native, hybrid, or mobile web solutions.
§ 11 — CHEAT SHEET

Every testing type, in one scan

DomainTesting TypeWhat it checks
WebFunctionalityLinks, forms, cookies, HTML/CSS, database
UsabilityNavigation + content, easy to understand/learn
InterfaceWeb server ↔ app server ↔ database server interactions
CompatibilityBrowsers, OS, hardware
PerformanceResponse time, load, stress, crash recovery
SecurityUnauthorized access, sessions, SSL/HTTPS
Mobile AppFunctionalUser interactions, transactions, regression
PerformanceLoad, battery, network switching, bottlenecks
SecurityBrute force, SQL injection, cert pinning, DoS
UsabilityButton size/placement, undo, readable text
CompatibilityScreen size, calls/alarms interrupting the app
RecoverabilityCrash, power loss, connection suspension
Install/Uninstall/NetworkReasonable time, required criteria, network load
§ 12 — COMMON MISTAKES

What students actually get wrong on this material

These are the mix-ups that show up on exams — read each pair twice.

Website vs. Web Application

✗ WRONG
Thinking "web application" just means "a big website" or that the two terms are interchangeable.
✓ RIGHT
A website is informational and static (Wikipedia); a web app is interactive and dynamic, with client-side logic responding to user input (webmail, online retail).

Mobile Testing vs. Mobile Application Testing

✗ WRONG
Using the two terms as synonyms, or assuming "mobile testing" covers the app's features.
✓ RIGHT
Mobile Testing = hardware (processors, camera, Bluetooth, WIFI). Mobile Application Testing = software — the app's functionality, usability, consistency.

Selenium's scope

✗ WRONG
"Selenium can automate mobile app testing too, since it automates browser actions."
✓ RIGHT
Selenium tests only web applications in browsers — it is explicitly not useful for mobile or desktop applications. For mobile, you'd reach for Appium, Selendroid, or iOS Driver.

Native vs. Hybrid vs. Mobile Web apps

✗ WRONG
Assuming a hybrid app is "just a native app with some web pages in it," or that mobile web apps get installed from an app store.
✓ RIGHT
Native = platform-specific, installed via store, fastest. Mobile Web = accessed via a browser, no install, slower. Hybrid = installed like a native app but built with web technologies (HTML5/CSS) on the inside.

Load testing vs. Stress testing

✗ WRONG
Treating "load test" and "stress test" as the same activity with different names.
✓ RIGHT
Load testing determines behavior under normal and peak loads. Stress testing pushes beyond normal loads to find the break point — then checks how the system recovers from a resulting crash.

Orphan pages vs. broken links

✗ WRONG
Confusing an "orphan page" (a page nothing links to) with a "broken link" (a link that points nowhere valid).
✓ RIGHT
An orphan page exists but has no incoming links pointing to it. A broken link points to a destination that doesn't resolve. Functionality testing checks for both, separately.

Interface Testing vs. Compatibility Testing

✗ WRONG
Mixing up "interface testing" (sounds like UI) with checking how the app looks on different screens.
✓ RIGHT
Interface testing checks the server-side layers talking to each other — web server ↔ application server ↔ database server. Compatibility testing checks the client-side environment — browsers, OS, hardware.

Recoverability testing as an afterthought

✗ WRONG
Forgetting recoverability testing exists as its own type, and folding it into "performance" or "functional."
✓ RIGHT
Recoverability testing is its own scenario group in the slides: crash recovery, transaction interruption, power failure mid-transaction, and re-establishing suspended connections.
§ 13 — POP QUIZ

Test yourself — click a question to reveal the answer

Q1.A collection of static pages, all users see the same content, published under one domain — is this a website or a web application? Reveal
Website. It's informational and static — every user sees the same information every time (e.g. wikipedia.org).
Q2.True or false: Selenium can be used to automate testing of a native Android app. Reveal
False. Selenium tests only web applications in a browser — it is explicitly not useful for mobile or desktop applications.
Q3.Which of the six web testing types checks that the web server, application server, and database server interact correctly? Reveal
Interface Testing. It focuses on the three server-side layers talking to each other, plus interactions between different pages.
Q4.An app is installed from the Google Play Store but is actually built with HTML5 and CSS on the inside. What type of mobile app is this? Reveal
Hybrid app. Installed like a native app, but web app technology under the hood — Netflix is the example given in the slides.
Q5.Short answer: name the difference between load testing and stress testing. Reveal
Load testing checks behavior under normal and peak loads. Stress testing pushes beyond normal loads to find the site's break point, then checks recovery from a resulting crash.
Q6.An automated process of trial-and-error used to guess a username, password, or credit-card number — what is this attack called, and which mobile testing type checks for it? Reveal
Brute force attack — checked under Security Testing for mobile applications.
Q7.A tester verifies an app resumes at its last operation after a hard reboot, and separately verifies it survives a battery dying mid-transaction. Are these the same testing type? Reveal
Not exactly — "resumes at the last operation after reboot/crash" is listed under Functional Testing scenarios, while "handles a transaction during power failure" and "re-establishes a suspended connection" fall under Recoverability Testing. Both deal with resilience, but they're distinct categories in the slides.
Q8.Name two universal mobile testing tools (work on both Android and iOS) and one platform-specific tool. Reveal
Universal: Eggplant, Ranorex, Appium, or Kobiton (any two). Platform-specific: Selendroid (Android only) or iOS Driver (iOS only).
§ 14 — PRACTICE LAB

Match the scenario to the testing type

Realistic exam-shape questions, built from the deck's own scenario lists — drill these until the mapping is automatic.

1. A QA engineer checks that the "Submit" button is disabled until the "Email" field passes validation, and that a numeric-only field rejects letters with a proper error message.
→ Functionality Testing (specifically, form testing — 1.2)
Why: field validations, default values, and wrong-input handling are exactly what "test forms on all pages" covers.
2. A tester opens the same banking app on Chrome, Firefox, and Safari to confirm the layout and JavaScript behave identically in each.
→ Compatibility Testing
Why: evaluating how well software performs under different browsers is the textbook definition of compatibility testing.
3. A tester simulates 10,000 concurrent users hitting an e-commerce site during a flash sale to find the point at which the server starts failing requests.
→ Performance Testing — specifically, stress testing
Why: pushing beyond normal load to find the break point at peak time is the definition of stress testing, a performance-testing activity.
4. A mobile QA team verifies the app cannot be installed on unauthorized devices, that sessions expire after inactivity, and that no attacker can read stored passwords in plaintext.
→ Security Testing
Why: unauthorized access prevention, session expiration, and encrypted sensitive data are core security-testing scenarios (for both web and mobile).
5. A tester force-closes a shopping app mid-checkout, then relaunches it to confirm the cart and transaction state are still intact.
→ Recoverability Testing
Why: crash recovery and validating effective recovery after an unexpected interruption is exactly what recoverability testing scenarios describe.
6. A team is deciding between Selenium and Appium for a new project that targets both a responsive website and a native Android app.
→ Selenium for the website, Appium for the native Android app
Why: Selenium is web-only by design; Appium is the open-source framework explicitly built for native, hybrid, and web mobile solutions.