10

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

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

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

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

1

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

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

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

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

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

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

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

Untitled

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

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

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

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

33

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

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

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

5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1

Записали выпуск Radio QA про тестирование и годы.

http://radio-qa.com/vypusk-9-testirovshhik-superstar/
А как считаете вы? С возрастом тестировщикам становится тяжелее или проще? Заполняйте опросы и пишите ваше мнение в комментах!

 

1

По мотивам ленты о тестировании подумалось:

Как_использовать_Agile_Manifesto_в_мобильном_тестировании___A1QA_Блог

 

Две самых крупных ошибки этого поста

  1. Выделение из 4 столпов Agile манифеста "двух ключевых".
  2. И что гораздо хуже, вычленение тестирования от процесса разработки (уж особенно в Agile)

Я думаю, пост должен помочь продавать тестирование в Agile-проект заказчикам, что я в принципе приветствую. Но не любыми же средствами :).

Запомните, тестирование - это часть процесса разработки. Я считаю, что Agile разработку нужно продавать, включая в неё тестирование без искусственного отделения от программирования.

Вот сказанул тут в чатике, а они это раз - и на картинку!А вы что думаете? Огрехи программиста увидеть проще, чем огрехи тестировщика или есть тонкости?

Если тестировщики постоянно сменяются, то определить качество результата можно лишь слишком поздно. Из этого делаю вывод, что тестировщиков нельзя заказывать на вес и количество, а надо вырабатывать для проекта надёжный и качественный канал информации.