Добро утро.
Винаги е приятно да влезеш в зала с десетки хора, които говорят за Agile, код и тестване.
Всичко започна с лекцията на Mathias Verraes – “Design Heuristics”
Това, бога ми, беше първия keynote speech без презентация, който гледам. Чувството е като онези push-up bras. Всичко беше ок, но нещо липсваше.
Аз лично се изгубих напълно още в началото.
Hindsight lessons about API testing
Viktor Slavchev
Да слушаш тестинг трола винаги е удоволствие. Дали е заради лекотата с която засажда идеи в главите ни или за интересните теми или заради братата, не знам, но при мен се получава.
И да не звуча тенденциозно мога да го хейтна (без хейт не може!1!!) – тази брада трябва да расте, по вързможност до колената! Край на хейта.
Сега, сериозно.
Лекцията му започна с препрепълнена зала и хора седящи по земята.
Първо да уточним думата hindsight. Това е “умението” да разбираме някакво събитие или ситуация само след като то се е случило. И един много подходящ пример “With hindsight, we would recommend exactly the opposite.”
Виктор каза нещо познато, което трябва да се казва много по-често и да се използва – “Tools don’t make software (tools are not a solution). You’re the one who solve the problem”.
Преди да влезем в контекста на API тестинга трябва да обясним какво е web service и Виктор го обясни по интересен начин:
Web service-а е като комуникацията със сервитьор*:
- Правите поръчка (request);
- Получавате отговор (от типа да/не) (status code);
- Получавате това, което сте поръчали (data, result)
Извън контекста на презентацията на Виктор – примера със сервитьора може да се използва и при security testing-а като му поръчаш да ти сервира ‘, *, NULL, 0 OR 1=1, шкембе с крутони и т.н. И после следим резултатите.
Относно точката за status code-а – понеже статус кодовете наистина са много и е хубаво да знаем поне основните най-лесния начин за това е да видите http status cat. От там аз научих повечето :D
Няколко неща преди да започнем с API тестовете:
- Документацията не е винаги е пълно описание на продукта. Особено автоматично генерираната, outdated или зле написаната документация. За това трябва да мислим, да идентифицираме да намерим нашия testing oracle (дефиницията си я намерете в блога на Виктор), да задаваме въпроси;
- Настройката ви при писане на тестове – не пишете тестове, които минават, светят в зелено и еднорози скачат по репорта, а тестове, които тестват функционалност (понеже тук може да се говори много можете да пишете коментар в този блогпост или в поста на Виктор в неговия блог);
- При API тестинга често забравяме да тестваме истински сценарии, а не само кой call какви отговори връща;
Кои тестове си струва да автоматизираме
- Всички тестове, които връщат грешен response code (status code checks);
- Всички тестове, които връщат грешни данни (structure checks);
- Всички тестове, които не връщат никакви данни;
- В добавка – освен единични, изолирани тестове е нужно да правим тестове по цели сценарии, знаете, но да кажа.
Status code checks – плюсове и минуси:
- Плюсове:
- Пишат се бързо и лесно;
- Много дефинитивни;
- Работят като sanity/smoke тестове.
- Минуси:
- Много повърхностни;
- Трудно получаваме някаква полезна информация ако използваме GET методи (получаваме само status code без никакъв контент);
- Status code checks сами по себе си не дефинират сериозни проблеми;
Structure checks – плюсове и минуси:
- Плюсове:
- С тях лесно може да проверим данните, които получаваме (no shit, Sherlock);
- Тестовете могат да са много конкретнил
- Ако използвате Codecept, например, можете да използвате regex.
- Минуси:
- Тези тестове са използваеми само за тестване на съдържание;
- Трудни са при тестове на променливи данни;
- Не са лесни когато имате deep nesting/дълги респонси.
Scenario checks – плюсове и минуси:
- Плюсове:
- Много близки до потребителското изживяване;
- Използваеми при намирането на integration problems;
- Могат да бъдат изпозлвани като леки regression suits;
- Когато пишете scenario checks приемайте API-то като приложение (не ме целете с домати, но помислете за това). Много по-лесно е да измислите някакъв flow и да работите по него..
- Минуси:
- Бавни за писане/изпънение;
- Изискват добра абстракция;
- Трудно е да се каже кога са достатъчни
Както е писано неведнъж – при писане на тестовете използвайте ААА метода – arrange, act, assert. Това е достатъчно. Ако обаче се оплетете в морето от arrange/act-ове драмата ще е по-голяма от тия в индийските сериали.
Сега като си препрочетох описанието с тази кирилско/английска плетка не ми звучи толкова добре колко я чух, може би трябваше да я опиша на английски.
В блога на Виктор има голяма част от това, което каза на лекцията така, че смятам ще ви е интересно.
Sales Skillz for IT People
Iancho Dimitrov, VP Innovation, Strategic Clients & Business Development, Musala Soft
Доста извън моя интерес реших да участвам в лекцията на Янчо Димитров, който беше представен като легенда. Сигурно е.
Разакза ни малко за продажбите като имаше две интересни попадения:
- “Sales are not bad thing if done right”;
- “People don’t want a quarter-inch drill, they want a quarter-inch hole” Ted Levitt.
Why Teams and Culture Matter: Leadership lessons – Vasil Popovski
Преди години слушах за пръв път Васил Поповски на едно от първите издания на ISTA. Тогава той работеше за VMWare и тогава и сега разказваше супер интересните неща. И понеже този път няма да мина през превеждането на термини и презентация ще е на английски.
Google have quite interesting project called project Google Aristotle. With that in mind Vasil gives us couple of vision about what’s the most important thing in team:
5) Impact – team members think their work matters and creates change;
4) Meaningful work – is personally important to team members;
3) Structure and clarity – team members have clear roles, plans and goals;
2) Dependability – team members get things done on time and meet Google’s high bar for excellence;
1) Psychological safety – team members feel safe to take risks and be vulnerable in front of each other.
How to build a great team:
- Team is not family – family is structure that is inherited, you cannot make changes there;
- Lead the team, do not manage it – lead people, manage projects. Manager says “Go”, leader say’s “Let’s go”;
- Foster a culture – culture is the shared core values, practices and beliefs of the team members.
- Integrity is what you do when no one is watching
Hiring:
- Hire for cultural fit;
- Prefer skills over knowledge (skill is to know how to apply knowledge);
- How many interviews you do as company – Google make a survey (how much interviews to hire someone) – fourth interviews was enough to predict a new hire’s performance with 86% confidence. After the fourth interview the accuracy of the mean score increases by less than one percent. More info can be found here
- In Leanplum for example one backend developer goes trough next interviews:
- Algorithmic
- Coding/OOP
- Design
- Cultural fit
- For Leadership skills
Performance management:
- A single negative employee or bad performer can cause a 30%-40% drop in a team’s performance.