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

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

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

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

3

Очередная критическая разборка доклада, на этот раз на очереди Андрей Ладутько с беседой об аудите:

В целом доклад мне показался интересным, но в некоторых моментах неполным или спорным. Мне показалось, что в начале Андрей несколько нервничал и спешил, затем темп стал лучше и ведение доклада стало очень уверенным.

Начну с критики по содержанию доклада:

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

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

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

...читать далее Линч-пакет: Андрей Ладутько “Как оценить процесс тестирования на проекте”

1

За этот слайд нужно исключать из автоматизаторов! Скажите же мне, что лектора пытали производители тулов для автотестов!!
Тестирование__Занятие_№11_-_YouTube
Полностью лекцию можно посмотреть тут, увы это не единственное неграмотное место в ней.

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

П.С. из комментов (Дмитрий Новоселов): Типа, чем больше автотестов, тем больше убыток? Интересная мысль, имеет право на существование 😉
И еще комментария (Алексей Баранцев): Главное не запускать автотесты слишком часто. А то, гм, прибыли становится слишком много :)

2

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

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

SevPrioComicsFull1
Смотрите, задавайте вопросы!

 

1

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

Рекомендация по безопасности от OWASP (описано в линче): удаляйте сессию на сервере для критичных приложений через 15 минут неактивности, для среднекритичных - через 30, для остальных - через час.

Теперь история:

Время от времени я планирую сложные маршруты на сайте Deutsch Bahn (Немецкая Железная Дорога). Ну там, пересадка там или сям, часом раньше - часом позже, тут чуть быстрее - а тут чуть дешевле. Тот, кто ездит или летает по новым маршрутам меня поймет. И вот нужное соединение найдено! Можно расслабиться и заскочить в фейсбучек, ну на 3 минутки всего. И вот эти козлы дропают мою сессию через 30 минут!!! А я же всего через час вернулся!

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

Рекомендации - хорошо, рекомендации и здравый смысл - лучше!

 

2

Продолжаем разбирать доклады с SQA Days 17 в жестком стиле, но с согласия докладчика :). Сегодня у нас в пакете доклад Игоря Бондаренко "Безопасность мобильных приложений. Что тестировать?" 

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

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

Серьёзных огрехов, честно говоря, вообще замечено не было, но так как формат линча предполагает критику - будем докапываться к мелочам :). Замеченные ошибки без градации - все не очень серьёзные.

  • Перемешаны английские и русские термины в слайдах

...читать далее Линч-пакет: Игорь Бондаренко “Безопасность мобильных приложений”

4

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

Первый под горячую руку попал доклад - Сергея Атрощенкова с SQA Days 17 в Минске
Для удобства чтения я повторю слайды и видео тут:

 

...читать далее Линч-пакет: Сергей Атрощенков “Моделирование угроз безопасности”

1

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

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

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