Автор: admin

4

Автор Опубликовано 4 комментария

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

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

Сам забываю об этом, поэтому решил написать пост для себя, в качестве напоминания.

5

Автор Опубликовано 5 комментариев

Рядовой Сидоров, если вы такой умный, то почему строем не ходите!? (неизвестный прапорщик из известного анекдота)

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

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

Для того, чтобы понять как работает двигатель внутреннего сгорания, не обязательно уметь собирать двигатели. Образованный человек сможет понять, как работает программа без владения языком программирования. А сможете ли вы объяснить ему или другому стороннему программисту?

Во время для саморазвития можно ездить на конференции, общаться с коллегами-профессионалами, писать в блоге, изучать бизнес домен, процессы разработки программного обеспечения, прокачивать коммуникационные навыки. И учить программирование тоже можно и нужно! Нравится - так учите на здоровье! Не уверены - попробуйте, это вовсе не так сложно!

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

12

Автор Опубликовано 12 комментариев

Давайте рассмотрим типичную для многих современных проектов ситуацию: мы начинаем только с программистами-на-все-руки (нет времени объяснять, надо кодить). Через некоторое время выясняется, что есть проблемы с качеством. Почему?

Мой ответ - потому что создаём много кода (умеем же), но мало проверяем код и идеи тестированием (потому что не умеем). Многие проекты осознают и берут в проект тестировщика (или нескольких). И теперь объясните мне внятно те, кто продвигают идею "польза от тестировщика только, если он умеет писать код" - вы действительно хотите чтобы в проекте стало ещё больше кода?

Более логичным выводом является то, что тестировщик должен уметь писать код, если в проекте создаётся слишком мало кода и этот код успевает отлично протестироваться. Вы знаете такие проекты? Сводите меня туда на экскурсию, я хочу у вас учиться!

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

Кесарю - кесарево, а слесарю - слесарево.

CF4a68gVIAEcZp0

4

Автор Опубликовано 4 комментария

 

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

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

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

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

5

Автор Опубликовано 5 комментариев

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

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

2

Автор Опубликовано 2 комментария

CV0BdxXWsAIvYoi

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

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

http://qaconf.ru/matrix.html

10

Автор Опубликовано 10 комментариев

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

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

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

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

1

Автор Опубликовано 1 комментарий

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

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

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

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

Автор Опубликовано Оставить комментарий

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

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

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

Untitled

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

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

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

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

33

Автор Опубликовано 33 комментария

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

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

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