Bash.org.ru IT Happens Истории ## 11001 – 12000

15 минут назад коллега-француз умудрился порезаться… клавиатурой! Чинил-чинил и порезался.

«Какого Ктулху?!» — спросите вы… Увы, последние 15 минут (из которых минут пять мы его забинтовывали) допытываемся. Но ведь молчит, как партизан на допросе! Так что, к сожалению, ваш немой вопрос остаётся без ответа. Сижу рядом, пишу историю и кошусь, как коллега продолжает возиться с клавиатурой четырьмя забинтованными пальцами.

Вот так, коллеги: не только электрического или «весового» урона нужно бояться.

#11477: Без мануала жить опасно

12:45 05.10.2013, IT happens

Когда-то давно вёл курсы компьютерной грамотности. Пришла в ученики тётенька — ну совсем блондинка, один в один как в недавней истории про библиотеку. Только работала она бухом в бюджетном учреждении, располагавшемся в том же здании, что и курсы. На каждое объяснение она кивала светлой головкой и смотрела ясными щенячьими глазами. После этого переспрашивала не по разу то же самое, и приходилось объяснять снова и снова одно и то же. Поначалу это сильно напрягало, но потом я понял, как следует поступать: всего лишь говорить ей каждый раз, что за чем следует выполнять по пунктам для совершения определённого действия.

Остальным учащимся я объяснял и показывал несколько разных способов, которыми можно добиться одной и той же цели, попутно показывая на примерах, методично и настойчиво, чтобы в голове оставались не инструкции, а знания и умение применить эти же принципы и в чём-то другом. Дама же, напротив, совершенно не запоминала, что я ей говорил пять минут назад, да и не хотела запоминать и понимать. Поэтому при выполнении практических заданий я ей просто говорил, что за чем нужно делать, чтобы она записала в блокнотик чёткие инструкции, а на некоем подобии экзамена в конце курсов дал ей простые задания, которые она выполняла под мою диктовку.

Вообще-то даме и не требовались эти курсы — ей просто хотелось их закончить ради самого факта. А моя директриса уж очень сильно просила ей в этом помочь.

В конце всей истории обнаружился очень интересный факт, который отложился у меня в подкорке на всю жизнь. Зайдя как-то к ней в кабинет, под стеклом увидел записку от руки:

Нечётные дни месяца: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31

Чётные дни месяца: 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30

Пока сам не увидел — не поверил бы.

#11478: Тест на вшивость

12:15 06.10.2013, IT happens

Процессы в разработке софта печальные, тестируются продукты плохо…

Работаю в довольно крупной компании, занимающейся в числе прочего QA (обеспечением качества). Мне таки есть что сказать об автоматизированном тестировании. Большинство решений в кровавом энтерпрайзе — лютый ад. Конечно же, поскольку автотесты — тот же программный продукт, то для них характерны всё те же проблемы, что и для ПО, только всё ещё печальнее.

Во-первых, квалификация автоматизаторов. Почему-то функциональные тестировщики считают, что человек, занимающийся автоматизированным тестированием, «уже не человек, ещё не программист», программисты в лучшем случае считают автоматизаторов «погромистами», в то время как самих автоматизаторов в целом можно поделить на следующие группы:

1) Бывшие функциональные тестировщики. Эти ребята обычно хорошо понимают процессы QA, но плохо понимают, как этого добиться с помощью имеющегося инструментария, а уж тем более как этот самый инструментарий подобрать исходя из задач. Хуже всего — когда они примеряют на себя роль «очень-крутого-парня-который-теперь-лучше-других».

2) Технические специалисты, уровня знаний которых достаточно, чтобы делать грамотные решения автотестов, но недостаточно для разработки. Как правило, далеки от QA и мечтают вырасти или в менеджеров, или в разработчиков.

3) Автоматизатор-единорог: технически подкован, чётко понимает процессы и задачи QA. В природе практически не встречается.

С таким составом, конечно тоже, можно добиться результатов, но это дело практически такое же лёгкое, как и найти работника из третьей категории.

4) Индусы и примкнувшие к ним. Люди, умудряющиеся сделать предположение, что KDT — это Keyboard Driven Testing, рисующие XPath-локаторы вроде //*[@id='some_id'] и т. п.

Во-вторых, мало кто думает о том, что автотесты — это такой программный продукт, исходный код которого будет переписываться чуть ли не чаще, чем тестируемая система, и поэтому поддерживаемость — один из ключевых факторов. К сожалению, в большинстве случаев код, который используется, не сильно отличается от кода, который генерируют модные и сильно платные рекордеры, то есть порой проще сделать заново, чем исправлять то, что есть.

В-третьих, есть неслабая мода устраивать псевдо-agile, когда тесты пишутся по новой функциональности, а подход в разработке не BDD/TDD (или банально не выделяется времени на поддержку тестов в актуальном состоянии).