Akceptační testování pomocí Robot Framework

Upozornění

Myslíme si, že tato informace může být pro někoho inspirací. V případě zájmu si můžete podrobnosti přečíst v diplomové práci Vais, R.: Akceptační testování v projektu TbUIS, odkazované též ze stránek celého projektu.
Článek není o tom, jak obecně používat Robot Framework.

Motivace

Chceme-li automatizovaně testovat pomocí rozsáhlejších scénářů, je funkcionální testování, tak, jak jsem jej používal (a je popsáno v předchozím článku), sice možné, ale ne úplně přehledné a efektivní (viz dále Rozsáhlé scénáře testů). Z tohoto důvodu jsme se snažili použít nějaký jiný vyhovující nástroj, kterým byl po poměrně rozsáhlém průzkum zvolen Robot Framework (RF).

Jak je asi obecně známo (alespoň pravidelným čtenářům Root.cz – viz Univerzální testovací nástroj Robot Framework), je nativním jazykem pro RF jazyk Python. V tomto jazyce je připravena celá řada externích knihoven (modulů), např. i modul SeleniumLibrary, pro testování webových stránek.
Pro naše testování jsme ale použili výhradně Javu, což RF také umožňuje. A zdrojové kódy pro RF byly připravovány v IntelliJ IDEA za využití Robot plugin.

Logická otázka ale samozřejmě zní: „Proč nepoužít Python pro celé akceptační testování? Proč do toho ‘míchat přes ruku‘ Javu?“ Odpověď má dvě části:

1. Je třeba inicializovat ovladač, který přes Selenium ovládá zvolený webový prohlížeč.

Tuto akci samozřejmě zvládá i již zmíněný Python modul SeleniumLibrary. Ovšem v již připravené a odladěné verzi knihovny Support (viz předchozí článek) je toto vše okamžitě k dispozici, včetně poměrně širokých možností konfigurace celého spouštění z textového konfiguračního souboru. Stačí to jen použít. (Poznámka – nezmiňuji zde funkční logování ze Support. To lze samozřejmě také okamžitě použít, ovšem RF má vlastní logování o „řád lepší“, takže bylo použito to z RF.)

2. Práce s jednotlivými elementy webové stránky. Pokud je webová stránka jednoduchá (úmyslně se vyhýbám pojmu ‘triviální’) a existuje na ní jen několik elementů nejlépe s jednoznačnými ID, pak nám modul SeleniumLibrary umožní tyto webové elementy jednoduše ovládat. Pokud je však stránka složitější (např. akce v jednoduché tabulce):

Nebo akce v (záměrně!) velmi složité tabulce:

Pak by bylo třeba v RF naprogramovat pomocí klíčových slov netriviální aktivity pro práci s těmito elementy. To je samozřejmě možné. Ovšem je to zbytečné, protože v knihovně Support jsou již všechny tyto aktivity k dispozici a již odladěné na předchozích funkcionálních testech. Navíc existují na vysoké úrovni abstrakce, tj. např. aktivita: „zapiš hodnocení C studentovi cyan z předmětu Introduction to Algorithms ve zkouškovém termínu 2020–08–26 09:34“.

Kromě toho je součástí knihovny Support i modul oracle (orákula), pomocí něhož se určí, jak má test dopadnout. Tento modul dovoluje mít i akceptační testy jednoduše plně automatizované.

Z tohoto důvodu byl tedy RF volán přes Jython z Javy.

Technologická poznámka:

Spouštíme přímo robotframework-3.2.1.jar, který má v sobě integrovaný Jython ( jython-standalone-2.7.2.jar).

Bylo bohužel nutné použít Javu 8, nikoliv Javu 11, ve které byly vyvíjeny funkcionální testy. Je to z důvodu, že při pokusu o spuštění pod Javou 11 hlásí robotframework-3.2.1.jar výjimku:
java.lang.IllegalArgumentException: Cannot create PyString with non-byte value
(Chyba je mj. reportována v https://github.com/robot­framework/robotframework/is­sues/3055 a jak zde reaguje samotný Pekka Klärck, tvůrce RF, je to opravdu problém Jythonu nikoliv RF.)

Schéma

Schéma spolupráce Javovské knihovny Support a testů v RF a jak se přejde od metod v javovské knihovně Support ke klíčovým slovům v RF:

Jedná se o několikavrstvý přechod, přičemž se přechodové fáze provádějí (generují) automatizovaně.

Problém bude vysvětlen na aktivitě, kdy si student chce zapsat nový předmět.

Poznámka: Již v minulých dílech se v diskuzi někteří čtenáři podivovali nad nezvyklými Javovskými identifikátory názvů tříd, např. Stu_OtherSubjects_Page. Věřte, že tento styl identifikátorů byl použit po zralé úvaze a mnohých pokusech s čitelností. Jistě by to šlo udělat i jinak, ale nám to prostě takto vyhovuje.

Java kód v knihovně Support

public static void enrollSubject(Student student, Subject subject) {
  Login_Actions.loginIfNecessary(student);
  Click.openUrlAndWait(Url.URL_STU_OTHERSUBJECTS);
  Stu_OtherSubjects_Page page = new Stu_OtherSubjects_Page();
  String subjectName = subject.getName();
  page.clickOnEnrollButton(subjectName);
  int number = student.getAllEnrolledSubjects().size();
  if (number < Const.STUDENT_MAX_SUBJECTS) {
    if (Stu_OtherSubjects_Check.checkEnrollSuccessAlert() == true) {
      student.enrollSubject(subjectName);
    }
  }
  else {
    Stu_Overview_Check.checkUpdateErrorAlert();
  }
  boolean correct = page.menu.isOtherSubjectsLinkSelected();
  String reason = "Actual menu item 'Other Subjects' is NOT selected";
  Check.checkCorrectness(correct, page.menu.OTHERSUBJECTS_LINK,reason);
}

Nejnižší vrstvou je integrace na knihovnu Support. Integrací rozumíme obalení (wrappers) dostupných metod knihovny Support pomocí kódu, který zpřístupňuje metody do prostředí Robot Frameworku.

V rámci nejnižší vrstvy je možné vytvářet i lokální podpůrné knihovny pro služby, které knihovna Support neposkytuje. Typickým příkladem je ověřování vstupních dat pro vyvolání metody z knihovny Support – zde volání metod ze třídy EntityValidator. Třídy wrapperů se generují automaticky ze tříd knihovny Support (proto jsou např. jména formálních parametrů  arg0Str).

public class Stu_OtherSubjects_Actions_Wrapper {
  public static final String ROBOT_LIBRARY_SCOPE = "GLOBAL";

  public void enrollSubject(String arg0Str, String arg1Str)
                   throws AssertionError, UnknownObjectException {
    Student arg0 = EntityValidator.getStudentByUserName(arg0Str);
    Subject arg1 = EntityValidator.getSubjectByName(arg1Str);
    Stu_OtherSubjects_Actions.enrollSubject(arg0,arg1);
  }
}

Druhou vrstvu můžeme do určité míry chápat jako pomocnou. Tato vrstva definuje základní klíčová slova již ve formátu RF jako ekvivalenty metod knihovny Support.

Tato vrstva se opět generuje automaticky. Metoda enrollSubject() wrapperu je již volána v syntaxi RF klíčových slov, tj. Enroll Subject  – slova jsou rozdělena jednou mezerou a začínají vždy velkým písmenem.

Poznámka: Vrstva přináší snadnou možnost nahradit integrační vrstvu již na úrovni návrhu struktury akceptačních testů. Pokud by vznikla potřeba zaměnit knihovnu Support, modifikovala by se právě tato vrstva řídících klíčových slov. Jednalo by se například o přímé vyvolání frameworku Selenium v rámci RF. Takové nahrazení by odpoutalo projekt od závislosti na specifickém prostředí Jython. Za předpokladu, že by nahrazující knihovna dodržela stávající kontrakt knihovny Support, by nebylo třeba modifikovat stávající testovací scénáře.

V projektu UIS je to ovšem jen teoretická možnost, protože napsat a odladit znovu v Pythonu kód knihovny Support by byla poměrně náročná práce.

Poznámka: Prvními dvěma příkazy následujícího klíčového slova je logování parametrů testu. Tento malý „trik“ se postupem času ukázal jako velký pomocník pro ladění testů. Jak již bylo řečeno dříve, logování – zejména možnosti prohlížení logovacího reportu – má RF na vysoké úrovni.

*** Keywords ***
Student Enroll Subject
    [Arguments]  ${name}  ${subject}
    Log    ${name}
    Log    ${subject}
    Stu_OtherSubjects_Action_Wrapper.Enroll Subject  ${name}  ${subject}

Nad touto vrstvou řídících klíčových slov je vytvářena vrstva konkrétních akcí v rámci UIS aplikace. Přibývají zde tagy (např. UC.06) informující o tom, jakou část specifikace (v našem případě případů užití) bude šablona pokrývat. Opět se jedná o definice klíčových slov. Tato připravovaná klíčová slova jsou hotovým scénářem (šablonou) testu.

*** Keywords ***
Enroll Subject
    [Tags]  UC.06
    [Arguments]  ${StudentUserName}  ${SubjectName}

    Student Enroll Subject  ${StudentUserName}  ${SubjectName}
    Student Check Enroll Success Alert
    Student Check Enrolled Subjects  ${StudentUserName}
    Student Check Other Subjects  ${StudentUserName}

Poslední vrstvou je příprava konkrétních testovacích scénářů. V rámci scénáře je provedeno spojení s šablonou testu ( [Template]) a přirazení odpovídajících datových souborů. V datových souborech jsou připraveny datové řady ( @{SuccesEnrolls}) pro jednotlivé scénáře.

*** Settings ***
Variables ../data/student/UC06_EnrollSubject.yaml

*** Test Cases ***
TC.06.01 Student Enroll Subject
    [Template]          Enroll Subject
    [Tags]              UC.06  HappyDay  CRITICAL
    [Documentation]     In this test case is tested Happy Day scenario Subject enrolment,
    ...                 when all prerequisites is fullfilled.

    FOR    ${params}    IN    @{SuccesEnrolls}
       @{params}
    END

Datová řada SuccesEnrolls ve formátu YAML v souboru  UC06_EnrollSubject.yaml:

SuccesEnrolls:
  -
    - cyan
    - Database Systems
  -
    - maroon
    - Introduction to Algorithms

Výhodou této vrstvené implementace je přidávání nových testovacích variant bez nutnosti opakovat zdrojový kód scénáře či modifikovat soubor scénáře. Jsou jasně oddělena data testu od jeho logiky. Toto rozložení mj. přispívá ke snazší kontrole vývoje testovacích scénářů.

Představme si nyní situaci, kdy jsou společně se zákazníkem připravovány akceptační testovací scénáře. Připravit scénář testu s pomocí prostředků RF může být technicky složitější (a uvedené ukázky dokumentují, že skutečně je). Zákazník sice ve výsledku snadno chápe, co které klíčové slovo znamená, ale nemusí si být vědom všech technických konsekvencí jeho konstrukce. Programátor tedy připravuje scénáře dle zadání od zákazníka. Zákazník má pak v plné režii datové řady testu.

Tímto způsobem lze tedy velmi snadno vyzkoušet značné množství datových kombinací.

Propojení testu, jeho šablony a datové řady lze přehledně vidět na obrázku:

Poznámka: Může samozřejmě nastat situace, na kterou mě upozornil kolega při revizi tohoto článku. „Zákazník dodal akceptační testy popsané v dokumentu a nemá čas spolupracovat na jejich reformulaci tak, aby testy bylo možné otestovat v RF. Vyplatí se v tomto případě psát testy pomoci RF?“ Na tuto otázku nedokáži úplně jednoznačně odpovědět, protože je faktem, že to, co bylo napsáno v RF, bych dokázal napsat pomocí dříve popsané technologii v Javě (viz též dále Rozsáhlé scénáře testů).

Pro psaní akceptačních testů v RF hovoří:

• Jejich větší čitelnost (viz dále srovnání scénáře testů v Javě a v RF) a tím i snadnější vytváření různých kombinací testovaných situací.
• Pro zákazníka mnohem pochopitelnější a přehlednější, tj. přesvědčivější, logování v RF.
• Snadné vytváření parametrizovaných testů z již existujícího testu (viz výše  TC.06.01 Student Enroll Subject).

Naopak proti použití RF stojí:

• Nutnost automatické konverze metod z knihovny Support a ověření správnosti této konverze.
• Nutnost udržování další struktury projektu.
• Nutnost mít o jednu technologii (RF) víc, což může zvyšovat složitost tj. počet problémů, např. problém zmíněný výše s nutností použít Javu 8.

Jaké byly vytvořeny testy

Výchozím podkladem připravených akceptačních testů byly ekvivalenty hlavních a vedlejších toků popsaných v případech užití.

Opět příklad, kdy si student zapisuje předmět. Příslušný UC.06 mj. obsahuje

Postconditions

1. UIS vloží předmět do studentova seznamu předmětů a provede další navazující změny v příslušných tabulkách DB

1. je stále zobrazena stránka menu Other Subjects

1. objeví se hlášení o úspěšném provedení

1. předmět zmizí ze seznamu v tabulce v menu Other Subjects

1. předmět se zobrazí v seznamu v tabulce Enrolled Subjects v menu My Subjects

1. předmět se zobrazí v seznamu v tabulce v menu Other Exam Dates

1. Teacher's View: u příslušného učitele se student objeví v seznamu studentů zapsaných na tomto předmětu v tabulce v menu My Subjects

Alternative Flows

●        1a. Tabulka je prázdná, tj. student již má zapsány všechny existující předměty

o 1a-1. Není možné provést tento use case

●        1b. Tlačítko Enroll u zapisovaného předmětu je disabled, protože předmět ještě neučí žádný učitel.

o 1b-1. Není možné provést tento use case

●        1c. Tlačítka Enroll u všech předmětů jsou disabled, protože student již má zapsán maximální počet (7) zapsaných předmětů

o 1c-1. Není možné provést tento use case

●        2a. Při zápisu nového předmětu do DB došlo k vnitřní chybě v UIS / DB.

Postconditions:

●        zůstává zobrazena obrazovka menu Other Subjects

●        objeví se chybové hlášení o neúspěšném provedení

●        k zápisu / změně nikde nedojde

Významné části Postconditions (body 3, 4 a 5) a Alternative Flows (1b, 1c) uvedené v UC.06 jsou pak pokryty testy:

Poznámky:

• Body 1, 2 a 7 z Postconditions byly ověřeny sadou funkcionálních testů.
• Alternative Flows 1a nelze při aktuálním nastavení DB nasimulovat. Tento TC musí být součástí jiných testů.
• TC.06.04, kdy si student chce zapsat již zapsaný předmět, není v Alternative Flows vůbec popsán. Z povahy aplikace k tomuto případu nemůže dojít (již zapsaný předmět se nezobrazuje v tabulce, což již bylo ověřeno sadou funkcionálních testů) a proto student nemůže „kliknout“ na zápis předmětu.

*** Test Cases ***

TC.06.01 Student Enroll Subject
    [Template]          Enroll Subject
    [Tags]              UC.06  HappyDay  CRITICAL
    [Documentation]     In this test case is tested Happy Day scenario Subject enrolment,
    ...                 when all prerequisites is fullfilled.

    FOR    ${params}    IN    @{SuccesEnrolls}
       @{params}
    END

TC.06.02 Student Cannot Enroll Subject - No Teacher
    [Template]          Enroll Subject Should Fail
    [Tags]              UC.06  MAJOR
    [Documentation]     In this test case si tested alternactive flow enrollment.
    ...                 Test fails when student successfuly enrolls subject.

    FOR    ${params}    IN    @{NoTeacher}
       @{params}
    END

TC.06.03 Student Can Not Enroll Subject - Too Many Subjects
    [Template]          Enroll Subject Should Fail
    [Tags]              UC.06  MINOR
    [Documentation]     In this test case is tested alternactive flow enrollment.
    ...                 Test fails when student successfuly enrolls subject.

    FOR    ${params}    IN    @{TooMany}
       @{params}
    END

TC.06.04 Student Cannot Enroll Subject - Already Study Subject
    [Template]          Enroll Subject Should Fail
    [Tags]              UC.06  MINOR
    [Documentation]     In this test case is tested alternactive flow enrollment.
    ...                 Test fails when student successfuly enrolls subject.

    FOR    ${params}    IN    @{AlreadyStudy}
       @{params}
    END

TC.06.05 Student Display Other Subjects Page
    [Template]          Validate All Parts Of Student Other Subjects Page
    [Tags]              UC.06  MINOR
    [Documentation]     In this test case is tested alternactive flow enrollment.
    ...                 Test fails when student successfuly enrolls subject.

    FOR    ${params}    IN    @{StudentsList}
       @{params}
    END

Stav, kdy je u každého testovacího případu pomocí tagu označeno, ke kterému případu užití patří, se dá z výhodou využít při agregaci výsledků. Z nich je pak na první pohled zřejmé, zda se na něco nezapomnělo. A při podrobnějším pohledu lze zkoumat, zda konkrétní testovací případ pokrývá právě požadovaný případ užití.

Rozsáhlé scénáře testů

Kromě výše uvedeného důkladného pokrytí jednotlivých UC, bylo dále navrženo několik (celkem 13) scénářů, které si kladou za cíl detailněji ověřit fungování aplikace. Tyto scénáře sdružují několik operací v jednom testu.
Jako příklad může sloužit scénář „Pomalý student“, který simuluje dva studentovy neúspěchy na zkoušce a poslední úspěch.
Učitel Lazy začne vyučovat předmět Linear Algebra. Tento předmět si zapíše studentka Magenta. Učitel vypíše první zkouškový termín. Studentka se na něj přihlásí, učitel jí udělí hodnocení F (fail). Situace se opakuje pro druhý zkouškový termín – opět F. A až při třetím (posledním možném) zkouškovém termínu obdrží studentka hodnocení E. Zápis tohoto scénáře je ve funkcionálních testech možný, ale pro zákazníka málo čitelný.

Ukázka zdrojového kódu testu v Javě (kód byl napsán pro budoucí srovnání s RF jako doplněk funkcionálních testů), kdy maximální část výkonného kódu (tj. kódu manipulujícím s jednotlivými elementy webových stránek aplikace UIS) je skryta v knihovně Support.

  @Test
  @DisplayName("Whole cycle - from enrolling to passing")
  void test_1() {
    setParameters("magenta", "lazy", "Linear Algebra");

    Tea_OthersSubjects_Actions.participateInSubject(teacher, subject);
    Stu_OtherSubjects_Actions.enrollSubject(student, subject);

    Tea_NewExamDates_Actions.newExamDate(teacher, subject, "1", examDate);
    Stu_OtherExamDates_Actions.registerExamDate(student, subject, examDate);
    Tea_SetEval_Actions.setEvaluation(teacher, subject, examDate, student, "F");

    String secondExamDate = Configurations.EXAM_DATE_SECOND;
    Tea_NewExamDates_Actions.newExamDate(teacher, subject, "2", secondExamDate);
    Stu_OtherExamDates_Actions.registerExamDate(student, subject, secondExamDate);
    Tea_EvalTable_Actions.setNewEvaluation(teacher, subject, secondExamDate, student, "F");

    String thirdExamDate = Configurations.EXAM_DATE_THIRD;
    Tea_NewExamDates_Actions.newExamDate(teacher, subject, "3", thirdExamDate);
    Stu_OtherExamDates_Actions.registerExamDate(student, subject, thirdExamDate);
    Tea_EvalTable_Actions.setNewEvaluation(teacher, subject, thirdExamDate, student, "E");
  }

A ukázka téhož scénáře v Robot Frameworku (samozřejmě opět s využitím knihovny Support), kdy můžete porovnat čitelnost obou zápisů:

Poznámka: Zde je ještě použit jiný způsob předávání skutečných parametrů klíčových slov – přímo v textu klíčového slova.

Dříve uváděný způsob (daný automatickou generací klíčových slov) byl:
  Student Enroll Subject ${student} ${subject}

Čitelnější způsob:
Student ${student} Enroll Subject ${subject}

*** Test Cases ***
Slow student
     Teacher ${teacher} Participate In Subject ${subject}
     Student ${student} Enroll Subject ${subject}

     ${firstExamDate} =  Dates Prepare Exam Date
     Teacher ${teacher} Create Exam For Subject ${subject} On ${firstExamDate} For 1
     Student ${student} Register Exam From ${subject} On ${firstExamDate}
     Teacher ${teacher} Set Evaluation F To Student ${student} For exam ${firstExamDate} of Subject ${subject}

     ${secondExamDate} =  Dates Prepare Second Exam Date
     Teacher ${teacher} Create Exam For Subject ${subject} On ${secondExamDate} For 2
     Student ${student} Register Exam From ${subject} On ${secondExamDate}
     Teacher ${teacher} Set Evaluation F To Student ${student} For exam ${secondExamDate} of Subject ${subject}

     ${thirdExamDate} =  Dates Prepare Third Exam Date
     Teacher ${teacher} Create Exam For Subject ${subject} On ${thirdExamDate} For 3
     Student ${student} Register Exam From ${subject} On ${thirdExamDate}
     Teacher ${teacher} Set Evaluation E To Student ${student} For exam ${thirdExamDate} of Subject ${subject}

Když se porovnají počty řádek, vyjde to nastejno. Ale když srovnáme čitelnost kódu, pak např.

Java: Tea_OthersSubjects_Actions.participateInSubject(teacher, subject);

versus

RF: Teacher ${teacher} Participate In Subject ${subject}

Je zvýšení srozumitelnosti testu jasně patrné.

Až tyto scénáře zaměřené na málo běžné aspekty aplikace pomohly odhalit dvě chyby, které v aplikaci UIS i přes důkladné předchozí testování přetrvávaly. Pro opravdové zájemce dodám, že popis těchto odhalených chyb je na str. 48 ve zmíněné diplomové práci.

Rozsahy zdrojových kódů a počty testů

Celkově byla vytvořena hierarchická struktura testů, jejich klíčových slov a datových řad. Jedná se celkem o 122 souborů .robot o celkovém počtu 4 541 řádek. Lze si prohlédnout podrobnější tabulku a samozřejmě i na Gitu celkovou strukturu.

Opět je zajímavé srovnání velikosti testů s velikostí celé testované aplikace UIS (8 000 řádek kódu). Znovu vidíme, že testy (a to bez započtení knihovny Support!!!) představují více než polovinu rozsahu aplikace.
Testování, pokud má být provedeno důkladně a koncepčně, je prostě drahá záležitost.

Co se týče počtu testovacích případů, bylo vytvořeno celkově 122 TC. Z tohoto počtu pak 98 TC ověřuje základní chování dle UC specifikace a zbylých 24 TC je zaměřeno na speciální případy užití UIS (rozsáhlé scénáře). Každý scénář je spuštěn několikrát s různými datovými sadami. V rámci testování tak dojde až k 6 008 porovnání (assertů) očekávaných stavu aplikace UIS.

Poznámka: Hodnota 6 008 je velmi podobná hodnotě 7 493, což je celkový počet porovnání při testování pomocí funkcionálních testů.

Popsaná sada akceptačních testů byla spuštěna a odladěna na bezporuchovém klonu aplikace UIS a následně pak na všech 28 jejích poruchových klonech. Provedené analýzy nalezených selhání potvrdily, že akceptační testy opravdu odhalují relevantní defekty. Opět k tomu výrazně napomohly tabulky agregovaných výsledků:

Zajímavé může být i srovnání „úspěšnosti“ funkcionálních testů versus testů akceptačních. Podrobně si je lze prohlédnout v tabulce. Z ní je vidět, že – i přes společný základ v knihovně Support – se jedná o odlišné typy testů.

Závěr

To, že akceptační testy odhalily dvě závažné logické chyby, které v aplikaci UIS přes její dvouleté podrobné testování přetrvávaly, potvrzuje existenci pesticidového paradoxu. Pesticidový paradox je stav, kdy sada testů neodhaluje určité selhání, ale aplikace defekty způsobující toto selhání obsahuje.

Poznámka: Pesticidový paradox se projevil i „obráceně“, tj. funkcionální testy odhalily selhání, ale akceptační testy nikoliv. Důvody, proč akceptační testy nedetekovaly u poruchového klonu selhání, jsou podrobně diskutovány ve zmíněné diplomové práci.

Nelze tedy jednoznačně říci, že některý typ testů je lepší než test jiný.

Celkově lze konstatovat, že v našem případě se pro psaní akceptačních testů ukázal Robot Framework jako významný pomocník. V tomto článku byly jen velmi okrajivě zmíněny jeho možnosti logování a zejména zobrazování logovacích záznamů. To je skutečně na špičkové úrovni. Zájemci se mohou „proklikat“ uceleným reportem všech provedených testů.

Jako každý nástroj vyžaduje i RF určitou počáteční investici v podobě času a úsilí (je to open source), ale pak máme k dispozici výkonný, spolehlivý a udržovaný nástroj (navíc s rychlou učící křivkou). Dle názoru naší výzkumné skupiny se tato investice vyplatí.

Tak, jako v předchozí minisérii, nabízím i zde pro případné zájemce možnost dalších konzultací.