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

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

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

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

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

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

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

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

5

Такой возник диспут.

"Тестировщик никогда не додумывает. Лучше задать вопрос. Вот этому стараюсь учить, да" (с)

Говорят нам преподаватели тестирования.

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

Даже сильнее скажу, то что я додумываю, считаю своим огромным конкурентным преимуществом перед теми тестировщиками, которые не додумывают.

Что я делаю не так?
И что я делаю так?

Прошу мнений в комменты.

P.S. На всякий случай поясню, что такое "додумывание". Для меня - это когда письменные или прочие требования не определяют, как должна работать программа. Тогда можно "задать вопрос", или можно "додумать" отсутствующее требование самому.

У меня возникает ощущение, что когда я слышу "нам обязательно нужна автоматизация тестов", в подавляющем большинстве случаев целью (явной или скрытой) этой автоматизации является перенос ответственности за непрофессионализм с тест-менеджеров и проект-менеджеров на будущих "автоматизаторов". Причем мне кажется люди это вполне понимают 🙂

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

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

Кстати, о тонких чувствах ручных тестировщиков, ушедших в автоматизацию, в субботу 04.07 в 16:00 мск выходит подкаст на Radio QA 🙂

1

Подумалось, что на собеседовании на должность тестировщика, я хотел бы проверить умение кандидата разбивать сложную задачу на множество простых. Ну и вообще увидеть понимание, зачем это нужно. Мне кажется, что если человек не умеет разбивать, то для него всегда придется разбивать задачу на такие куски, с которыми он умеет обращаться или он будет просто зависать на задаче без прогресса.  Фраза характеризующая проблему: "дай мне нормальное ТЗ"

Это не только про тестировщиков.

Что думаете по этому по поводу? Нужно проверять? Как проверять?

 

 

2

Коллеги и все, кто в теме.
Почему считается, что тестировщики ищут как сломать программу?

Я вот подумал, что когда я тестирую, я хочу узнать, как программа работает. При этом я просто использую программу по разным сценариям, обращаю внимание на детали и, иногда, даю свою оценку удобству и осмысленности выполнения. Может быть раньше и хотел "сломать", не помню уже... А сейчас - просто копаю глубже, и ошибки сами находятся, без каких-либо специальных деструктивных усилий. И другим советую то же :).

Исключения, конечно тоже есть - тестирование безопасности (например penetration testing), но я им не занимаюсь практически.
А вы, тестировщики, ищете как сломать?

Недавно на сайте QAHelp задавали вопрос, по каким признакам можно понять, что проекту скоро конец. Изучил вопрос и привел такие признаки:

  • когда в ваш офис начинают приходить деловитые посторонние и оценивающе поглядывать на мебель и оргтехнику
  • когда шеф внезапно составляет списки, в каком порядке получать зарплату и очень настаивает на том, чтобы его имя стояло первым
  • когда на входе табличка в офис сменилась на "Бутик У Жоржа - скоро открытие!!"
  • когда вас спрашивают, а не говорите ли вы, абсолютно случайно, по-китайски

и, наконец, самый главный признак:

  • когда руководитель проекта, направив взгляд в потолок, произносит: "а я бы не удивился, если бы мне сказали, что проекту конец".

А теперь об успехах юзабилизаторов. Компания LinkedIn твёрдой рукой ведет Slideshare к триумфу плохого UX во славу "требований". Казалось бы, что главное в платформе, демонстрирующей слайды? Слайды? Вряд ли, иначе трудно объяснить, почему на огромном экране они занимают примерно 10% пространства.

13

"Наш проект огромен, проверять нужно немерянное количество вещей, вручную это занимает очень много времени, да и в принципе то не всегда возможно проверить всё вручную, поэтому мы решили внедрять автоматизацию" (с) одна из первых реплик доклада

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

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

Надеюсь, всегда запоминается последняя фраза ;-).

Хочу поделиться фразами про качество и сделать их вольный перевод.
"You can't test quality into a software project; it must be built in."
"Quality must be built in, it cannot be added on."
Не нашел первоисточников, последние корни увели в сторону Тойоты второй половины прошлого века.

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