неділю, 18 грудня 2016 р.

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

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

Книга невеличка, але чудова (коштує лише 2 бакси на leanpub), не така вже й нова (я її купив ще коли долар був по 8). Можливо, вона мені найбільше сподобалася через те, що думки автора щодо автоматизації збігаються з моїми:
 
You should automate 100% of the tests that should be automated.


середу, 14 грудня 2016 р.

Тестатон №5 TestUAStartups в Києві

Мушу подякувати усім тим, хто організував, судив та приймав участь у чудовій події, що я намагаюся не пропускати - тестатон TestUAStartups.
Це був 5-й тестатон від цієї чудової команди, і 4-й де я був суддею.
Все було суперово!

вівторок, 29 листопада 2016 р.

Equivalence Class Partitioning - Explaining at Interview

More than a year ago, I went for an interview for a medical project. I was given some kind of a layout design and a product technical specification. The task was: "Describe your approach to the product testing, make use of Equivalence Classes Partitioning." I must admit that the layout design and specification prepared were very good for the purpose of a tester interview.
Although I knew what are "equivalence classes", and even had taught some theory to novice testers, the task made me stuck for a bit. After a pause (long enough to spoil the interview), I said:
- What should I break into Equivalence Classes? - Watching my competence decreases in the eyes of the interviewing Test Lead.

"Класи Еквівалентності" - Пояснення, Наздоганяючи Джеймса Баха


Півтора роки тому я ходив на співбесіду на один медичний проект, де мені вперше дали щось типу дизайну продукту із невеличкою технічною специфікацією. Завдання було: "Описати тестування продукту, використовуючи класи еквівалентності." І хоча я знав, що то таке "розбиття на класи еквівалентності", і на той час вже викладав теорію тестування тестерам-початківцям, це завдання привело мене у невеличкий ступор. Треба сказати, що самі дизайни й специфікація були дуже вдало підібрані та підготовлені, тест-лід була справжній молодець.
Після паузи (достатньо тривалої, щоб зіпсувати співбесіду) я спитав:
- Що я маю розбивати на класи еквівалентності? - Чим, звісно, підважив власну компетентність в очах тест-ліда.

четвер, 24 листопада 2016 р.

Test Design Definition

There are numerous variants out there what exactly "Test Design" means.
Having tried to explain the matter several times lead me to the following definition which I find even more solid than my definition of testing.
This is how I put it:

Test Designing is prioritizing of an infinite list of all the possible inputs by the risk of not knowing the actual output.

I like this definition because:
  • it implements the agility of testing time-frames
  • its corner stone is risk - the main/only reason of doing testing at all
 And by inputs I mean everything that is needed for testing: data, steps, environments etc. And outputs are the system-under-test's reactions to our testing.

вівторок, 22 листопада 2016 р.

My definition of Testing


When I read the post in QA hiccaps: The Anatomy of a Definition of Testing, where James puts the following definition of Testing:  "Testing is the pursuit of actual or potential incongruity".
I find this definition rather romance. I think it was intentionally so.
I thought about how I understand the Testing in the whole its variety of actions, and came to the following definition:
 Testing is making implicit things explicit to someone who matters.
Why I find this definition important is that it does not include a person of a tester and does not insists the tester is right doing this "testing".
Because all humans, including testers are to err in directions of their "pursuit". I often find "incongruities" that appear not important, and if I had "pursued" them long enough I'd feel disappointed.
But when we report to someone who matters that there was something "implicit" for them, we let THEM decide if this info is useful, having done our part of the deal.
And with "implicit" I also mean "unconcious". What everyone look at but no one sees. The things that "a clear eye" can find.

PS Thus, my definition doesn't include testers, but instead includes those who are using information taken from testers. No, I don't find this fair. Here is a point for improvement :-)

середу, 16 листопада 2016 р.

Моє визначення тестування

Прочитавши останній пост QA hiccaps: The Anatomy of a Definition of Testing, Джеймсове визначення тестування як "гонитва за присутньою чи можливою невідповідністю" мені здалося трохи романтичним. Мабуть, така і була мета :)
Я для себе нещодавно підібрав таке визначення:
Тестування - це обернення неявного на явне для тих, хто впливає.
Для мене найголовніше, що це визначення не містить особи тестера і його беззаперечної правоти. Бо всі люди, в тому числі й тестувальники, помиляються у "напрямках гонитви". Особисто я часто знаходжу неважливі "невідповідності", і якби я за ними "гнався", то відчував би розчарування.
У той же час, повідомляючи комусь важливому про те, що було щось "неявне", ми даємо ЙОМУ визначати корисність цієї інформації, виконавши свою роботу.
Під "неявним" я також розумію "неусвідомлене". Те, що усі бачать, але не помічають. Тобто речі, які може знайти "свіже око".
Отаке моє визначення.

PS Зрозумів, що я виключив особу тестера, і додав особу, що впливає. За Фройдом, як то кажуть :-) Це несправедливо. Треба ще думати!

понеділок, 7 листопада 2016 р.

"Оцінка тестування": як оцінювати те, що всі розуміють по-своєму?

Одне з найтривіальніших завдань для будь-якого спеціаліста - це оцінка часу на виконання власної роботи. Звичайно, в кожній професії є завдання із "підводними граблями", але якщо взяти приблизну оцінку в двох спеціалістів, вона рідко буде відрізнятися більше ніж на порядок.
У тестуванні все інакше. Спробуймо розібратися, чому, і як було б більш правильно і зрозуміло бізнесу (бо саме він платить нам гроші, і саме йому ми маємо бути корисні).

понеділок, 31 жовтня 2016 р.

Читайте Джеррі Вайнберга

Десь рік тому я вперше взяв до рук книжку Джеральда Вайнберга "The Secrets of Consulting", та не зміг відірватися доки не прочитав 2 інших: "More Secrets of Consulting" та "Perfect Software (and other illusions about testing)". 
За свою кар’єру у більш ніж 50 років він встиг написати як мінімум пару книжок про кожен з аспектів роботи в ІТ.
На leanpub.com є цілі збірники його книжок і для програмістів, і для тестерів, і для реквайрмент-менеджерів, і особливо - для менеджерів проектів. І як завжди, ті, кому ці книжки потрібні найбільше(ПМи), їх не читають...



Кожна з його книжок чудово розкриває тему, якій присвячена. Але крім того, вони вчать життя! Джеррі має чудове "відчуття важливого", кожна проблема якою він цікавиться, перетворюється на низку простих життєвих питань, які він розв’язує із майстерністю джедая. 

 Ось кілька його порад:
  • Ніколи не читайте те, що не варто читати.
    • Не треба робити добре те, що не треба робити.
      • Ніколи не перев’язуйте подарунковою стрічкою сміття. 

неділю, 11 вересня 2016 р.

Менше сумнівів

Не знаю як ви, а я боюся своїх сумнівів. Вони отруюють життя, забирають час і мотивацію. Тому я ненавиджу сумніватися! 



У так званому Lean Development навіть офіційно затверджено Принцип №4: 

Відкладай зобов'язання (Defer commitment), що означає: 
Приймай рішення якнайпізніше! 
Див. http://www.allaboutagile.com/lean-principles-4-defer-commitment/ 


Чому не вирішувати раніше, адже це могло б прискорити весь процес? 
Чим менше невідомих у рівнянні, тобто не прийнятих рішень, тим швидше можна розв'язати задачу. 

Суть цього принципу в тому, що із часом все зміниться, додасться нова інформація, і або вже не буде, про що думати, або рішення буде прийняти простіше. 

Але як не відкладай, після рішення гарантовано прийде нова інформація, а за нею - сумніви у правильності рішення. 

Зменшити сумніви дуже допомагає візуалізація наявної інформації. Бо часто ми боїмося, що, скажімо, рішення не сподобається іншим, але просто не хочемо собі зізнатися, чому саме.

вівторок, 2 серпня 2016 р.

Причини всіх рішень

Кожному моменту я звик шукати пояснення.  Зазвичай, я доходжу до якоїсь межі доцільності, глибше якої, я вважаю, вже нічого не можна достеменно з'ясувати.
Ці найглибші, з доступних, пояснення я відношу до певних категорій. Якщо я не можу точно виявити категорію, значить я копаю далі. Але я можу копати далі і категоризовану причину. 
Отже, причини різних рішень я розділяю на наступні категорії:
  •      Фізичні чинники. Сюди входять всі ресурсні обмеження. Коли для того, щоб зробити інакше(ліпше) не вистачило грошей, людей чи технічних можливостей.
  •      Політичні чинники. До цієї категорії я відношу рішення, основані на людських взаєминах. Як то "Головна компанія наказала нам використовувати цей сервіс" чи "Ми не можемо робити цю задачу, бо нас за це покарають". Головна їхня ознака - це емоційне слово, що не має сенсу поза людським контекстом, як то "боятися", "ненавидіти", "карати", "любити", "обожнювати"; чи слово, що відображає людські взаємини, ієрархію, наприклад "наказувати", "підлягати", "розпоряджатися", тощо.
  •      Історичні чинники можуть мати політичний чи фізичний характер, але це те, що ґрунтується не на теперішній дійсності, а на минулій, коли ті фізичні та політичні впливи мали місце.
І от останнім часом мені стало здаватися, що мене оточили політичні та політично-історичні чинники, причому не моєї політики. Гнітюче відчуття, що тебе закручено в чужих тенетах. Ну і от я звільнився. Привітайте мене!

неділю, 24 липня 2016 р.

"5 hours a day" keeps pressure away

A common question raised by customer-side management:

  • How to control software engineers? 
  • How I, as a customer who pays huge bags of cash per hour to this hippies, can really know that they are not cheating me watching youtube half a day?

But even if the question is not asked explicitly, does not mean nobody has doubts alike. 

I worked in various environments. Let me review the most common solutions and their pros and cons.





пʼятницю, 22 липня 2016 р.

Tester's mental "try ... catch"

Once this blog post http://www.inspiredtester.com/inspired-tester-blog/process-metrics-and-the-impact-of-context (and maybe a little bit of Jerry Weinberg's ideas) inspired me to this thoughts.




People like their "status Quo". They don't like to act. Every their action is forced by change. The change may be in outside, in circumstances; and it may be in themself. Changing the way one acts too is a reaction to different changes one experiences.

Applying this to the Software Testing, an experienced user becomes a tester, when they react not directly to external changes, but to the internal feelings induced by external changes. Establishing some kind of "try - catch" block for distractions in their brain. Instead of (or additionally to) just shouting out loud that "This piece of software does not work!", the tester asks themself: "What causes my such a reaction?" and puts the answer to the Bug Report title.

пʼятницю, 15 липня 2016 р.

Agility of "agile"

As for me, currently a "new renaissance" of Agile (with capital "A") followers is going on. With their not getting the spirit of agile manifesto, but just following "best" practices and rules from some guide books, not regarding the reality, context and consequences of their deeds. (It may be connected to the new generation of IT employees stepping on the scene.)

That's why it's great that there appear new posts on this subject, trying to educate people about the difference between "agile" and "Agile".
Here is a post I liked recently from Yegor Bugayenko: 12 Mistakes in Agile Manifesto.


Гнучкість "гнучкості"

Мені здається, зараз відбувається якесь "нове відродження" адептів Agile (з великої літери) - людей, що не розуміють дух agile manifesto, а лише намагаються слідувати книжковим правилам без огляду на дійсність та результати своїх дій. (Це може бути пов’язано із черговою великою хвилею "нових айтішників".)

І от як раз нагодився текст Єгора Бугаєнка: 12 помилок Agile маніфеста (12 Mistakes in Agile Manifesto).

В житті цих помилок, звісно ж, не 12, бо кожен із постулатів Agile Маніфеста може мати безліч неправильних інтерпретацій :-)

середу, 25 травня 2016 р.

Питання на співбесіду

Приймаючи участь у співбесідах, я рідко дотримуюся свого плану, адже, на мою думку, співбесіда має лишатися "спів-" - тобто взаємною - "бесідою" - тобто діалогом рівних людей, що мають якісь спільні інтереси. Найбільше мене тішить, коли на співбесіді я дізнаюся про щось нове й цікаве.
Ось мій особистий список того, що я хочу дізнатися у кандидата, безвідносно його професійного рівня. Просто відповіді провідного "сіньора" будуть більш фундаментальними та розлогими, а молодшого "джуніора" - короткими, наприклад "Не знаю." :-)

понеділок, 23 травня 2016 р.

"Done" for everyone!

Probably each of us had that dialogue with a developer:
- How is your task? Is it okay?
- Yeah! It's done!
- Where can I test it?
- No, it's not yet covered with unit tests / not passed code review / the last commit is almost there.


(Google points here for this picture: https://hoangluongsjsu.wordpress.com/ )

What is missing here is not exactly "Definition of "Done"", but a substitution of different levels of "Done":
- Personal "Done": "I can do nothing more about it", the task is handed over to another team member."
- Team's "Done": "We have done all we could do internally. Now we can demonstrate the results to a wider audience, but we are still open for changes and suggestions in case of interference with some other team."
- Project's "Done": "We ship it! All your claims and change requests you should send to our legal department."

Working with agile Scrum-like process which states team commitment, we should always put the Team's "Done" to tasks' Acceptance Criteria.
Because putting personal commitments to a task description looks like avoiding responsibility for possible future changes in its scope due to integration issues.
But putting project oriented goals is even worse as they are likely not to be testable at the point, when a particular task is done. That leads to "requirements inflation", when the "key project points" are written everywhere and at the same time are not met anywhere.

Watch your requirements. And keep your task descriptions clear and testable.

середу, 4 травня 2016 р.

Мої просрані релізи

За останні кілька років я брав участь у не менше ніж 100 випусках нового коду у світ. Більшість разів усе було чотко, але реальність іноді  дарувала нам сюрпризи, і зовсім не завжди вони були пов'язані із спеціально навченими індійськими спеціалістами баз і консолей.
Прошу до вашої уваги 3 випадки, що завжди спадають мені на думку при словах "Fucked up release".



пʼятницю, 22 квітня 2016 р.

Agile and numbers



In his recent post, Seth Godin writes:
When you measure the wrong thing, you get the wrong thing. Perhaps you can be precise in your measurement, but precision is not significance.
On the other hand, when you are able to expose your work and your process to the right thing, to the metric that actually matters, good things happen.
We need to spend more time figuring out what to keep track of, and less time actually obsessing over the numbers that we are already measuring.



This is the essential part of the "agile development".
In my current team we spend lots of time on "Backlog grooming sessions" arguing on numbers, getting asked "why is it 5 not 8?"
On the same time, nobody cares on getting the Burndown Chart to look like burn down. The reason is "We have many important and urgent tasks with vague deadlines emerging meanwhile in the sprint."
So on our "Sprint planning" meeting we are basically putting the "precisely measured" tickets to a heap of immeasurable ones. What we get is precisely immeasurable. Like dropping 10 carat diamonds to a bucket of soil and trying to estimate the bucket weight.
What precision we might get?


Moreover, the measurement does not influence our actions in any way.
Our the most precise scale of estimations probably should have 3 values:
- "It's OK to try to do this now"
- "Better not to try now"
- "We don't know"
Having the priorities in place, this simple scale will give us enough information to plan sprints, and dramatically reduce time spent on estimation and planning.

середу, 20 квітня 2016 р.

Test Design Strategy

Updated my Test Strategy Template with a new section.
Enjoy :-) Comments are welcome!

Test Design Strategy

Test Design activity is a process of identifying and formalizing Test Cases and Test Suites (in forms of Check Lists, mind maps, etc.) in regards to risk weights, i.e. the value customers might loose if the test is not conducted; or in other words, the risk of unawareness of the unwanted behavior of the system.
Each Test Case is explicitly related to a piece of Requirements, as well as to Test Suites it is run under.

пʼятницю, 1 квітня 2016 р.

Сем проти Джеймса (скандали-інтриги-розслідування у віршах)


Результат пошуку зображень за запитом "cem kaner james bach"
Якщо ви достатньо давно в тестуванні, то маєте знати Джеймса Баха (James Bach). Не менш відомою постаттю у галузі  методологій розробки є Сем Канер (Cem Kaner), автор багатьох книжок і публікацій. Колись давно вони разом були співзасновниками Школи Контексто-керованого Тестування (Context Driven Testing School), що заклала засади сучасного розуміння дослідницького підходу (exploratory testing). Після того вони чогось посварилися, побили горщики, та перестали спілкуватися. І щось мені підказує, що розбіжності в них були зовсім не у способах тестування, а у чомусь іншому. Але що було, те загуло. 

неділю, 27 березня 2016 р.

Мої RSS підписки про Тестування. Березень 2016

За рік я знайшов кілька нових, вартих уваги блогів.
Ось останній перелік тих, хто активно пише щось корисне.
(минулорічний список тут http://lazytesterua.blogspot.com/2015_03_01_archive.html)


БлоґКоментар
Gerald Weinberg's Secrets of Writing and ConsultingJerry Weinberg - американський ІТ консультант зі стажем. Цей мудрий чоловік був моїм відкриттям року. Усім раджу його книжки. Від 80-х він їх чимало написав.
Agile Testing with Lisa CrispinЦікаві речі про тестування і менеджмент
Gojko AdzicРозумний дядько, консультант в ІТ. Пости про автоматизацію дуже мене надихнули.
QA HiccuppsТестер, що намагається нестандартно дивитись на речі. Знайшов його за серією публікацій "Тестування - як жартування" (Joking With Jerry)
Uncharted WatersЧудовий блог про різні аспекти роботи в ІТ
UX MovementСвіжі погляди на дизайн користувацьких інтерфейсів
Seth Godin's Blog on marketing, tribes and respectБагато пише про все підряд. Має надихати на думки...
Linux.org.ru: НовостиРаніше не згадував, але оце я читаю вже дуже давно. Щоб бути в курсі.

понеділок, 15 лютого 2016 р.

Where to start to automate your checks?


So you are an almost only off-shore tester on a project, and want to automate some of your daily checks to have more time for actual testing. But you lack skills to do it right, or you think you do. And the automation tools and frameworks do not suddenly appear in a project. Somebody needs to implement them.


This picture is familiar to lots of us. But how can we push the deal out of this vicious circle? If not directly to a project's but for self-development sake?

We often hear the management saying: “We do not need automation at this point.”
And they are right!
They do not need an automation of those checks YOU PROPOSED, if it is done by YOU INSTEAD of the work you are hired for, especially in that weedy way YOU NOW would do it.
Whole disadvantage from their perspective!


Starting to write code is always hard and slow at the beginning, because the code quality is in direct proportion to an amount of hours one spent attentively staring at it. So here I propose the first points to look at start:

неділю, 14 лютого 2016 р.

Є час, хочу автоматизувати. З чого почати?

Автоматизація сама на проектах не з’являється, її хтось має писати.

Ця картинка знайома багатьом. Але як зрушити справу з мертвої точки? Якщо, навіть, не для проекту, а для свого розвитку?

Ми чуємо від керівництва "На даному етапі нам не потрібна автоматизація."
І це так!
Їм не потрібна автоматизація саме тих перевірок, що Ви їм запропонували, якщо її будете робити Ви замість тієї робити, на яку Вас найняли, та ще й так недолуго, як Ви зараз це робите.
З їхньої точки зору - суцільні мінуси!


Власне тестове середовище на docker


Для чого тестеру може знадобитися свій інвайронмент, якщо можна просто почекати, доки код виллють на тестовий сервер?

Мені це питання задають постійно. І відповідь, як завжди, залежить від контексту.

Щось ризиковане треба перевірити у середовищі, яке не шкода; для чогось потрібні особливі налаштування, недоступні на тестовому сервері; а хтось, як я, хоче тестити ще у девелоперській гілці, бо не може дочекатися, доки новий код нарешті дорев’ювлять і замерджать в develop.




В епоху віртуальних машин існує кілька загальних інструментів, що дозволяють запустити собі власне тестове середовище, та заразом вижерти зайву оперативку та довантажити процесор вашого комп’ютера до "прийнятних" 104%.

Як розгорнути два зв’язаних docker-контейнера: веб-сервер із Вашим проектом та базу, подивимось на прикладі PHP та MySQL.