3

 

41NCHGYJCzLИзвестным Егор стал  благодаря своему блогу, в котором он и начал выкладывать свои будоражащие мир идеи об объектно-ориентированном программировании (ООП), а так же после знаменитого выпуска 105 подкаста "Разбор Полетов", где Егор провел неравный, но весьма увлекательный бой,  с хорошо подготовленной группой профессионалов, которые обстоятельно заклевали покритиковали его подход.

Данная рецензия именно на книгу, и меньше на сам подход Егора к ООП.

Хотя на обложке и нарисован кактус, как бы напоминающий нам о плачущих и  голодных мышах, книга мне определенно понравилась. Начну с пунктов, по которым она определенно побила подавляющее большинство выпускаемой сегодня технической литературы:

...читать далее Рецензия на книгу “Elegant Objects” Егора Бугаенко

5

Недавно заметил, что могу давать для одного и того же бага в одном и том же софте разные оценки "Severity" в зависимости от "истории болезни".
Например появляется какой-то незначительный баг, неудобство для пользователя - никаких последствий для функциональности. Логично ставлю "Minor". Если же неудобство появилось в новой версии программы, а до этого было "удобно" - то рука чешется поднять до "Moderate", и обычно я себе в этом не отказываю.
Логика довольна простая -"проблема" обнаруженная в месте, в котором пользователь столкнётся с ней впервые - легче, чем та же самая "проблема", которую пользователь не испытывал в предыдущих версиях. Ухудшение существующего положение вещей - всегда хуже, чем неоптимальное нововведение.

Получается, что оценка Severity не всегда является статичной по отношению к текущему состоянию приложения.

2

CV0BdxXWsAIvYoi

В субботу 23.04 буду в Москве на конференции по автоматизированному тестированию "QA Conference".
Я буду рассказывать про сравнительно узкую техническую тему - использование PageObjects в UI Automation.
И для заманухи - в докладе я покажу, в каких местах Copy&Paste кода - хорошая идея. :)

Этот и другие вбросы - в Москве, в гостинице "Салют" с 10 утра, приходите или смотрите online. Я думаю, что будет, как обычно, довольно живенько и спорно!

http://qaconf.ru/matrix.html

9

В описаниях вакансий на должность тестировщика чего только не увидишь. И тест-планы надо уметь писать, и багрекерами владеть. Столько-то лет опыта в тестировании веб-приложений, основы Java или C#. Желательно знать Selenium. Быть коммуникативным, умным, добрым.

И вот только одного на мой взгляд абсолютно важного для тестировщика скилла вы никогда не найдете в описании должности, или в тестовом задании: владение слепым методом печати.

Скажите, зачем вам тестировщик, который знает Selenium, если он печатает двумя пальцами, опустив голову в песок? Слепая печать (десятипальцевым методом, но если вы вдруг можете печатать вслепую меньшим количеством пальцем - ради бога) - базовый скилл любого айтишника, который изо дня в день должен писать большое количество связного текста, и особенно для тестировщика (баг-репорты, отчеты, тест кейсы, коммуникация с коллегами).

...грустно глядя на коллегу, который со скоростью черепахи вносит баг-репорт в систему...

1

Понадобилось как-то Петру скрепить вместе 30 страниц формата А4, инструкцию по работе с актуальным программным обеспечением. Пётр сидел в одном просторном офисе со всей командой, состоящей из 8 первоклассных программистов.

- Конечно, не вопрос! - отозвался Андрей, сосед напротив. - Держи мой степлер.
- Бзык, - сказал маленький степлер, который и близко не смог пройти через 30 страниц.
- Понятно! - сказал Андрей. - Нам нужна более большая модель. Ребята, у кого есть степлер побольше?
- У меня! - охотно пришел на помощь Кирилл.
Ручной степлер был действительно солидный и почти сшил 30 листов - один кончик скрепки даже торчал на пол-миллиметра из бумаги.
- Эх, не везёт. - вздохнули ребята. - Ну ты ж понимаешь, мы программисты, мы с экрана читаем, нам бумага ни к чему.
- А может лучше дыроколом...? - предложил Иван, и тут Олегу пришла в голову идея. - А ты сначала сшей 3 кусками по 10 листочков, и потом отдельные части между между собой!
Какой вариант выбрал Пётр?
Пётр был тестировщик, поэтому он спустился на один этаж в бухгалтерию, где промышленный степлер легко скрепил все 30 листочков между собой одной надёжной стальной скепкой.

-------------------------------------------------------------------------------------------------------------------

Какая мораль у данной сказки. Часто бывает, что программисты не способны самостоятельно выйти из своего контекста. В данном случае они действительно охотно пытались помочь, и даже очень креативно придумали костыли и альтернативные решения, которые они могли бы самостоятельно исполнить. Но иногда программисту трудно представить, что лучшее решение лежит "не на его этаже", то есть, например, не в написании кода, а в организационных изменениях.

Как писали великие  (Jerry M. Weinberg, кажется) -  каким бы странными и глупыми вам не казались решения, которые принимались в прошлом, наверняка в момент их принятия были вполне логичные и разумные аргументы в пользу этих решений.

Переделанный пример из личного опыта.

Вижу в приложении (допустим, портал частных авто-услуг) примерно такую формочку (прокат частных авто):

Untitled

Вверху поле, где нужно задать примерные пробег автомобиля. Внизу - выбрать максимальное разрешенное расстояние для поездок за день. Везде точка разделяет дробную часть, запятая - тысячи (американский стандарт). Да, внизу записаны 20, 50 и 80 километров. А вверху 25 тысяч тех же километров.

Казалось бы нули в дропдауне - абсолютно бессмысленные и лишние, нет? Кому могла в голову прийти идея так реализовать?

Разгадка такая.

...читать далее О странных решениях

32

Свежими постами от Макса Шульги и дискуссиях в твиттере и фейсбуке на русском и английском языках навеяло. 

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

Я надеюсь, что теперь уж все вопросы закрыты и вектор развития отрасли задан!

5

Поразмыслил на тему, почему я начал считать, что все, кто непосредственно участвуют в процессе разработки программного обеспечения - тестировщики, аналитики, архитекторы, дизайнеры, программисты конечно - разработчики. А не только те, кто умеют программировать и программируют.

Похоже, что "виной" тому - Scrum. Дело в том, что одно из базовых понятий Scrum-е -  Developement Team (команда разработчиков). Теперь если понимать это буквально и консервативно - то выходит, что Development Team состоит только из людей, которые умеют программировать (к сожалению, много людей поверхностно понимающих Scrum именно так и думают). Что в корне ошибочно - на самом деле в команду входят все вышеперечисленные роли, если они важны для успешной реализации требований проекта.

Логичный выход из ситуации для меня - считать и называть "разработчиками" всех, кто принимает участие! В некоторых случаях это будет даже представитель клиента (если он является частью Scrum команды). Scrum безумно популярен в мире, поэтому приходится это учитывать. А если бы не он, возможно, я бы не был против называть разработчиками только программистов.

Ну и вообще,  почему бы и нет?

Эту ошибку при написании ui автотестов я, как мне кажется, встречаю чаще
всего.

Update. По просьбам трудящихся обновил пример с более абстрактного, на более жизненный. Суть осталось неизменной.

Представьте, у вас есть такой простой набор тестов.

Набор чеков в коде, в стиле Selenide, будет примерно таким:

Видите ошибку?

Если вы просто повторили язык теста, то чеки пройдут положительно и тест будет "зелёненьким", даже когда "Оплатить" будет всегда "disabled" (в частности, после выполнения заполнения корзины).

Более правильным, конечно, будет вариант

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

Пришел на новый проект. Через неделю не могу в апп залогиниться в браузере со своего компа, а с других могу и автотесты с моего же компа - логинятся с теми же браузерами. Программист ищет баг уже 3-ий день, сегодня вокруг него еще 5 коллег сидело.
Я вообще не могу понять, как написать такой код, даже если захотеть, с такими странными эффектами.

А вы говорите не нужны юнит-тесты.

Дали мне сегодня весь проект запустить. Скачал из git. Запустил на сборку. Выдаёт ошибку в юнит-тесте.
Окей - говорю программистам. У нас не выдаёт, отвечают. Запускают - действительно не выдаёт, у меня при запуске теста из IDE тоже не выдаёт. А из командной строки - выдает. Программисты, хотите упражнение? Метод модифицирует web элемент таг с атрибутами вроде:

И assert сравнивает строковый результат, и у меня из командной строки валится потому что атрибут один меняет порядок (сперва attr2, затем attr1). Примерно так:

Симптомы - выше (где-то меняет, где-то не меняет). В чем проблема? Решение ниже.

...читать далее Походные заметки про простое тестирование