Testing the Pallas app inside E-Werk’s concrete bunker

At a temporary festival, the mobile app is not detached from the experience: it guides arrivals, stores tickets, publishes stage times and delivers urgent changes. Inside E-Werk’s heavy concrete, those functions are harder to deliver than on an open street. Testing the festival’s mobile app to ensure it works in the building’s concrete bunker is therefore part of crowd safety, access and service quality, not simply pre-launch software assurance.

The programme should reproduce the journey from download to departure, including crowded thresholds, temporary network coverage and hurried transitions between rooms. It must also account for international visitors. A timetable shown in Berlin time, a mobile wallet familiar in Sydney or Melbourne, and plain-English permission messages all affect whether people can move through the site without confusion.

Defining the journeys that matter

Begin with user journeys instead of screens. The core set should cover ticket purchase and transfer, venue entry, stage schedules, artist details, wayfinding, accessibility information and urgent notices. Add journeys for a first-time visitor, a returning attendee, someone on a low-bandwidth connection and a guest who has not enabled location services. Each journey receives a business goal and failure condition, such as “a visitor reaches the correct stage in under two minutes” or “a ticket remains available without a network connection.”

Onboarding is tested on a clean device, not only on a developer account with cached data. Participants scan the entry code, add the ticket to a wallet, accept or decline notifications and change an important preference. The process should explain why location or Bluetooth is requested rather than treating permission as a gateway. Offline content should preserve the ticket, essential maps and the latest schedule, with a visible timestamp so nobody mistakes old information for a live update.

The team sets pass criteria before the visit. Measures include median and worst-case load times, successful scans, push-delivery rates, battery drain over an event-length session and wrong turns in navigation tasks. Criteria must prioritise critical paths: a failed artist lookup is inconvenient, while an inaccessible entry route or stale safety notice is release-blocking. These thresholds become the shared basis for bug reports, retesting and final sign-off.

Preparing devices and connectivity

The device matrix reflects the audience rather than the development team’s favourites. It should cover current Android and iOS releases, preceding operating-system versions and several screen sizes. Android remains substantial in the Australian smartphone market, so older handsets and manufacturer-specific battery controls need to be represented alongside recent iPhones. Testers use different locales, font sizes, languages and accessibility settings, because an interface validated on one handset can still break on another.

Network conditions are documented inside every relevant E-Werk space. Testers compare the temporary Wi-Fi with mobile data, note dead zones and observe whether walls or floors cause abrupt loss of service. The app should load cached content immediately, communicate that live data may be delayed and recover without losing a user’s place. A staged load test can then add hundreds of simulated sessions, while scanners and ticket endpoints are exercised as queues build at the entrance.

Battery behaviour is tested over several hours, including screen-off periods and repeated switching between Wi-Fi and cellular service. People commonly check a phone while walking, queueing or moving between transport and a venue, so the app must not consume power in the background or keep location active after its task. Push notifications are checked for timing, grouping and failure recovery, while deep links are opened from locked, foreground and background states to ensure they land on the intended screen.

Walking the bunker with participants

Recruit a mixed group including frequent attendees, first-time visitors, wheelchair users and people comfortable with technology alongside those who are not. Australian participants add an overseas perspective, particularly around mobile payments and public-transport planning. A Sydney or Melbourne resident may recognise transit systems such as Opal and myki, yet still navigate a German venue where signs, staff instructions and stage naming work differently. The test is about transferability, not making Berlin resemble an Australian city.

During the walk-through, each participant completes assigned tasks without a developer explaining the interface. They find an entrance, locate a stage, save an artist and recover after a connection drop. Observers record hesitation, backtracking and spoken instructions because someone who silently guesses may still reveal a weak sign-to-screen relationship. GPS coordinates are compared with physical signage; inaccurate pins inside a dense structure are dangerous, so the app needs a room-and-level description when positioning is uncertain.

Accessibility checks continue with the app used at different text sizes and with screen readers enabled. Controls need clear labels, logical focus order, visible focus and enough contrast against dark backgrounds. Testers also check legibility in immersive lighting and dim corridors. WCAG 2.2 AA supplies testable criteria for contrast, focus and screen-reader behaviour, even though the app is used in Berlin.

Stress testing live event conditions

The app is exercised under event-shaped pressure rather than normal traffic. A timed session covers ticket scans at the main door, a schedule update, several artist pages opening at once and a push alert sent to a large opted-in group. The team records latency, error rates and recovery time while people move through narrow circulation areas. These observations are compared with concerts, raves and nighttime club events programmed by Berlin labels and crews across Pallas’s multiple stages, since testing before doors open does not prove performance at peak density.

Notifications carry more risk than ordinary content. A message about a delayed set, altered entrance or change in travel arrangements must reach the right person quickly without becoming noise. The test includes revoked permissions, duplicate alerts, delayed devices and recipients who have left. Fallback messages should point to official on-site information when delivery fails. Information about CO2-neutral operations, travel guidance and accessibility details should remain readable during congestion instead of disappearing behind a network-dependent animation.

Links to companion material receive the same treatment. A visitor tapping through to the festival NFT exhibition should return to the app without losing their place, and the destination should fail gracefully if unavailable. QR codes for entrances and schedules need contrast, sufficient print size and short fallback text. Each link is tested over weak mobile data, within the browser back stack and after the operating system has cleared temporary memory.

Meeting privacy and Australian expectations

The app may collect more than a ticket: location history, notification choices, device identifiers and usage events can reveal where a person went and what they did. For Australian users covered by the Privacy Act 1988, its Australian Privacy Principles require transparent collection, purpose limitation, security and accessible processes for correcting inaccurate data. Berlin operations may also engage the EU General Data Protection Regulation, so retention and consent rules should be documented in one understandable model without hiding optional analytics behind vague wording. Analytics are disabled by default where appropriate, and event logs are reviewed for unnecessary precision.

Marketing and consent rules need equal attention. The Spam Act 2003 generally requires consent for commercial electronic messages and a clear, functional unsubscribe route, while the Australian Consumer Law can govern product claims, refunds and the promised functionality of paid digital products. These obligations connect directly to testing: a user who buys a ticket and later finds no accessible refund process has encountered a service failure and a compliance issue. Test purchases, chargebacks, restored purchases and refund notices belong in the regression schedule.

Time and travel assumptions can expose poor localisation. Berlin remains in Central European Time, but Sydney, Melbourne, Brisbane and Perth sit across several clocks, with some Australian cities observing daylight-saving changes. The schedule must identify the venue’s local time without shifting when an artist starts. Transport and late-night travel guidance should reflect local habits while remaining suitable for international visitors. For a Melbourne resident accustomed to myki and a Sydney resident using Opal, a clear transaction history is a useful benchmark for the Pallas ticket experience.

Making the release decision

Every issue enters a defect record with the device, operating system, venue location, network state, steps and expected result. Severity reflects operational impact, not who reported it. Critical defects—entry failure, incorrect safety information, inaccessible purchase or privacy loss—stop the release. Major issues require a verified fix and regression pass, while lower-priority visual problems enter a controlled follow-up list. Screenshots, traces and short video clips help the team reproduce the problem without repeating the event scenario.

An independent product specialist can challenge the research method and test coverage. A partner experienced in mobile product testing can review whether the chosen devices represent the audience, whether usability tasks reflect actual behaviour and whether release thresholds are meaningful. The review should remain independent of Pallas’s label and crew partners, preserving release ownership while adding expertise where the internal team lacks it.

The final decision is recorded as a release gate rather than a general impression. Pallas’s operations, programming and technical leads review the evidence, confirm that critical journeys pass in the building and note accepted risks. The next concrete step is to reserve E-Werk for a two-hour instrumented walk-through with one Android phone and one iPhone, recording offline navigation, ticket display and notification recovery as release-blocking checks.