Heisenbug версия 1

Може ли първото пускане на продукт да бъде достатъчно добре тествано или неизбежно ще срещнете куп неравности, които вече са в производството? Конференцията за тестване наHeisenbug, която наскоро проведохме в Москва, се проведе за първи път, така че беше възможно да се види добър пример за това. Как отиде тя? Имало ли е проблеми? И как трябва да изглежда една конференция за тестване, ако вътре в нея има подвидове с напълно различни специфики и с нея се занимават специалисти от различни профили?

Откриващата бележка беше изсвирена отИлари Хенрик Егертер- притежателят на такава брада, че хората чуруликат "на живо тя е три пъти по-впечатляваща". С предупреждението „Аз съм консултант и мениджър, така че се съмнявам във всичко, което казвам“, той започна да изразява мисли, които наистина могат да предизвикат възражения. Например, че разделението на ръчно и автоматизирано тестване е пресилено, защото „и в двата случая не са важни ръцете, а мозъкът“. И това TDD изобщо не може да се счита за пълноценно тестване, "защото законът за необходимото разнообразие изисква повече разнообразие от управляващата система, отколкото от контролираната."

Призовавайки „да не се опитваме да автоматизираме всичко изобщо“, Илари придружи това с визуален експеримент, тествайки тестери. Той предложи съвместно съставяне на списък с критерии за тестване на "2 + 2" на калкулатор. От публиката те посочиха много неща, на които си струва да се обърне внимание - например интервалите между натисканията. Когато опциите изсъхнаха, Илари продължи: „Добре, помислихте за условията, при които устройството може да не извърши желаното действие. Но какво ще стане, ако това прави нещо повече от него? Какво ще стане, ако освен четворката покаже още нещо? Ако погледнемекран, веднага ще забележим, че нещо не е наред. Но е трудно да се направят пълни критерии за автоматизирано определяне на всичко това, има много неизвестни неизвестни.

Той завърши речта си не по-малко категорично: с думите „не се смятайте за носители на истината, поддържайте ниво на съмнение в себе си“.

Dan Couillard, разработчик на Appium, наскоро ни говори в интервю за своето въображение и за мобилното тестване като цяло. Докладът беше приблизително същият, но много по-подробен: „На iOS изскачащо предупреждение за „фишинг сайт“ може да попречи на тестването и няма смисъл да плащате за сертификат само за тестване. В такива случаи това предупреждение може да бъде заобиколено с safariIgnoreFraudWarning." Краят на репортажа също се оказа гръмък: „Вярвайте в себе си. Сигурен съм, че можете да се справите по-добре от Appium. Само защото SpaceX поставя ракета на шлеп, това не означава, че разбират нещо!"

Докладът наIgor khroliz Khrol(Toptal) за автоматизираните тестове беше може би най-илюстративният: на огромен екран в реално време той демонстрира кода на един след друг тестове, написани на Ruby, изпълнява ги и записва изпълнението в отделна таблица. Всеки следващ тест се оказа по-продуктивен от предишния, правейки колоната „колко такива теста могат да се изпълнят за пет минути“ все по-впечатляваща.

МеждувременноВладимир владимирситников Ситников(Netcracker) анализира тънкостите на тестването на натоварване, използвайки отличния инструмент JMeter, известен му като пример. Например, ако „заявките веднъж на минута“ се окажат строго в началото на минутата, в това няма нищо добро, картината не е представителна. От друга страна, ако просто вземете и рандомизирате времето, тогава не е ясно как след това правилно да сравните измерванията едно с друго- условията им явно са различни. Освен това, ако честотата е зададена на „100 заявки на час“ и тестът се изпълнява за половин час, искам да означава „50 за половин час“, но произволното не обещава това. Какво да правим с тази трудна ситуация? Според Владимир, за да създадете свой собствен правилен велосипед - и той направи точно това, като написа таймер за JMeter. Този таймер създава разпределение на Поасон на базата на произволно начално число (така че едни и същи произволни закъснения могат да се повтарят), а също така има параметър за продължителност на теста, който ви позволява да получите "плосък половин час".

Краят на доклада и в този случай се оказа запомнящ се - имаше списък „защо рандомизиране? 5 "U", а петото "U" веднага се запечата в паметта ми:

Подобрява покритието
Намалява броя на необходимите тестове
Опростява кода (подготвя ненужни данни)
Опростява развитието като цяло (утилитарни задачи)
Преподава инструменти, инфраструктура (unicode)

Докладът наФилип Кексбеше много различен от другите: той говори за такава екстремна тема като автоматизацията на тестването на игри (за която той писа в публикация в блог по-рано) и призова да не се страхувате да създадете свои собствени инструменти за това. В този процес Keks демонстрира с помощта на кодиране на живо как Creative Mobile тества своето NitroNation mobile drag racing (повече от 10 милиона инсталации в Google Play). И в същото време той показа снимка на сървъра Cthulhu, работещ надстройки на редица свързани мобилни устройства - сървърът получи името си заради това как изглежда всичко заедно. Всичко това толкова впечатли публиката, че почти първият въпрос от публиката след репортажа беше „Имате ли свободни места“.

Jan Jaap Cannegieter започна шоутос думите „трудно ти е да произнасяш името ми правилно, но няма страшно, твоето също ми е трудно“ (затова за всеки случай ще го оставим на латиница). За разлика от Илари, той не предложи да се премахне разделението на ръчно и автоматизирано тестване, но в същото време се съгласи, че основният използван инструмент е мозъкът. И за да демонстрира това, той започна да тества сайта на самия Heisenbug на сцената: „Нека вземем инструмента за обхождане на уебсайтове и анализираме сайта с него. Той съобщава за редица грешки - но сега се нуждае от човек, който да разбере къде всъщност са грешките. Нека последваме тази връзка - всичко изглежда наред с нея, въпреки че не разбирам какво е. И ето го истинският 404. Ура, намерих грешка!

Като цяло е полезно да организирате конференции за тестване: в същото време говорителите ще тестват всичко вместо вас.

И накрая,Rex Blackимаше заключителната бележка — толкова значима фигура в света на тестването, че на конференцията някои хора си направиха селфита с него. „Аз съм от Тексас - може би сте очаквали да носите каубойска шапка? Имаме израз „само шапка и без добитък“ за тези, които се обличат като каубой, без да са такива. Не искам да съм само с шапки и без добитък, така че не нося шапка."

В основната си бележка за това как да се избегнат грешки при използването на показатели имаше интересен пример с ефекта на Хоторн: понякога самият факт на измерване на нещо влияе върху това, което се измерва, което затруднява получаването на правилна представа за ситуацията. Това любопитно повтори името на конференцията: „Heisenbug“ е грешка, която изчезва или променя свойствата си, когато се опитате да я намерите.

По време на същата заключителна бележка, онлайн излъчването беше прекъснато за известно време, така че конференцията за борбата с грешките не беше лишена от своя малък „бъг“. Това обаче се превърна в най-сериозния проблем зацял ден - опитът от провеждането на конференции по други теми помогна. Оказва се, че има ситуация, когато за първи път е напълно възможно да се справите без мащабни проблеми: в случай, че вече сте се сдобили с подобен.

Въпросът „каква трябва да бъде конференцията за такова многостранно явление като тестването“ също намери своя логичен отговор: тя също трябва да бъде многостранна. Доклади за нюансите на конкретен продукт и доклади за всички дейности като цяло, доклад за разпределени системи, базиран на опита на Yandex и доклад за игри, базиран на опита на най-популярното приложение, доклади с код и доклади с общи разсъждения - и в крайна сметка, съдейки по обратната връзка, както тестерите, така и разработчиците успяха да се възползват за себе си.

В резултат на конференцията подкастът на Radio QA пусна издание за Heisenbug с членове на програмния комитет. А първите 5 доклада на конференцията, според публиката, се оказаха следните:

Филип Кекс (Creative Mobile) - Как да научим роботите да играят игри?
Александър Баяндин (Badoo) - Jailbreak на ChromeDriver
Дан Куейлард - Appium - Appium: Автоматизация за приложения
Станислав Башкирцев (EPAM) - Рандомизирано тестване
Владимир Ситников (Netcracker) — Клопки при тестване на натоварване