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

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

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

Тому, на мою думку, першим тестом має бути перевірка від "доступу за дурно", тобто:
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!