Звіт із Selenium Camp 2017, про архітектуру тестів

Був оце на Selenium Camp 2017
Все дуже сподобалось! І місце, і доповіді, і відвідувачі. Особливо на віскі-паті :-)
Після кожної доповіді я ставив питання, а на майстер-сесії питань-відповідей навіть трохи попав у кадр і змусив усіх відповідати, як мати справу із великими тестовими базами, отримавши кілька робочих ідей!
І навіть той раз, коли одна з презентацій перетнула нижню межу цікавості, час не був втрачений, бо в коридорі нас спіймали журналісти і взяли інтерв’ю. 

Ще раз дякую команді організаторів!

Свій звіт я хочу зробити досить нестандартно. Відео всіх доповідей ви самі можете подивитися на офіційному каналі, тому немає сенсу їх переказувати. Я ж просто поділюся тим, що було нового впродовж двох днів конференції саме для мене на кожну з тем, не прив’язуючись до якоїсь конкретної презентації.
 

Усі мої нотатки можна розділити на 3 групи:

• Збір та аналіз статистики результатів тестування
• Архітектура автоматизації (поради щодо PageObject та інших паттернів)
• Безперервне впровадження (Continuous Deployment): Github Flow, середовища розробки, постійне тестування на робочому середовищі

Хочу почати з архітектури, бо про це в мене найбільше нотаток.

Web Site UI Testing

"We were only changing the UI, so we don't need a full regression run here." - They said.

In Gerald Weinberg's "Secrets of Consulting" there was a wonderful chapter on "lullaby words". And "only" was one of them. Each time testers hear the word "only" - they start to get nervous. Or rather they smell bugs in the air :-)

I want to share my outlines that should be taken into account while testing "only UI" of a website (disregarding its platform or applied area).

Тестування UI сайту

"У нас були зміни лише на UI-ї, повністю регресію проганяти не будемо." - казали вони.

У Джеррі Вайнберга був чудовий розділ про "колиско́ві слова", і "лише" - одне з них. Щоразу як тестер чує "лише" - тестер починає нервувати. Або навпаки, радіти, бо в повітрі запахло багами :-)

Хочу поділитися своїми намітками про те, що треба брати до уваги, тестуючи "лише UI" якогось сайту (не прив’язано до платформи).

Питання на співбесіді: Потестуйте логін-форму

Мене просили потестувати логін форму ледь не на кожній співбесіді, навіть на сініора. Зараз мені задали це питання мої студенти, самі відповівши так:
Оскільки спершу треба тестувати позитивні кейси, то першим тестом має бути "правильний логін - правильний пароль - залогінена сторінка".

Це мені здалося трохи невірним, і ось чому.
Найголовніше завдання функції логіну - обмежити доступ. Адже, якби ми хотіли давати всім доступ, то цієї функції б не було зовсім, в нас би була відкрита для всіх сторінка. А оскільки головне - обмежити, то й перевіряти ми спершу маємо саме "обмеження", а не "успішний доступ".

Тому, на мою думку, першим тестом має бути перевірка від "доступу за дурно", тобто:
1. Спроба логіну із порожніми полями - нема доступу.

Далі, має бути перевірка "недоступу" за неповними креденшелами:
2. Спроба логіну з порожнім паролем та вірним логіном - нема доступу.

І тільки в третю чергу можна перевірити, що вас пускає із валідними значеннями.
3. Спроба логіну з вірними логіном та паролем - доступ до потрібної сторінки.

Сподіваюсь, комусь це пояснення допоможе!

Я особисто стикався з випадками, коли починали тестувати з пункта 3., забуваючи про 1. та 2., і баги, пов’язані з ними, вилазили аж за кілька місяців на продакшені, залишаючи систему вразливою, покладаючись тільки на те, що "злі хакери" не встигли нічого зробити.

Дзен Python

Я знайомий з Python ще з 2009 року. З тих пір він став моїм незамінним інструментом з тестування. Не скажу, що я багато на ньому писав (та й узагалі я не дуже люблю багато писати), але завжди (у 90% випадків) коли мені було треба, я сідав, писав так, як мені здавалося правильним, і воно працювало!

Якщо ви, пишучи у будь-якому інтерпретаторі Пайтону (перевірено на Python 3.6 та Jython 2.7), не будете знати як вам вчинити, введіть:

>>> import this

Я дуже вдячний Тиму Пітерсу за ці чудові афоризми, які дуже точно підкреслюють те, чим керуватися, пишучи код. Такий дзен Рубі від Еріка Пірса колись додав мені впевненості, що мені продовжувати з Ruby не буде цікаво. Був би радий побачити такі списки принципів для кожної мови програмування. (Для PHP, мені здається, було б щось посереднє між цими двома).
Але, схоже, що програмісти на всіх інших мовах надто сильно люблять писати код, щоб відволікатись на філософію. Так що якщо Ви любите філософію - вчіть пітон :-)

Дзен Python

by Tim Peters

Прекрасне ліпше за потворне.

Явне ліпше за неявне.

Просте ліпше ніж складне.

Складне ліпше ніж заплутане.

Плоске ліпше ніж вкладене.

Розлоге ліпше ніж скупчене.

Читаність має значення.

Окремі випадки не на стільки окремі, щоб порушувати правила.

Хоча практичність б’є чистоту.

Помилки ніколи не мають тихо минати.

Якщо тільки явно не приглушені.

Перед лицем двозначності, утримайся від омани вгадати.

Має бути один-- і, бажано, єдиний --очевидний спосіб це зробити.

Хоча він може спершу здатися неочевидним, якщо Ви не голландець.

Зараз краще ніж ніколи.

Хоча "ніколи" буває часто краще ніж "прямо зараз".

Якщо рішення важко пояснити - це погана ідея.

Якщо рішення легко пояснити - це може бути добра ідея.

Простори імен - це, трясця, чудова ідея -- давайте ще!

Давно кортіло це перекласти, бо це ж "засадничі принципи" :-)

Being a Remote Tester

Being a people person, my first priority when seeking a new testing job always was a Team. Moreover, last couple of years I've been working in agile development team, mostly as a Scrum-master, with tight daily collaboration with developers (all sitting next to me) and whole-day-round chatting with a product owner (being remote but always available for any conversation during my working hours). I used to be aware of all processes and conversations going on in the team. I even could give a rough estimate instead of developers. Our team was really cross-functional and agile.

But the projects move in and out, companies grow and blow up.

So it was a time for me to move on. After almost a year of looking for a team/project that would be as good as the previous one, I gave up and accepted a proposal that made me an only team-member on the Europe continent with 10 hours time difference with the rest of the team. At that moment I truly felt what Gerald Weinberg puts in his Secrets Of Consulting: 

Struggling to stay at home can make you a wanderer.
Struggling to travel can make you a stay-at-home.

And I'm surprised how comfortable I am now in my new "stay-at-home" status!

Книга Алана Пейджа "The A word"

Автор - Alan Page (його блоґ: angryweasel.com, твіттер: @alanpage), працює в Microsoft.

Книга невеличка, але чудова (коштує лише 2 бакси на leanpub), не така вже й нова (я її купив ще коли долар був по 8). Можливо, вона мені найбільше сподобалася через те, що думки автора щодо автоматизації збігаються з моїми:
 

You should automate 100% of the tests that should be automated.