Testowanie multitenancy - praktyczne porady

Przez cztery lata pracy jako testerka oprogramowania miałam okazje testować aplikacje
multitenancy dla branży związanych z kontrolą dostępów a około dwa lata temu miałam
przyjemność wystąpić na konferencji, organizowanej przez mojego pracodawcę z tematem
“Testowanie multitenancy (nie tylko) w branży access control”. Teraz postanowiłam wrócić do
tego tematu i bardzo się zdziwiłam - ilość materiałów w internecie jest teraz o wiele większa! Dla
mnie oznacza to, że rozwiązania multitenancy są faktycznie coraz bardziej popularne. Artykuły, na
które tra ałam dotyczyły jednak głównie architektury i kwestii technicznych a także wad i zalet
rozwiązań single i multi tenant.

W tym artykule chciałabym poruszyć temat testowania. Czym testowanie multitenancy różni się
od testowania aplikacji single tenant? Na co warto zwrócić uwagę, gdy już tra my do takiego
projektu? Często w software house’ach oraz mniejszych rmach jesteśmy jedynymi testerami w
zespole, nie mamy możliwości wymiany poglądów czy nawet prośby o komentarz koleżanki/
kolegi testera. Mam nadzieję, że mój wpis pomoże Wam i będziecie mogli wcielić moje praktyczne
porady w życie!

Czym jest multitenancy?

Architektura oparta na multi tenancy słu y wielu u ytkownikom, których okre lamy wła nie
mianem tenantów. Tenantem za to okre lamy grup u ytkowników, którzy maj dost p i wgl d
do u ytkowania konkretnej wersji aplikacji.

Aplikację single tenant możemy porównać do domu jednorodzinnego. Cechy charakterystyczne

aplikacji stworzonej dla jednego klienta na zamówienie to między innymi:

1. Architektura dedykowana klientowi - zawiera tylko takie funkcjonalności, jakie klient

potrzebuje
2. Jedna baza danych - zwiększa bezpieczeństwo i kontrolę nad danymi
3. Dedykowany interfejs aplikacji, który zaspokaja indywidualne potrzeby klienta
4. Zoptymalizowane zasoby

Aplikację multi-tenant łatwo jest porównać do bloku mieszalnego. Cechy

charakterystyczne dla tego rozwiązania to:

1. Niskie koszta obsługi - utrzymywanie aplikacji jest łatwiejsze a koszt rozkłada się na
wielu klientów
2. Baza danych - wiele baz danych, które muszą być odpowiednio zabezpieczone
3. Ograniczony interfejs - design jest współdzielony z innymi tenantami, mała możliwość
personalizacji
4. Skalowalność - idealne rozwiązanie dla szybko rozwijających się rm

Zostając przy naszym porównaniu do mieszkalnictwa - dom obarczony jest wyższymi

kosztami utrzymania, zapewnia lepszą prywatność i został wybudowany specjalnie dla
użytkownika więc spełnia jego potrzeby. Przy mieszkaniu w bloku współdzielimy sporo
kosztów ale każde mieszkanie jest do siebie podobne - ma ten sam układ, ograniczają
nas ściany nośne - możemy więc wprowadzić tylko nieznaczne poprawki.

Zalety architektury multitenant

1. Pozwala zaoszczędzić pieniądze: współdzielony koszt, model pay what you use
2. Optymalizuje czas spędzony na utrzymaniu po wydaniu aplikacji klientowi
3. Zapewnienie aktualizacji - są one dostarczane przez dostawcę
4. Łatwiejsza administracja - dostawcy mają jeden system do monitorowania
ż
fi
ż
ś
ż
ę
ż
fi
fi
ś
fi
ą
ę
ś
ą
5. Łatwy hosting - klient nie martwi się o infrastrukturę
6. Łatwa skalowalność - system można łatwo rozbudować

Wyzwania

1. Mniejsza elastyczność
2. Rygorystyczne zabezpieczenia
3. Ryzyko niedostępności
4. Izolacja danych

Strategie testowania

Skoro przeszliśmy już przez podstawowe informacje, znamy wady oraz zalety
multitenancy możemy przejść do konkretów interesujących testera - jakie strategie
testowania obrać? Jakie testy są kluczowe i czy w ogóle możemy mówić, że testowanie
aplikacji single i multi temat się od siebie różnią?

Na co warto zwrócić uwagę testując aplikację multi- tenant?

1. Testy funkcjonalne

- izolacja danych poszczególnych tenantów

- Testowanie kon guracji oraz poszczególny funkcjonalności w zależności od wymagań
klienta

2. Bezpieczeństwo
- testy autentykacji i autoryzacji - tenant A nie powinien być w stanie zalogować się na
konto Tenanta B, użytkownicy/klienci powinni mieć dostęp wyłącznie do swojej domeny
- Testy kompatybilności - cross tenant compability, testowanie przeglądarek i urządzeń

3. Usability
- dedytkowane kon guracje dla klienta

4. API I integracje
- sprawdzenie api - czy spełnia restrykcje
- Integracja z 3rd party

5. Testy baz danych:

- tenanci nie mają dosępu do informacji drugiego Tennanta

6. Automatyzacja:
- jakie podejście obierzemy?
fi
fi
 ---

Praktyczne Porady Dotyczące Testowania Multitenancy: Od Teorii do Praktyki

Po czterech latach doświadczenia w testowaniu oprogramowania i dwóch latach od

mojego wystąpienia na konferencji na temat testowania rozwiązań multitenancy, wracam
do tego zagadnienia z nowym spojrzeniem. Zaskoczyła mnie ilość dostępnych obecnie
materiałów – co świadczy o rosnącej popularności tego typu rozwiązań. Przy tej okazji
chciałabym podzielić się moimi praktycznymi radami, szczególnie przydatnymi w
przypadku, gdy jesteśmy jedynymi testerami w zespole.

Czym Jest Multitenancy?

W skrócie, multitenancy to architektura oprogramowania, która umożliwia obsługę wielu

użytkowników (tenantów) za pomocą jednej instancji aplikacji. Porównując do
mieszkalnictwa, aplikacja multi-tenant przypomina blok mieszkalny, gdzie koszty
utrzymania są niższe, ale ogranicza nas wspólny design i małe możliwości personalizacji.
Natomiast aplikacja single tenant jest jak dom jednorodzinny – oferuje większą
prywatność i jest dostosowana do indywidualnych potrzeb klienta.

Zalety i Wyzwania Architektury Multitenant

- Zalety: Oszczędność kosztów, łatwiejsza administracja, łatwa skalowalność.

- Wyzwania: Mniejsza elastyczność, rygorystyczne zabezpieczenia, ryzyko
niedostępności, izolacja danych.

Strategie Testowania Multitenancy

Testowanie multitenancy różni się od testowania rozwiązań single tenant, przede

wszystkim ze względu na unikalne wyzwania związane z izolacją danych i
bezpieczeństwem. Oto co warto wziąć pod uwagę:

1. Testy Funkcjonalne
- Izolacja Danych: Upewnij się, że dane każdego tenanta są dobrze izolowane.
- Kon guracje i Funkcjonalności:** Testuj zgodnie z wymaganiami klienta.

2. Bezpieczeństwo
- Autentykacja i Autoryzacja: Użytkownicy powinni mieć dostęp tylko do swojej domeny.
- Testy Kompatybilności: Cross-tenant compatibility, przeglądarki i urządzenia.

3. Usability
- Dedykowane Kon guracje: Sprawdź, jak kon guracje wpływają na użyteczność dla
klienta.

4. API i Integracje
- Restrykcje API: Czy spełniają one wymagane restrykcje?
- Integracja z 3rd Party: Jak aplikacja współpracuje z zewnętrznymi systemami?

5. Testy Baz Danych

- Upewnij się, że tenanci nie mają dostępu do informacji innych tenantów.
fi
fi
fi
6. Automatyzacja
- Podejście: Jaka strategia będzie najefektywniejsza?

Podsumowanie

Testowanie aplikacji multitenancy wymaga szczegółowego podejścia, uwzględniającego

unikalne cechy tego typu architektury. Kluczowe aspekty to izolacja danych,
bezpieczeństwo, użyteczność oraz skuteczna automatyzacja. Mam nadzieję, że moje
wskazówki pomogą wam w codziennej pracy z tego typu aplikacjami. Czy macie jakieś
dodatkowe rady lub doświadczenia związane z testowaniem multitenancy? Podzielcie się
nimi w komentarzach!

---

Cross-tenant testing in Gherkin involves testing scenarios that span multiple tenants in
your CRM multitenant application. Here are some examples of test cases for cross-tenant
testing in Gherkin format:

**Scenario 1: Generating Cross-Tenant Reports**

```gherkin
Feature: Cross-Tenant Reporting

Scenario: Generating a Summary Report Across Tenants

Given I am logged in as an admin user
When I navigate to the "Cross-Tenant Reports" section
And I select the "Summary Report" option
Then the system should display a list of all tenants
And I select multiple tenants
And I specify the report parameters
When I click on the "Generate Report" button
Then the system should generate a summary report for the selected tenants
And the report should include data from all selected tenants
And the report should be downloadable in PDF format
```

**Scenario 2: Data Sharing Between Tenants**

```gherkin
Feature: Data Sharing Between Tenants

Scenario: Sharing an Event between Tenants

Given I am logged in as an admin user
When I create a new event for Tenant A
And I share the event with Tenant B
Then Tenant B should be able to see and access the shared event
And any updates made to the shared event by Tenant A should re ect in Tenant B's
view
```

**Scenario 3: Cross-Tenant User Access**

```gherkin
Feature: Cross-Tenant User Access

Scenario: User Access to Multiple Tenants

Given I am logged in as a user with access to multiple tenants
When I switch between tenants in the application
Then I should be able to access and manage data speci c to each selected tenant
And I should not have access to data from other tenants
```

**Scenario 4: Cross-Tenant Data Search**

```gherkin
Feature: Cross-Tenant Data Search

Scenario: Searching for Shared Customer Data

Given I am logged in as an admin user
When I search for a customer's data across all tenants
Then the system should display results from all tenants where the customer exists
And I should be able to view and manage customer data for each tenant separately
```

**Scenario 5: Cross-Tenant Security**

```gherkin
Feature: Cross-Tenant Security

Scenario: Unauthorized Cross-Tenant Access

Given I am logged in as a user from Tenant A
When I attempt to access data or features speci c to Tenant B
Then I should receive an "Access Denied" message
And I should not be able to perform any actions on data from Tenant B
```

These Gherkin scenarios cover various aspects of cross-tenant testing, including

reporting, data sharing, user access, data search, and security. You can adapt and
expand these scenarios based on your speci c requirements and application
functionalities.
fi
fi
fi
fl
 Testing a multitenant CRM application with three distinct tenants involves ensuring that
each tenant's speci c requirements are met while maintaining data isolation between
them. Here are some test cases to consider:

**1. Tenant Onboarding:**

- Verify that each tenant can be onboarded successfully.
- Ensure that the data for each tenant is isolated and not accessible by other tenants.

**2. User Roles and Permissions:**

- Test that each tenant can de ne user roles and permissions speci c to their needs.
- Verify that users from one tenant cannot access or modify data from other tenants.

**3. Tenant Customization:**

- Test if each tenant can customize their CRM with their branding and speci c
con gurations.
- Ensure that the customizations do not a ect other tenants.

**4. Ticket Selling (1st Tenant - Event Agency):**

- Create and sell tickets for events within the rst tenant's domain.
- Verify that tickets are accurately recorded, and revenue is calculated correctly.

**5. Ticket Administration (2nd Tenant - Football Club):**

- Ensure that the football club can create events and manage tickets for their monthly
event.
- Test the ticket scanning devices to ensure they can scan tickets correctly.
- Verify that data from the football club does not interfere with data from other tenants.

**6. Cricket Championships (3rd Tenant - Cricket Association):**

- Test the ability to create and manage multiple cricket events simultaneously on three
stadiums.
- Ensure that ticketing for these events is handled properly without con icts.
- Verify that the application can handle the complexity of scheduling and managing
multiple events simultaneously.

**7. Data Isolation:**

- Test scenarios where one tenant tries to access data from another tenant and ensure
that access is denied.
- Verify that data from one tenant is not mixed up with data from other tenants.

**8. Performance Testing:**

- Simulate a high load scenario for each tenant to test the application's scalability.
- Ensure that response times remain acceptable, and the system can handle the
expected load.

**9. Security Testing:**

- Perform security testing to identify vulnerabilities such as SQL injection, cross-site
scripting, and data breaches.
- Ensure that each tenant's data is stored securely and is not accessible by
unauthorized users.
fi
fi
fi
ff
fi
fi
fl
fi
 **10. Backup and Restore:**
- Test backup and restore functionality for each tenant's data to ensure data recovery
in case of failures.

**11. Tenant Scaling:**

- Test the application's ability to add new tenants dynamically and ensure that it can
handle a growing number of tenants.

**12. Data Migration:**

- Test data migration processes when a tenant decides to leave or when a new tenant
is onboarded.

**13. Reporting and Analytics:**

- Verify that each tenant can generate custom reports and analytics speci c to their
business needs.

**14. Disaster Recovery:**

- Simulate a disaster scenario and test the application's ability to recover data and
maintain business continuity.

**15. Cross-Tenant Testing:**

- In some cases, perform testing to ensure that speci c functionalities that need to
span multiple tenants (e.g., reporting across all tenants) work correctly.

Remember to document all test cases, test results, and any issues found during testing.
Test each tenant's functionalities thoroughly while ensuring data isolation and tenant-
speci c con gurations are maintained.
fi
fi
fi
fi