Názory k článku Co to znamená „pořádně“ otestovat webovou aplikaci?

@Honzucha

devel manageru
procesu Development -> Testing -> UAT -> Pre-Production -> Production Release
BI oddeleni
dedikovanych testerech
unit testing nad DWH
MOLAP modely
Dashboardy a reporty
TestRail a Jenkins
mame celkem blizko k CI/CD

Bingo!

Co vas v te skole uci? Projit zkouskami? Chyby na urcite urovni komplexity podporene lidskym faktorem jsou nevyhnutelne. Softwarove produkty jsou jedny z nejkomplexnejsich stroju ktere clovek kdy vyvinul. Kazdy zkuseny manazer akceptuje chybovost pri vyvoji jako bezny jev se kterym je treba pocitat.

Procesy testovani (oddelene od i od primarniho vyvoje) jsou zakladni praktiky inzenyrstvi. Pisi inzenyrstvi protoze je to vec ktera jde skrz mnoho oboru a netyka se jen software.

To slovo inzinirstvi je presne ten zakladny problem. Moja skusenost je ta, ze kedze sa to nemoze zrutit ako most tak naprosta vacsina manegerov pristupuje k testom ako niecomu co pokial mozno treba osekat ako sa da a kedze sa nenamahaju tomu rozumiet tak jedina metrika co poznaju je pokrytie kodu testami co je vyzera na prvy pohlad fajn ale o skutocnej kvalite testov to az tak moc nehovori. Keby aspon trocha uvazovali ako pises tak by kvalita skokovo vzrastla. Len by potrebovali miesto debilnych grafov obcas aj vzdelat a nielen 5 minut cez google

Nebudem sem davat url iba citujem:

Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same.

Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”

Ano, az na to ze kolko rokov, desatroci, storoci sa vyvyjalo stavebnictvo, materialy. Pri montazi aut, v stavebnictve sa pouzivaju standardizovane dielce, maju standardne rozmery atd. Nikto pocas stavby nezmeni zrazu priemer odpadovych rur s tym ze ine sa uz nebudu dat zohnat. Pri vyrobe sa nezmenia zavity na skrutkach z noci na den, co je celkom bezny jav pri sw - rozne automaticke updaty. Nehovoriac o tom ze vecsina strojov, pristrojov sa daju rozobrat na relativne jednoduche zakladne suciastky alebo aspon moduly (vynimajuc digitalnu elektroniku ale to sme zasa pri IT). Pri SW to ide dost tazko.

Realita: Zakaznik kupuje burger z obrazku za 6eur. Cim skor ho ma tym menej ho trapi za co zaplatil.
To je bezny kontrakt b2b. To ze ludia ktory to vyvijaju maju nervy a ludia co to pouzivaju maju nervy nikoho nezaujima.

Predpokladajme ze nikde inde niesu chyby iba v aplikacii a ze zakaznik dodal uplne deterministicku specifikaciu na urovni pravdivostnych tabuliek a programator by kopiroval specifikaciu. Pekne db,b-e,f-e,vcs,bs,ds,t­s,pps,ps.... naplanovane devops ako zo skatulky. Tak tam tie chyby ozaj robi iba programator.

Zvycajne projekt taha ten jeden programator. Robi uplne vsetko potyka sa s chybami ktore sa nedaju casto predpokladat. Ma 10% casu na vyvoj. Zvycajne caka na doplnenie specifikacie ci pridanie disk space niekam. Nic poriadne nemoze zmenit lebo vsade su neake zavislosti a nieje podla coho zistit ako to ma fungovat alebo nema prava.
Zadania uz maju matematicke/logicke chyby/nepresnosti. Priklad nieco neplati do 15teho roku je to 14.99, 15, 15.99? Zakazte platbu MC proste sa neratalo s tym ze niekto pouzije Amex a nie Visu. Dajte to na druhu az na to ze casom prisli na to ze to vracia iba kladne hodnoty....

Snad som v niecom vyjasnil ze kde su chyby. Snazil som sa pisat co najmenej a nejde mi to.
V texte su asi chyby nakolko som sa snazil to zosekat na co najmenej.

Chyby jsou všude.

Jako když jedna firma v v online šachách ukládala partie do DB naserveru a indexovala je typem uint. V aplikaci na klientovy uint bylo uint32_t, na serveru uint bylo uint64_t. Po 2^32 partiích začala být dobrá sranda... Testama to prošlo, nikoho nenapadlo poslat dost vysoký číslo partie během testování.

Nebo hloupý string. Widlí appka má CP1250, verze pro Linux UTF-8 (díky za to, Schroedingerova kočko) a server je nějaký bastl s UTF16. Testuje se to na datech výhradně z ASCII charsetu. A je krásně vymalováno...

Nebo latence serveru byla zaručena specifikací do 10ms, expert dal do klienta s UDPčkem timeout 10ms (podle specifikace přece server odpoví), ale vůbec ho nenapadlo, že klient bude od serveru 500km (rychlost šíření signálu) a zůstane to občas viset někde v buffer u na routeru... Většinou to jelo, ale při "blbým počasí" to mělo výpadky, data ze serveru přišla až na klienta, jenom klient je ignoroval. Po změně na 15ms všechno bez problémů (najít jim to trvalo tři týdny).

Tož asi tak...

No ja som zazil seleniove testy.
Islo o nastavenie hesla. User prisiel na stranku napisal heslo GUI(f-e) vyhodilo hlasku o tom ze heslo nesplna vsemozne kriteria no kniznica(b-e) to heslo nastavila.

Nedokáži si představit, že by takovéto chování bylo způsobeno chybou Selenium WebDriver. Samozřejmě nepopírám, že je něco takového možné ;-)
Nebyly to ale náhodou testy pomocí Seleniun IDE (skripty)?

Ano presne tak Seleniun IDE (skripty).
Web zahlasil ze heslo neresetol co bolo ucelom testu otestovat pravidla. Ale heslo nastavil aj ked nesplnalo kriteria.
Nema to nic so selenium. Proste prides na web zmenit heslo web zahlasi ze heslo nesplna kriteria. Ides sa lognut a zistis ze tam je nove heslo. Ktore vraj nenastavil.

Pointa je ze GUI testy nemaju uplne velku vypovednu hodnotu.

Podle vašeho textu, když jsem se nad tím zamyslel, to nebyl test na reset hesla, ale test zobrazení nejaké chybové hlášky pro reset hesla, nemyslíte?

"No a kdo jiny? Kdo tam ty chyby nasekal? Uklizecka?"

Omlouvám se, vyjádřil jsem se nejasně. Myslel jsem to tak, že my, vývojáři, jsme obviňováni za to, že zákazník chce odejít. To, že sekáme chyby nijak nepopírám, problém je jiný: my vývojáři dostaneme určitý čas na implementaci a kvalita (logicky) odpovídá onomu času (tedy chybí prostor na dostatečné testování pro daný typ sw). Po té vyšší vedení sw prodává a kvalitu prezentuje na poněkud jiné úrovni, kterou zákazník tedy očekává. Jenže při setkání s realitou je (logicky) zklamán a odstupuje od smlouvy. A za to jsme pak my, vývojáři. A to je to, s čím mám problém.

Je zajímavé, že Q&A se normálně řeší i v klasickém průmyslu. Nejen v sériové výrobě, ale i při vývoji nových produktů se samozřejmě musí řešit, zda a jak moc splňují požadavky, takže to je běžná součást manažerské práce; netuším, proč si lidé myslí, že v SW to bude jinak a výrobek bude "by default" bezchybný.

Taky se často zapomíná, že kvalita je funkce mnoha proměnných a jednou z nich je i kvalita zadání...

Navíc pozor na chytáky. Pokud bude nejasný zadání, tak si zákazník vždycky najde důvod ke slevě. Třeba v věta v zadání "bude implementován TCP/IP":
- "A kde je IPv6? Nedodali jste to kompletní, je toho jenom půlka, zaplatím jenom půlku."
- "My ale nechtěli IPv6, polovinu práce jste dělali zadarmo, nikde o tom nebylo ani slovo."
A ty si, jako vývojář, vyber... Implementovat, nebo neimplementovat? :(

@Petr M
"Taky se často zapomíná, že kvalita je funkce mnoha proměnných a jednou z nich je i kvalita zadání..."

A zde hodně narážíme i na to, že zde hodně záleží i na kvalitě komunikace. Už dávno jsem se naučil, že zákazník neví co přesně chce a v podstatě to od něj ani nemůžeme chtít. Tedy vezmeme jeho zadání, nějak jej interpretujeme, z toho vygenerujeme specifikaci, kterou zákazník schválí - nebo přijde na to, že to není tak úplně ono.

Jenže toto je pěkná teorie, avšak v praxi tyto věci opět domlouvá vedení (nebo grafik -.-), kteří (logicky) pořádně ani neví, že je rozdíl, zda implementujeme IPv4, IPv6 nebo obojí.

A jestliže mi řekne šéf-programátor "máš tam null-reference exception" (tou dobou jsem dělal na dvou projektech zároveň) (to v uvozovkách je kompletní bug-report), tak jediné řešení, na které jsem přišel, je flegmatismus.

@ \neq

V předminulé práci jsme měli tým, který připravoval zadání. Já v něm měl na starost HW. Nabídka neodešla, dokud jsem neměl vypracovaný tři možnosti jak to řešit po stránce HW, odhad jejich ceny a rizik. Tam se dalo i něco dělat.

V předchozí práci šok. Se zákazníkem jednali jenom ti, co mají v titulu funkce sprostý slova na M - Markeťáci a Manažeři. Šéf s tím nebyl schopný nic udělat, jenom nám doporučil brát si 3x denně Fakitol...

No ono bývá i obráceně: vyšší vedení sw prodává a prezentuje a po té my vývojáři dostaneme určitý čas na implementaci.

Možná vyjde další série na téma "SW: Cesta do hlubin manažerovy duše" :-)

Teď nevím, jestli by z toho byl krátký článek nebo stokusová série :) Pochybuju že by rozsah padl někam doprostřed.

Myslíte to, jak zákazník odchází? Jistě, ano, vidí, jenže chyba nikdy není na jejich straně, na tom, že nedali dostatečný prostor odladit aplikaci. Ve skutečnosti je chyba v nás, vývojářích, kteří jsme práci odflákli.

Jinými slovy, myslel jsem to tak, že testování je něco, co investoři nevidí přímo, tedy vloží X hodin a vypadne z toho Y featur. Místo toho vidí, že vloží X hodin a ... nevypadne z toho nic.

Test Driven Development je fajn, ale neufinancovatelný a pomalý.

Není z tohohle pohledu lepší Development Driven Testing? Efekt stejný, princip jiný...

@Petr M

Taky to tak dělám radši, šetří to čas hlavně u nestandardních projektů ...

Len 1 detail. Istqb nie je norma a ani sa na nu nechce hrat. Je to suhrn viacerych iso (ktore aj spomina) a zamerana primarne na testovanie aplikacii. Samozrejme ma aj state venovane sw lifecycle ale primarne z pohladu kam patri testing

> Bezne som sa stretol s bankovymi aplikaciami ale aj v medicnie kde sa to uzamkne na konkretnu verziu jvm a dalsich podpornych knizniciach inak to nebude fungovat.

Ono je to logické. Tyhle aplikace potřebují mít vysokou míru spolehlivosti. Takže se pečlivě testují. Aby to testování bylo relevantní, tak provoz musí probíhat v prostředí co nejpodobnějším testům - jinak jsou testy pro kočku. Proto jsou jasně speficikovány podmínky, tedy verze knihoven, za kterých se aplikace testuje a pak provozuje.

Číslo 2 až 3 krát jsem uvedl zhruba, protože (jak bude uvedeno v dalších dílech) je kódu testů (v mém případě!!!) zhruba tolikrát více, než kódu aplikace.
Pokud se bavíme o skutečných nákladech, platí Boehmův zákon: "čím dříve se na defekt přijde, tím je její oprava levnější"
Kvantifikován je ve:
McConnell, Steve: Code Complete (2nd ed.). Microsoft Press (2004); ISBN 0-7356-1967-0
Ale to je tabulka, kterou sem nedokáži vložit. :-(
Velmi zjednodušeně řečeno - pokud defekt vznikl ve fázi kódování a přišlo se na něj ve fázi používání, pak je jeho oprava 10 až 25 krát dražší, než kdyby se na něj přišlo např. jednotkovými testy.
Ale ještě jednou zdůrazňuji - berte tento komentář jen jako velmi stručnou a nepřesnou odpověď.

Jj, výborná knížka.

Když už jsme u M$, tenhle znáte? Youtube -> EEVBLOG #1164 Krásná ukázka opravy ve chvíli, kdy už je to venku...

Zajímavé.

FYI:
Z dimenze kvality FURPS+ (Functionality, Usability, Reliability, Performance, Supportability) jsem se zabýval jen tou první částí, tj. funkcionalitou.
Další dimenze jsem netestoval.
Ale z ohlasů zde je vidět, že se jedná o nosné téma.

ony jsou to možná spíš reakce na titulek článku :-), i když těžko říct, jak chápat ty uvozovky. Obecně platí, že to, co je na klientovi, nemůžeme jako develové moc ovlivnit ani uhlídat, takže kontrola vstupu na webové části je fajn a důležitá (asi to spadá do functionality a usability), ale kontrola na straně serveru je stejně nutná, možná ještě víc.

Jedna věc totiž je, že klientovi něco nepojede, když zapíše nevalidní údaje a druhá věc leak dat nebo nějaká ještě horší akce na serveru. Ale tam je toho ještě mega víc než jen prostá kontrola vstupů, samozřejmě záleží na kontextu, právech, skupinách, možná i na analyzované historii chování uživatele (to ale asi dělá málokdo, i když bych to uvítal) a ... je toho prostě moc...

Uvozovky u "pořádně" otestovat mají právě význam relativizace. Otestovat něco stoprocentně podle všech dimenzí kvality je nadlidský úkol. Já si ani netroufám říci, že jsem to _pořádně_ (tj. bez relativizujících uvozovek) otestoval funkcionálně. Přesto ten počet potřebných testů byl pro mne značným překvapením.

Díky za zajímavý námět.

Pavle,

Neplanujete o Vasich zkusenostech s fuzzy testingem napsat clanek? Zajimalo by me treba, co by mel pekny FT nastroj umet. Pripadne nejake lehky uvod do principu a teorie FT.

+1 (text musi mit alespon 4 znaky)

Ano

pred lety jsem pracoval v projektu, kde bylo mnoho rozhranni a subsystemu a pres ta rozhrani se posilala data. Jeden kolega, matematik prosadil presne to same co rikate, kazdy transfer dat byl neustale a znova verifikovan, jedno pres kolik to slo rozhrani.

To vse je sice teoreticky tak 'spravne', ale projekt zkrachoval, protoze zakaznik nebyl ochoten platit ty vicenaklady - pri navrhu toho software u toho ten matematik totiz jeste nebyl. Pamatuji si na ty diskuze jako dnes, jak se argumentovalo, ze jak prijdou data k sevru, tak je to treba zkontrolovat, protoze kdo vi, co se cestou zmenilo. :-)

Abych byl uprimny, s lidmi jako vy zasadne nepracuji, protoze ja rad zadanou praci dokoncuji v terminu.

Alespoň nějaká kontrola na serveru by proběhnout měla.
Já to řeším tak, že u klienta je podrobná kontrola s hezkým výpisem, co je zadané špatně a jak by to mělo být správně.
Na serveru je pak její zhuštěná verze, která při nekorektním vstupu jen vrátí odpověď, že data jsou chybná (žádné detailní pitvání, protože někdo nejspíš jen odeslal data nekorektním způsobem).

takze na tom servru ta data zkontrolujete, a kdyz bude vse vporadku, tak treba cast tech dat ulozite do DB a nejaka data poslete dal. Treba k nejakemu dalsimu servru. A tam ta data samozrejme zkontrolujete, protoze by se mohlo stat, ze se cestou neco zmenilo. A tak dale, a tak dale.

Ze zkusenosti vim, ze nakonec dojdete do situace, kdy se rozhodnete tem datum proste verit. A nebude to vubec nic neprofesionalniho nebo hloupeho. Uvedomite si, ze v urcitych situacich je ta pravdepodobnost, ze se v tech jednotlivych fazich zpracovani muze neco zmenit tak miziva, ze budete ta data povazovat za spravna -> proste se spolehnete na ty predchozi kontroly.

Autor clanku nikde presne nespecifikoval, jak bude jeho aplikace vypadat. Treba bude pouzivat komponenty, ktere jsou tak chytre udelane, ze bude jen s velkou namahou mozne ta data nejakym zpusobem modifikovat. (ten priklad s tim vyvojarskym panelem v browseru). Pak je mozno na servru povazovat ta data za validni, protoze to uz nekdo zkontroloval.

Samozrejme je ten vas postup rozumny a ja netvrdim, ze kontrola dat na servru je nesmysl a ztrata casu. Vadi mi ovsem, kdyz nekdo pronasi ty vyse uvedene 'absolutni' pravdy, ze kontrolovat je potreba !VZDY!

Vstupy je třeba kontrolovat !VŽDY!, když přichází z nedůvěryhodného zdroje - třeba když je tam cvaká člověk. Smysl nemá (nemusí mít) kontrola na každém důvěryhodném článku řetězce: když posílám zkontrolovaná data ze serveru na server a to zabezpečeným kanálem, má smysl jim věřit, protože už jednou zkontrolována byla.

Cokoliv z prohlížeče/elec­tronu je třeba považovat za nedůvěryhodné a na serveru to zkontrolovat a případně nepustit dál, právě proto, aby takové požadavky nemohly nakazit ty části systému, které kontroly neprovádí. Nemusí to být žádná krása: "chyba v poli X - končím".

@honza

Jasně že je potřeba kontrlolovat vždy. Minimálně vůči uřité technologii, která má něco někam posunout odněkud někam. V tvém příkladu, když tedy obecném tak tedy obecně, zkotroluješ na frontendu to co zajímá uživatele (např. věk musí být int), zkontroluješ různé další druhy chyb a ůtoků na frontend, odešleš např. json na server a tam zkontroluješ co to má obsahovat a jak to má vypadat, co máš uložit ošetříš pro uložení, co máš přeposlat ošetříš pro přeposlání. Ano, není to tak jednoduché jako to prostě někam vrazit, protože už to kontroloval někdo jiný někde jinde ...

Re: honza (neregistrovaný) ---.dip0.t-ipconnect.de

Máte pravdu. Ta hranice, kdy už datům věřím, ale není jedna. Pro každý údaj je jiná. Je dána spíš tím, kde ještě se dá něco ověřit. Takže třebas to, zda zákazník existuje, se dá ověřovat až do úplného konce pomocí integritních omezení. Zda je částka v nějakém intervalu se také dá, byť tohle se moc nedělá. Ale třebas zda zákazník má dostatečný kredit na danou transkci, to už ověřit nejde a tam se vskutku musíte spolehnout na to, že to ověřil někdo výš. Už proto, že vlastně vůbec nemáte tušení o tom, co účtujete - je to prodej, storno, vratka, dobití kreditu, vratka zálohy, kurzový rozdíl, nebo co to vlastně je? Podobně při zápisu do hlavní knihy - úplně na konci je něco, co zapisuje řádek do účetnictví. A tohle něco se musí spolehnout na to, že ten, kdo to zavolal, to zavolá i podruhé a udělá tak správně zápis do podvojného účetnictví.

Tady ale někteří diskutují budou nesouhlasit. Bude to záležet na tom, kde oni mají nakreslené čáry a co považují za jeden celek. Já vyrostl na třívrstvé architektuře. Takže od databáze čekám jen integritní omezení. Kontrolu smysluplnosti dat pak očekávám od aplikačního serveru. V takové architektuře máte pravdu - databázový server věří tomu, že aplikační server již vše zkontroloval. Databáze sama nezná logiku aplikace, takže většinu kontrol ani nemá jak provést.

Zda s tvrzením "některé kontroly se nedají provádět až do konce a proto se na konci velké části dat musí věřit" bude konkrétní člověk souhlasit pak záleží na tom, zda vidí jen hranici mezi "klient" a "aplikační server", nebo zda vidí těch hranic víc, například právě tu mezi RDBMS a aplikačním serverem. Ti, co hranici databáze - aplikační server nevidí, vám těžko přiznají, že na téhle hranici už řadě věcí prostě věřit musíte.

K tomu jedna důležitá, ale obvykle zcela přehlížená věc: pokud chci, aby databáze mohla věřit datům z aplikačního serveru, tak si musím být jistý tím, s kým si povídám. Takže v databázi několik uživatelů, každý s pořádným heslem a velmi přesně omezenými přístupovými právy. Aplikační server prostě nemá důvod mít práva vytvářet nebo rušit tabulky, do řady tabulek není ani důvod aby měl práva DELETE. Pokud se do databáze hrabe více aplikací, tak každá má vlastního uživatele a vlastní práva. Docházka nemá co hrabat do kusovníků nebo si číst v účetnictví. Pokud chci mít jo jistotu, tak postavím čtvrtou vrstvu z vložených procedur přímo v databázi, která mi aspoň ty nejdůležitější věci typu změny hesla nebo plánování úloh ohlídá. Porovnejte to s typickou MySQL + PHP aplikací, kde je jediný uživatel, který má právo na úplně cokoliv.

> Abych byl uprimny, s lidmi jako vy zasadne nepracuji, protoze ja rad zadanou praci dokoncuji v terminu.

A to včetně SQL injekce v <input type="number">, prže tam určitě nic jiného než číslo nepřijde.

Ja zase zasadne nepracuji s lidmi vaseho typu. Je krasne mit super komponenty v javascriptu, ktere uzivateli nedovoli zadat nevalidni data, ale vtip je v tom, ze zdrojem dat nemusi vubec byt webovy js klient. Muze to byt curl bot, api klient, hacker s telnetem, atd. To je uplne jedno. Funkcni backendovy celek proste musi resit validace svych vstupu. Spravny pristup je publikovat webove sluzby a pak je vam lhostejno, jestli k nim pristupuje webovy js klient, api klient, atd. O vice naklady se zpravidla nejedna. Naopak prinosem je lepsi skalovatelnost, testovatelnost a moznost prave vice klientu: zakaznicke api, webovy klient, mobilni aplikace, atd.

A ještě vtipnější je, když autor těch komponent je někdo, kdo vůbec neřeší kontrolu výstupu - však on si to server přebere... Pak vyjde nějaké aktualizace a místo pár mailů typu "nejde vybrat větší náhledy obrázků" řešíš obnovu rozdrbané databáze na backendu.

No já jsem to pochopil. Ale když vidím, jak lidi čím dál tím víc k*rví češtinu a jsou tak cool, že si v každé třetí větě nedokážou vzpomenout na běžné české sloveso (mmm a jak se to řekne česky, aha "obohatit") a namísto "domluvit" si lámou jazyk pitomostmi typu "vykomunikovat", přijde mi snaha tu češtinu kultivovat a hájit jako sympatická a ne směšná. Té tvojí "směšné větě" jsem bez problémů porozuměl (jo a neříkám "kryptovat", nýbrž "šifrovat").

@Seamonker
Odpověď na otázku - nemám za sebou žádnou praxi. Jsem z akademické sféry, což lze vyčíst i z informací zveřejněných současně s článkem.
Důvod uvedení odkazu na slovník CaSTB jsem nepochopil. CaSTB se mj. snaží o zavedení a sjednocení české terminologie. Nemyslím si, že je na používání české terminologie něco špatného a už vůbec ne na snahách o její sjednocení.
Myslím si, že nemá cenu v tomto vláknu pokračovat, společnou řeč asi nenalezneme, takže navrhuji si nekazit vzájemně náladu ;-)

@Seamonker

Tím že za sebou nemáš praxi bych se vůbec netrápil - někdy je to dokonce výhoda, protože opravit léta prakticky pěstovanou apatii k různému patlání jde velmi těžko ....

Divej, rozdil mezi akademickou teorii a praxi je casto dost velkej, podle me delas akorat medvedi sluzbu sobe a zacatecnikum s prekladem terminu, ktery se v praxi proste nepouzivaji (at si jakakoliv komise mysli co chce).

Samozrejme pokud nestojis o komenty z praxe, tak se pod dalsima dilama budu drzet zpet.

PS - ten slovnik obsahuje vyrazy jako "firemní dashboard", "komise pro management
defektů" nebo "management testovacích dat" dal pro jistotu uz nic nepisu.

Asi je ta praxe širší než si myslíš, ale u mě člověk používající české termity na pohovoru za debila nebude. Vybíráme si lidi podle jiných kritérií. :-)

Existence a znalost českých termínů přece nijak nevylučuje, ba ani nenahrazuje, potřebu znalosti těch anglických.

@Jakub Daněk

Nevylučuje, ale mohlo by to ukazovat na sklony věci zbytečně komplikovat. Prostě jenom další vrstva něčeho k ničemu ..... IMO jsem zvědavý kdy dojde na latinu až už nebude počešťování obrozencům stačit :-)

Re: Jakub Daněk (neregistrovaný) ---.net.upcbroad­band.cz

Já se občas setkal s tím, že české termity naopak vymýšlely pracovnice z personálního a za debila měly uchazeče, který jim nerozumněl. Že se k tomu schyluje se poznalo tak, že holky kupříkladu začaly vyzvídat, co že vlastně MRB dělá a jak se "Material Review Board" řekne česky. Tuším že se tehdy dobraly k něčemu jako "tabule kontroly materiálu". Každopádně ten termit pak použily v inzerátu i při pohovorech. A samozřejmě stylem "Máte nějaké zkušenosti s tabulí kontroly materiálu? Ne? Hmm, body dolů."