Tag: quality assurance

Студенти, стаж и работа

Миналата седмица изнесохме две лекции респективно в Икономически Университет и Технически Университет във Варна.

Поговорихме доста за компанията, за условията, но най-важното бяха въпросите. Ще се постарая отговорите да са универсални, защото така или иначе статията не е с рекламна цел.

 

Колко опит трябва да имам за да започна стаж?

За започването на стаж обикновено компаниите търсят студенти (или ученици), които имат интерес в сферата, но професионалния опит не е задължително изискване. Ако ви е интересно и сте правили задачки във вас или в университета и имате някакъв фундамент значи сте готови да се гмурнете в занаята.

Колко време ще съм стажант?

Обикновено стажовете продължават между 3 и 6 месеца (така е в Немечек например), като след като приключи предварително уговорения срок изборите са два:

  • Започване на Junior позиция в компанията:
    • Очакванията към вас са оправдани и двете страни са доволни. Следват промяна на възнаграджението (което трябва да е упоменато в договора ви още като започвате стажа си) и други придобивки (ваучери, втори монитор или каквото друго предлага компанията). Освен това четири други неща ще се променят:
      • Задачите ви ще станат по-отговорни и шанса да имате парче код, което ще работи при клиент е много вероятно. Вашите ментори вече няма да са с вас на всяка крачка, но ще продължат да бъдат на разположение. Тогава трябва и смяна на начина на комуникация – въпросите да са по-малко, по-структурирани и да сте се подготвили сериозно преди да ги зададете;
      • Вероятно ще имате втори изпитателен срок – това също е честа практика и отнема време. Не бъдете нетърпеливи, защото за няколко месеца/година ще влезете в бранша и оттам всичко остава във вашите ръце;
      • Бъдете самоинициативни – ако някой процес не ви хареса или имате идеи за развитие, курсове, споделяне на добри практики или каквото и да е било друго не се срамувайте, а говорете с вашия Team lead.
      • Бъдете готови да помагате на другите около вас без значение от това дали не са от 20 години в бранша или са стажанти. Бранша ни е толкова мащабен, че всеки може да даде ценна троха знания на всеки около него.
  • Прекратяване на Стажа ако една от страните не е доволна от другата:
    • Ако не се харесате с компанията в която работите и решите да я сменяте, го направете по възможно най-коректния начин. Това е първата ви компания и е важно да се разделите в добри отношения (без значение дали са били добри с вас или са били абсолютните задници). Пък и не е рядка практика HR-ките да звънят на предни фирми, в които сте работили за да разпитат;
    • Ако сте доволни от компанията, но не и от заплащането винаги можете да договорите. Съвет от мен е при преговори да се подготвите предварително с план в краткосрочна и дългосрочна перспектива. Това включва подобряване на hard skills (например ученето на нова технология) и по-трудното – работа по някой soft skill (комуникация, работа с екипа и т.н.);
    • Ако са ви пръснали от работа и това е причината да напуснете – тогава expectations management-а и на двете страни не е сработил добре. За това в началото при даването на задачите ако усетите, че има вероятност да не се справите разпитайте, прочетете повече и преговаряйте. Ще се учудите колко отворени са хората. И е нормално да не дадете супер точен estimation. Това идва с опита.

Колко време ще ми е нужно да стана Mid и Senior?

 

Всяка компания има политика за определяне на това кой в какъв seniority level e. За да придобиете представа ще дефинирам четирите основни нива:

  • Intern (стажант) – често млад и надъхан студент или ученик, но може да е човек, който сменя бранша. Обикновено има човек, който се грижи за него – ментор, който му дава задачи, оценява го как се справя и т.н. Очакванията към него са да е нахъсан и да му се учи, да се адаптира бързо към средата и да му е интересно;
  • Junior – стъпка над стажанта, вече може да се чувства, че опита му започва да става професионален. Задава си въпроси, които като стажант не е можел да си отговори ясно (например накъде да копае – frontend или backend, някоя конкретна технология или каквото се сетите). Задълженията му нарастват и вече има задачки за него, които не са тренировъчни, а реални. Трябва да можете да комуникирате ясно и стегнато и да знаете на кого да зададете въпросите си. Очаква се от вас ако имате мнение по някой въпрос касаещ кода, проекта или процесите да ги обсъдите с вашия Team Lead. Очакванията са да си задържите и засилите интереса към това, което правите и да се стремите да сте по-добри;
  • Mid – вероятно най-често срещаната позиция в бранша. Това са хора с изграден вече професионален опит, които имат добър фундамент, справят се с много голяма част от задачите, които има за правене по проекта. Те могат да виждат голямата картинка, да разбират бизнеса и да работят самостоятелно. Не е рядкост към Mid (програмист, QA, PM, изберете си сами) да закачат някой стажант или junior като човек за помощ и подкрепа, а понякога и направо като ментор. Очакванията са да са самоинициативни и самодостатъчни, да комуникират с лекота с всички членове на екипа и да знаят как работят нещата отдолу, да могат да се справят със заплетени проблеми и както обичам да казвам – да са настъпвали възможно най-много мотики за да знаят какво и къде да правят;
  • Senior – освен солидната техническа грамотност трбява да са мотивиращи и лидери (не е задължилно да са lead-ове), да могат да помагат на другите, да дърпат проектите напред и да бъдат хората, които като някой има въпрос да са там и да имат желание да помагат. Тези хора Виктор ги нарича oracles. Освен това дълбокото разбиране на проблемите и ясната позиция при решаването им са много важни. Комуникация с клиенти също е често срещано. И накрая, но не на последно място senior хората трябва да са израснали вътрешно – да са спокойни и да знаят как да приоритизират.

Както виждате за всички позиции човек трябва да е надъхан, да му е интересно и да рови. Ако нямате подходящия attitude сте обречени на вечно мънкане и бърз бърнаут.

Какво трябва да мога и какво ще науча освен техническата част?

Понеже обичам bullet points:

  • Трябва да се научите да комуникирате с хора – да сте спокойни и да задавате правилните въпроси, да можете да говорите с лекота както с програмистите, с вашия team lead и ако щете със CTO-то ви. Задаването на правилните въпроси носи удовлетворение и ефективност и в двете страни, но значи и че трябва да се научите да си структурирате въпросите правилно както и да четете предварително преди да задавате такива;
  • Научете се да … учите – в нашия свят много често се налага да навлезем много бързо в някоя непозната за нас технология и това е напълно нормално. И виждам как хора научават в движение Go или React и се справят отлично. Тайната е това, че тези хора имат стабилен фудамент на който да стъпят и разбират и методика на учене;
  • Да се стремите да виждате голямата картинка. Януари тази година бяхме с екипа в САЩ и там се срещнахме с нашия CEO и съответно имахме време да си поговорим на дълго и на широко. Още от първото изречение видях, че моя и неговия мироглед са толкова различни, че чак е стряскащо. Той гледа с няколко години напред, усеща кога идва нещо голямо и каква е голямата картинка. Аз към този момент (в аспекта на текущия ни проект) се грижих за абсолютно микроиоскопичните детайли. Такива разговори действат отрезвяващо и карат човек да се замисли за това;
  • Да се научите да вършите работата си по определен начин. Както във всеки проект текат различни процеси, които го държат стегнат и праволинеен така и вашата работа трябва да се основава на нещо подобно.  Всеки обича чистото и подредено бюро, но не всеки се замисля дали е проблем това, че работим едновременно по 6 различни задачи и имаме 145 отворени таба на браузъра.
  • Работа в екип – в идеалния случай екипът се събира като части от пъзел – лесно и безпрепятствено. Понякога обаче е все едно сте призовали 8 демона, които се бият с лопати през няколко минути. Без значение от коя страна сте работата с хората във вашия екип трябва да е първо на професиоанлно ниво и да оставите на заден план личните ангажименти. Защото ако в пъзела има една част, която не пасва тя обикновено бива изхвърлена. И е признак на зрялост желанието за подобряване на отношенията в екипа;
  • Да държите на критика. Ако сте програмист ще има цял екип от малки демони, които ще тестват вашата работа и ще логват къде адекватни, къде не проблеми, ще има колеги, които няма да харесат вашия pull request и ще пишат коментари, много коментари. И ще изглежда, че всичкие са гъзове и че не ви харесват и че изглежда, че ви казват, че за вас ще е по-добре да пасете овце/крави на село, но това не е така. Всеки в един работещ екип има една основна цел – проекта да върви напред. А за да върви напред качеството на работа на всеки един от екипа трябва да е на високо ниво. Не забравяйте, че качеството и ефективността на всеки екип е равно на този с най-малко опит;
  • Бъдете пич (пич е state of mind, а не полово определение, моля, моля!) – когато човек е пич нещата вървят по-лесно. Дребнавостта, нуждата за внимание на всяка цена и всякакви малки злободневни неща могат само да подразнят колектива.

 

И пак си бях обещал да не правя 100 страници пост и пак не ми се получи :)
Надявам се да съм бил полезен. Ако имате въпроси ги задавайте под статията в секцията за коментари.

 

P.S. Споделям с вас страхотния материал на WaitButWhy.com – How to Pick a Career (That Actually Fits You). Отделете му време, съветите са брилиантни.

02.04.2018

Целия уикенд мина в почивка, разходка до Балчик за по една супа и да ни навали дъжда и четене.

In other news, освен, че се подготвям за QA: Challenge Accepted 4.0:

Равносметката 2017

Мина още една година. И по навик казвам нещата, които не съм направил първо, защото са по-важни.

  • Не водих лекции в Социалната Чайна. Преди няколко месеца излязоха открито и казаха, че парите им не стигат. Тогава се свързах с тях и говорихме да водя лекции в тяхната зала, а приходите (всеки плаща колкото реши) да отиват в Чайната. По същото време смених работата и реших да забавя нещата за да мога да се концентрирам върху нея;
  • Почти не снимах. За поредна година;
  • Почти не танцувах;
    • Нямам нито едно представление за годината.
  • Не говорих на TEDx. Темите ми щяха да бъдат свързани с депресията или Quality Assurance in real live;
  • Не говорих на WordCamp Varna 2017. Предложените ми теми бяха за security и performance testing. Не ги одобриха;
  • Почти не свирих;
  • Не карах колелото точно колкото исках. За това вече писах;
  • Не четох толкова, колкото исках;
  • Не писах толкова, колкото исках.

 

Нещата, които се случиха:

  • Започнах нова работа. За момента това е най-доброто място в което съм работил в съотношение колеги/проект/условия. Компанията е Немечек;
  • Направих моето Голямо Каране. До половината. Три дни интензивно каране и общо 264 км, спане в колата, катерене на връх Ботев, ядене на малини и ягоди на средата на нищото;
  • Случи се това. И близките ми за здрави и повечето дори са щастливи. Повече не мога да искам. Дори и котката Иво е жив и здрав (и дебел);
  • Изкарах 2 дуатлна (Злати се включи във втория и го изкара също), на единия дори и завърших в контролното време. Имам си и медал!
  • Пътувахме със Злати много. Обикаляхме из България, а тази година направихме и няколко пъти Варна-София-Варна със самолет;
  • Изкачихме връх Ботев за ден и спечелих от габровец 10-тина бири;
  • Говорих в WordPress meetup Varna за “Security of WordPress”. Получи се много добре;
  • Говорих и в “ИТ Форум” в Технически Университет Варна. Там организацията беше зле, след като си написах лекцията после 5 (!!) човека от предната фирма в която работих я редакритаха, рязаха, добавяха, осакатяваха докато не стана една страхотно скучна лекция типична за скучно-университетските и/или корпоративни среди. И имаше 10 човека (заедно с лекторите);
  • Говорих във “Вечер на таланта” за моето Голямо каране. Беше интересно, даже има и видео как фъфля;
  • Говорих в “EU Code Week Varna 2017” – беше най-класното и посещаемо събитие провело се в зала “Black Sea Hall” на хотел “Черно Море”;
  • Месец по-късно говорих в “Zara Code Week 2017” поканен от Венко Добрев. Беше най-сърцатото събитие, срещнах ценни хора, имаше крайно черен хумор вечерта преди моята лекция, заразих се от ентусиазма на Орлин. Абе беше страхотно преживяване;
  • Започнах да се заигравам с микроконтролери. За момента съм загърбил Raspberry Pi-то и си играя с ESP8266 (контролер с 80 Mhz процесор, micro USB захранване, вграден WiFi, I2C, etc.), DH11 (датчик за температура, влажност и атмосферно налягане), BSP280 (като DH11, но много по-точен и производство на Bosch) и голямата ми гордост – SDS011 (датчик за твърди частици). Като сглобя всичко това ще се включа в Air Bulgaria да следим в колко мръсен въздух живеем;
  • marvin е още жив. Покрай него научих супер много за системната администрация и как работи отдолу nginx. Нико, Владо – благодаря за помощта, която ми дадохте през времето когато го омазвах солидно;
  • Тръгнах да чета Хари Потър, до момента съм към края на петата част – “Хари Потър и Ордена на Фениска”. Четох и Бакман, Весела Тотева и Агата Кристи. Следващата година ще дочета Потъра и после – Глуховски. И повече от 9 книги за годината(срам, срам…);
  • Отидохме на Hills Of Rock, счупихме главите и си изкарахме потресаващо добре.

  • Не мога да повярвам колко дълга ми стана косата.

Нещата, които ще ми се случат:

  • Да направя каквото мога за Чайната;
  • Да правя хората по-добри. Винаги съм вярвал в споделянето на знания и ще продължавам да го правя докато мога;
  • Да чета приказки в дома за деца лишени от родителски грижи;
  • Да се случи моето Голямото каране 2 – този път 500+ км за седмица, вероятно пак сам;
  • Силна бреветна година – 200км, 300км (евентуално 200+300 във Варненски бреветен уикенд) и ако успея да вляза във форма – и един 600 км (400 е за ден, а 600 има време човек да поспи 2-3 часа за това казват и че е по-възможен);
  • Дунав Ултра – много се надявам да успея да участвам и да финиширам в контролното време;
  • Да изкарам първия си мартон.

 

Нещата, които заболяха:

30.11.2017

Днес цял ден ми е едно ей такова:

 

И после ей такова:

 

Пуснах пост 200, после и малко писание около Zara Code Week 2017, смених галерията (най-накрая) с нещо по-адекватно и за последно – вече всеки нов пост ще бъде пускан автоматично и в twitter акаунта ми.

 

Александър Тодоров сподели и едно видео на Claudiu Draghia, изглежда полезно:

Мина Zara Code Week 2017

Мина втория ми за годината Code Week този път в Стара Загора само няколко седмици след Code Week Varna 2017.

Бях поканен от Венко Добрев, който е от ония суперактивни хора, които искат да правят света около себе си по-добър и не мрънкат, а действат.  И понеже е и скромен ще опиша аз с какво се занимава – беше управител на Beehive за година и половина, два пъти е организирал Code Week Варна (като веднъж бях сред лекторите там), два пъти в Стара Загора, два Startup Weekend-а, бил е един от организаторите на TEDxStaraZagora, помага на брутално якия coworking space ZaraLab (Венко, ако четеш това прати малко снимки да покажем на хората колко яко е местенцето). Освен това започна нова образователна инициатива за мотивация на ученици и отделно младежи в неравностойно положение – “Аз и моят успех”. Опита се да направи нещата по-добри като работеше в община Стара Загора като младши специалист в отдел спорт, туризъм и младежки дейности и беше част от екипа писал кандидатурата за Европейски град на спорта 2017, която градът спечели. Сега работи като експерт в Агенция за регионално икономическо развитие – Стара Загора по два международни проекта с колегите – единият за иновации в МСП в селските райони, а другият за зелени обществени поръчки. Сигурно има и други неща, които пропускам.

Та – той беше една от причините да пропътуваме 300 км. Другата бяха останалите лектори, които бяха епични копелета, а на трето, но изобщо не на последно място – хората, които щяхме да срещнем там.

Тръгнахме в Събота, 21 Октомври от Варна и за съжление изтървахме откриването и голяма част от лекцията на Петър ПетровAndroid between Java and Kotlin“. Това, което видях беше интересно и сигурно много практично за Android devs. Лекцията беше много chill, както и повечето от лекциите от двата дни. За Пешо хубаво или нищо! Дори вече не помня от къде се познаваме, но като го представям на някого обикновено споменавам, че първо се е научил да свири на гъдулка (ей, винаги съм си мислил, че е гайда, деба!) и после да програмира.

Последва може би най-епичната лекция от събитието с най-епичния лектор – Oрлин Димитров, който тръгна да говори за “Свързаност на елементите на роботизираните системи“, но след десетата минута и зададени 5 въпроса смени темата и изкара на freestyle почти два часа пълни с хардуер и софтуер и хумор, а в края залата беше залята от мощната вълна ентусиазъм, която Орлин хвърля винаги, когато говори пред хора. Той е и един от виновниците да се запаля по микроконтролите последните седмици. (Орлине – ти ще отговаряш пред Златина защо съм си дал половината заплата за контролери!)

Последва почивка и след това дойде темата на Яна Славчева за чат ботовете, която не слушах много, защото си подготвях моята лекция и среда за изпълняването на тестовете. Тук нямам какво повече да напиша.

ИТ-ПОП-ИДОЛА Михаил Дучев известен сред своите приятели, колеги и врагове като Дучев, още по-известен като грамар-нацито на Интернета, бъг хънтъра на себеподобни, човека, който чупи всичко по пътя си и т.н. и т.н. Та той говори за Xamarin като се посмяхме, показа някои интересни неща и беше достойно (Дучев за 3 минути намери eastern-egg-а, браво :D) закриване на първия ден на Zara Code Week 2017.
Останахме да спим в Митака (Митак №2 всъщност), а преди това се събрахме на бърза и културна вечеря на местна кръчма (на която забравих името). Та там салатите бяха два типа – от 500 и от 1000 гр. Със Златина успяхме да смачкаме една 500 грамова с малко зор.
След като се правихме на културни за около 12 минути някой започна с първия виц и така до полунощ минахме от тъпи вицове, които всеки знае до най-дълбоките дебри на черния хумор. Беше абсолютно епично и още повече да говориш с такива хора, които имат толкова много неща да споделят (и хумора е само малка част от тях).

Прибрахме се и легнахме. На следващия ден аз бях с откриващата лекция.

Станахме в 7 и към 8:00 се замъкнахме в бизнес сградата в която щеше да се проведе събитието. Поръчахме по едно кафе и направих финални щрихи (тоест си донаписах презентацията :D) на презентацията (баси тъпото повторение), хората започнаха да се нижат един по един и в 10:30-10:40 излязох да говоря аз.

Минах набързо през основните неща, които казвам на лекциите си и се насочих към темата за сигурност. Разказах в известни детайли как да направим анализ на някакъв уеб ресурс, който в случая беше моя блог (не ми се искаше пак да чупим общинско/държавно on the fly), разказах за DVWA и накрая пуснах един dictionary attack към блога ми. Разказах малко за Google Dorks, a накрая имаше и малко performance testing с jMeter, за който не остана много време, че вече бях направил почти два часа.

Имаше доста дискусии и въпроси и се получи много cool цялата работа. Дори май бях и полезен.

След мен излезе Димитър Костов за да говори за Mobile scaffolding. Лекцията беше супер полезна и интересна, разказа доста неща и най-накрая научих какво е scaffolding. Също така беше и единствения лектор, който излезе и започна да говори за това, което прави от самото начало така, че да бъде разбран добре и от хора, които нямат никакъв опит в бранша. Получи се добра лекция.
Решихме след него да си ходим със Злати, но се оказа, че Митака и Тошко са към Варна и останахме за предпоследната лекция на Тодор Янков – “Интро в JavaScript”. Презентацията му беше web based с интеграции и най-вече – code snippet editor директно в нея.

Разказа ни за JS, react и направи един съвсем лек проект (взимаше JSON данни от weather provider и ги показваше на екрана). Имаше и супер много въпроси, дискусии и показа завидни познания по linux/zsh/vim.
Тръгнахме като ми беше терсене, че няма да чуем последната лекция на нашия домакин – Димитър Стефанов, който е backend developer в Big Mustache Game говори за “Grimm side of programming”. Самия той се занимава от безброй много години със C# .NET и MSSQL и разказа за C#, релационните база данни и концепцията клиент/сървър (това ми беше преразказано от Венко като каза, че лекцията е била доста добра).

 

Снимки – скоро.

ISTA 2017 live blogging day 1

ISTA 2017 ден първи

 

“Innovate, automate, accelerate” – Birger Thorburn CTO на Experian

Доста интересна и надъхваща реч относно бързото развитие на Expirian, която се занимава и с data analysis, няколко огромни цифри и ме накара пак да се замисля за сигурността ни онлайн. Това беше един страхотен пример как се води презентация пред хора – много добър начин на изразяване, слайда с данните беше представен по правилния начин (а не да се изчете всичко дословно), посланието от презентацията стигна до (повечето от) нас.

 

“The new leaders of quality” – Lyudmila Labova from Paysafe

Людмила говори за качеството, за quality measurements, non-measurable quality и best practices, говори доста за компанията в която работи. Споменава за това, че използват SonarQube. Като цяло лекцията е много основна и не научих много нови неща от нея.

И формулата за успеха на PaySafe е: V x D x F > R (Vision x Discomfort x First steps x Resistance). Ако това ви свърши работа намерете Любмила и я черпете едно.

 

Лекцията приключи 20 минути по-рано и имах време да вляза към края на:

“Security, Big Data and other challenges to the IoT” – Martin Harizanov от Visteon

Мартин Харизанов ни говори за сигурността в IoT и разказва за векторите на атака (които по дефиниция са почти същите както и на други real-world системи) като brute force, DDoS, после за превенция – client/server/OS updates, FOTA (firmware-over-the-air), monitoring и т.н. Накрая пак ни напомни, че абсолютно сигурни системи няма (може би освен тези, които са offline?). След това поговори за Big Data в IoT. Каза, че CISCO са излезли с доклад, че до 2020 година ще има около 20 милиарда неща (игра на думи от internet of things). Forbes пък са предвидили, че IoT трафика ще достигне 600 ZB (600 трилиона гигабайта) през 2020.

Note – тук отварям една голяма скоба:

  • Проверих твърдението, че до 2020 г. ще има ~ 20 милиарда IoT devices. Доклада, който намерих е от 2011 година и на страница три се споменава цифрата от 50 милиона устройства;
  • Доклада на Forbes относно твърдението, че до 2020 IoT ще генерират ~ 600 ZB е коректен, но написан в статия от преди точно година (13 Ноември 2016);
  • Тези статистически детайли не знам колко могат да бъдат прогнозирани, но ще следя с интерес какво се случва на IoT пазара.

Мартин обръща внимание на данните и трафика, които IoT могат да генерират. Всички ние взимаме трафика за нещо не толкова важно, но истина е, че той трябва да се пести. Разказа ни също и за няколко неща, които могат да ни помогнат като например това, че не всички данни трябва да се запазват и измерват, може да използваме агрегация (статия за data aggregation от IEEE), “Cold” data (или данните, които не са ни наистина нужни или използваме прекалено рядко) и т.н. Даде пример как няма нужда да измерваме температурата в стаята ни през 30 секунди, например. Какво ще се случи за толкова време? Помогна ми да взема решение за home automation-а, защото се чудих дали 2 минути са ок за измерване, но може дори и на повече.

 

“Testing Red Hat Enterprise Linux the Microsoft way” – Alexander Todorov от RedHat

Александър говори основно за pariwaise testing, installation testing и спомена, че за автоматизация на инсталациите използват Anaconda.

Разказва за спецификите на тестване на инсталатора на RedHat – симулация на iSCSI (с и без authentication) например, за това как един тест кейс може да продължи по 30 минути.

Говори за оптимизиране на test matrix (нещо за което трябва да прочета повече). Освен това трябва да си припомня и повече за pairwaise. За големи test suites и направен правилно може да даде впечатляващи резултати.

В общи линии разказа, че използва 3 tiers – първия е набор от тестове, който намира около 30% от всички логнато бъгове, втория набор е от всички тестове, които ползва (още около 30% от намерените бъгове са от тях) и 30% са от exploratory testing. Останалите 10% са дефекти (4 critical) – 1 firmware dependent, 1 corner case в s390x  (не може да се закачи правилно по NFS, hidden dependency и разлика в работата на IPv6 иIPv6) и третия в недостатъчно тестване (human error).

В извод pairwaise има доста силни страни така, че трябва да бъде използван от нас често и мъдро за да намалим броя на нашите test cases без да афектираме качеството.

 

Обедна почивка – време за networking, хапване, кафе и дойде време на:

 

“The future of computing” – Laurent Bugnion от Microsoft

Забавния Laurent Bugnion с интересния швейцарски акцент започна с историята за computing_а отзад-напред – със старите лентови карти, огромни комютри и т.н.

После мина на Blockchain:

  • Blockchain не е само валута;
  • Децентрализирано сигурно предаване на информация;
  • Информацията е най-ценния ни ресурс.

Следваща точка беше cloud computing (напомни ми на онзи лаф, че не качваш на cloud, а на компютъра на друг човек). Спомена Azure, OneDrive, Amazon Cloud Services и накрая – “Абе и Apple май имат някаква такава услуга, но …” и се засмя :D

Спомена за serverless computing (помните ли Силиконовата долина и идеята им за разпределено изчисляване (decentralized computing)?). (последните няколко знака заприличаха на някакъв извратен regular expression :D ).

Направи и малко демо с Cortana (като първия път фейлна :D) за времето, да му напомни нещо и накрая интересното беше “Като се прибера ми напомни да направя еди си кое”. Имаше и tell me a joke и хумора беше трагичен :) Следващата част на лекцията беше за AI/ML (Artificial Intelligence, Machine Learning). Едно нещо не ми хареса – каза, че ще направи serverless demo, но после каза – “Upload-ваме това на сървъра”. Това е тъпо и ще прочета малко за тяхната идея за serverless и ще видим каква е тяхната дефиниция.Та – направи един пример в Azure cognitive services с blob upload event (тови е event при upload на снимка в нашия случай) успя да прочете нещо надписано на ръка. Успя от две свои снимки с Emotion API да разпознае емоцията на лицето си с доста добра точност. Дойде ред на Augmented reality (пример беше Pokeymon Go) и Virtual Reality (напълно виртуална реалност, рендирана от някакво изчислително устройство). Спомена с и известна надсмешка за Google Cardboard glasses (които по дефиниция са супер евтини, мисля $2 и после почти директно ги сравни с VR на Acer) и HoloLens и mixed reality (смесена AR и VR – практически можем да взаимодействаме с реалния свят смесен с виртуална реалност).Показа и забавно демо с един космонавт над публиката. HoloLens заби само веднъж, а стрийминга беше ужасно бавен. Сигурен съм, че ползва 2.4 GHz мрежа. И пак Apple reference като спря stream-а – “Can you turn off your phones?” :D Показа едно тъпо демо с едни кубове и после дойде някакво абрусдно добро демо за планиране на индустриални структури упралвяемо с глас и жестове (добави кран/махни кран/покажи информация за този кран). Презентацията и кода можете да видите тук.

До момента най-забавна/приятна/интерактивна лекция.

 

В почивката имах възможност да се запозная с Алекс Тодоров, който е супер активен в нашата сфера и поддържа един от най-интересните блогове за QA в България – http://atodorov.org/ а след това и се запознах (най-накрая!) с Виктор Славчев – още един страхотен лектор и блогър. Нещата му можете да видите тук – http://mrslavchev.com/

 

“A Team Contributing Full-time to Open Source Projects – A Primer on Making It Happen in Your Company” – Iancho Dimitrov, Dimitar Ivanov – Musala Soft

 Двамата лектора изглеждат интересни и разказаха защо е ок да работят върху / разработват open-source проект.
До момента разказаха основно за МусалаСофт.  След това заговориха за smart home и споменаха OpenHab и SmartHome.Продължават да говорят основно за Мусала.

Разказаха как са убедили борда на директорите, че имат нужда от opensource проект по който да работят и в момента по него са включени 10+ програмистра (full-time) и един Senior Dev (part-time mentoring).

Описали са доста документация, доста unit тестове и са метнали тежките задачи. После е последвал static code analysis, работа по интеграцията с различни устройства и разбира се са вложили вътрешните си, вече утвърдени процеси в разработката.

Малко разпиляна ми дойде лекцията така, че на TL DR – пичове са решили да се занимават с open source, харесали са си smart home идеята, убедили са мениджмънта, че ще е яко ако имат такъв проект и с времето са набавили 10+ човека, които работят за проекта постоянно. И нещо важно – казаха, че по-неопитните хора, които първо са минали през този opensource проект са се интегрирали много по-бързо и по-качествено във фирмената инфраструктура работейки по комерсиалните проекти.

 

“Mastering scrum mastering” – Nikola Bogdanov от Fourth

Започва с това, че има куче и че е от Добрич. Оставам до края на лекцията! Учи за PhD и води университетски класове (не каза къде).

Започва със самото начало, защо SCRUM е важен, какво прави един scrum master и т.н. Разказа как в началото на agile stuff всичко е било self-organizing team и как е минало доста време докато се оформи нуждата на отделен човек, който да работи като scrum-master.

Scrum master as a teacher:

  • Boundaries;
  • Alignment;
  • Constraints;
  • Support;
  • Observations.

 

Scrum Master Evolution Model:

  • ScrumDude – part time, Schedules meetings, time keeping, three questions, Lists positives & negatives;
  • ScrumMom – Moderates meetings, protects the team, directly removes impediments, team interface, artificial harmony, bossy, cares about velocity and delivery dates;
  • True ScrumMaster – facilitates meetings, grows the teams long term, delegates & analyses, makes the team responsible and accountable, encourgages and motivates, mirror of the team, leads by example, an experimenter;
  • Agile Guru Lama Sensei – light for the team, sees & feels the matrix, holds the space, refills & inspires, just listens & reflects, flow & evolution, asks powerful questions, kokoro teacher.

 

“Automating Web security testing” – Yavor Papazov – CyresLab

Явор разказа с голямо въодушевление и страст за това, което прави. Разказа как не се прави вече:

Yesterday’s IT projects:

  • Waterfall methodology;
  • Testing comes after construction and before deployment;
  • Discrete releases;
  • A release of a project can be certified for security
    • e.g. common criteria

 

И как се прави сега:

Today’s IT projects:

  • We’re Agile now
    • We don’t do releases
  • Tendencies
    • DevOps
    • Continuous Integration;
    • Continuous Deployment
  • Cloud-first design
    • Elastic Load Balancing & Autoscaling
    • Systems that manage themselves

Обясни ни за това, че има два подхода към сигурността:

  • Options A: Give up security at release and work to improve it afterwards
    • Resilience instead of security
  • Option B: Ensure security early along the software production pipeline
    • Leads to automating security testing

Спомена и за Chaos Monkey.

 

Защо автоматизирането на security тестовете е трудно:

  • Lack of well-defines security requirements
    • “Make it secure” is not well-defined;
  • Most security requirements are non-functional
    • “Make it secure” is non-functional
  • Lack of well-defined security requirements
    • Check “Application security verification standard” by OWASP
    • CWEs
  • Most security requirements are non-functional
    • We can translate some requirements to functional

 

What other people use:

  • OWASP ZAP (Zed Attack Proxy) – had API
  • BDD-security )Confinuum Security)
  • Mittn (F-Secure)
  • Gauntlt

Demo time:

 

Това беше края на ден първи. Имах удоволствието накрая да се запозная лично с the Microsoft dude и с Явор и побъбрихме мъничко. Беше много приятно да видя, че извън сцената хората са си същите – без много взимане на сериозно, много приятелско и тополо отношение.

 

 

Stay tuned за ден втори :)

Ние като QA НЕ осигуряваме качество!

Покрай силната неопределеност и неструктурираност на част от методиките в Quality Assurance витаят едни общи разбирания, че Quality Assurance engineer-а осигурява качество. Това НЕ е така. Ние можем да:

  • Анализираме изискванията на клиента и на тази база (и немалко предишен опит) можем да предвидим още преди да е започнала активната разработка да открием несъответствия (логически, технически или концептуални);
  • На база клиентски изисквания да напишем десетки или дори стотици тестове (test cases) на всеки отделен компонент, които след като част от нужната функционалност е готова да изпълним за да се уверим, че това, което е направено съвпада с вижданията на клиента за добре работещо приложение;
  • Да използваме множество методики, тест техники, черна магия и каквото друго е нужно по време на разработката на проекта. Всичко, което намерим го логваме в някой bug tracking system (дали ще е TFS, BugZilla, JIRA, дори и Google Docs, etc няма значение). Знаете правилото – ако няма логнат бъг значи няма бъг. А повярвайте ми – в този ежедневен поток от информация много лесно можете да забравите нещо ако не го логнете;
  • Да проверим след като програмисти/дизайнери/други са фикснали проблема дали е направен по начин, който може да удовлетвори клиента (и в идеалния случай и нашите лични вижданя за това кое е правилно);
  • Да направим финални тестове, които да ни дадат солидни доказателства, че можем да кажем на клиента актуалния статус на проекта. Има вариант в който да репортнем, че нещото не работи според очакванията и изискванията, но да бъде предприет риск (risk management) и въпросната функционалност да бъде пусната в production. Това зависи от клиента, не от нас.

И още едно, много важно нещо – мога да ви гарантирам, че НЯМА софтуер без бъгове. Има такъв с неоткрити такива. Някой преди време беше казал, че: “QA can miss a bug, but the crowd will not”.

13.01.2017

Снощи ходихме до фитнеса да го видим дали е още там. :) Залепнах за велотренажора, направих една загряваща петкилометрова и после пуснах програма за един час да видим колко ще мога да изкарам. Очаквах около 30 км/ч средна, но се оказа, че забих на 27.3 км/ч (което не е чак толкова много при положение, че нямам баири). И все пак не беше лоша тренировката.
Тегло от снощи – 99 кг. Има надежда.

 

Днес разбрах, че норвежеца Viljami Kuosmanen (това не мога да го произнеса на глас) показа на Google, Apple и Opera foundation как лесно може да се възползва от един елементарен security flow (макар, че по дефиниция не бих го нарекал така). Идеята е, че ако имам поле с id=name autofill на браузъра ще ми предложи да попълня полето, но хватката е ако имаме няколко скрити полета с margin-left:-500px. В случая са скритите полета са phone, organization, address, postal и city. Така при $_POST освен данните, които виждаме (name и email) ще постнем и останалите (ако са въведени в autofill-а). Хубавото в случая е, че пароли и CVV на кредитни карти не се изпращат.

Можете да разгледате live demo-то на скрипта и да си поиграете. Има го в github в горния линк.

 

  • In other news намерих един много приятен Online JSON viewer. Върши страхотна работа при визуализация на JSON и за по-лесно намиране на счупен такъв;
  • От същата поредица намерих и един много приятен online DIFF checker, който може освен да ви покаже в много приятен вариант разликите в два текста и да ви запази за определен период стринговете. Ето и един вариант – https://www.diffchecker.com/XuNaSlwI
  • Малко приятна фонова музика;
  • А случайно да имате ли проблеми със запомнянето на response codes като мен? HTTP Status Cats API е вашия помощник. Този малък инструмент събира двете най-важни неща в Интернет – котки и status codes. Якото е, че можете да го викате и по линк – https://http.cat/[response code]. Например едно от любимите ми https://http.cat/416 :D
  • Един малък thread за любими книги свързани с Quality Assurance Engineering. Като преглътнем индийците има някои интересни четива;

 

И за накрая едно тъжно интервю от Саймън Синек за хората на Новото Време като го наричахме преди или за децата израстли след 2000 година. Силно препоръчвам ако сте от тях или сте родители на такива деца.