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.

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

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

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.

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 :-)

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

Прочитавши останній пост QA hiccaps: The Anatomy of a Definition of Testing, Джеймсове визначення тестування як "гонитва за присутньою чи можливою невідповідністю" мені здалося трохи романтичним. Мабуть, така і була мета :)

Я для себе нещодавно підібрав таке визначення:
Тестування - це обернення неявного на явне для тих, хто впливає.

Для мене найголовніше, що це визначення не містить особи тестера і його беззаперечної правоти. Бо всі люди, в тому числі й тестувальники, помиляються у "напрямках гонитви". Особисто я часто знаходжу неважливі "невідповідності", і якби я за ними "гнався", то відчував би розчарування.

У той же час, повідомляючи комусь важливому про те, що було щось "неявне", ми даємо ЙОМУ визначати корисність цієї інформації, виконавши свою роботу.

Під "неявним" я також розумію "неусвідомлене". Те, що усі бачать, але не помічають. Тобто речі, які може знайти "свіже око".

Отаке моє визначення.

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

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

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