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 в Минске
Для удобства чтения я повторю слайды и видео тут:

 

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

7

В пятницу 29 мая, в Минске буду читать доклад на SQA Days 17.

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

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

Кто после доклада приведет мне линки на советы и приёмы аналогичные указанным - получит пиво/шоколадку 🙂

SeverityVsPriority_Рус_key

До встречи на докладе!

 

1

Первое видео с квартирника про IT работу и жизнь за рубежом, который я вел в Новосибирске. Несколько оффтопиком к теме блога, в нем о тестировании говориться не будет.
Как и ожидалось, все темы пройти не успели - эксперты, поначалу неуверенно высказывавшиеся о желании участвовать, пришли в полном составе!
И это несмотря на то, что квартирник был поставлен первым слотом в 10 утра между первым и вторым днём конференции (ну вы поняли). 🙂
Местами было занудно, но все равно квартирник занял второе место в побочной секции квартирников и мини-докладов.

 

И сразу онтопиком квартирник, занявший 3-ее место про тестирование с ведущей Таней Писчасовой "Мир без тестировщиков. Миф или реальность?"

2

Команда, в которой 10 разработчиков и ни одного тестировщика похожа на футбольную команду без защитников. Кстати, и 1 защитник особо погоды не меняет.
Из прошлогоднего креатива про то, как бы было, если бы в футболе размышляли, как некоторые личности из IT сферы.

- Мы должны выиграть в сжатые сроки, поэтому нам более важно иметь много нападающих.
- Защитники стоят ненамного дешевле нападающих, но практически не участвуют в голевых моментах.
- У нас просто нет денег на защитников, пока обойдемся тем чем есть.
- Когда мы забьем достаточно голов, наши нападающие уйдут помогать в защиту.
- У нас нападающие тоже защищаются (иногда)!
- Защитников выпустим в самом конце игры, если к тому моменту пропустим слишком много голов.
- (Перед началом матча) Зачем защитники? Нас же еще никто не атакует.
- Очень хороший защитник, но ведь он хочет зарплату, как у нашего среднего нападающего, не можем взять.
- Защитник - первая ступенька в карьере футболиста. Хорошие защитники через пол-года идут в полузащитники, затем в нападающие.
- Главная задача защитников - автоматизировать защиту.
- Вратарь (ака тест менеджер): я не должен уметь играть ногами и головой, это скиллы защитников.
- Нападающий: с какого я в свою половину поля пойду - у нас же четыре защитника есть.
- Защитник нам не нужен, он будет треть матча сидеть без работы!
- Пока наша команда атакует, защитники могут приседать на месте, чтобы улучшать свою физическую форму.
- Мы очень дешево закупили пожилых близоруких астматиков с плоскостопием. - Ничего, для защиты сгодятся!

(с) моё

- В защитники уходят те, кто не могут стать хорошими нападающими, это недонападающие.

(с) Андрей Ладутько

 

11

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

Я так часто иронизирую над автоматизацией тестирования, что может возникнуть ощущение, что я её ненавижу или считаю малозначимой. Это не так. Вот на днях как раз отловил довольно серьёзный баг, который *как я сперва подумал* ни в жизни не обнаружил бы, тестируя вручную. Автоматизируя тест-кейсы веб приложения, внезапно заметил, что вместо одного элемента окна диалога мне вернулся массив. Оказалось, что диалог, который используется во многих местах приложения всегда создается после открытия, но не удаляется из кода страницы после закрытия. Со временем "мусор" накапливается и тормозит отображение страницы.

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

...и вот, что оказалось. "Нас часто спрашивают"™, как выжить тестировщику, который не умеет писать программный код, в современном жестоком IT-мире, где всякий встречный пытается автоматизировать всё, что не успевает на счет 3 залезть на дерево. Отвечаю так. Приобретайте новые навыки, конечно, но... Не надо путать навыки автоматизации, без которых, *как я все еще не сомневаюсь*, можно обойтись от слова совсем, и навыки технической, пользовательской и исследовательской грамотности! Буквально неделю назад, я посмотрел небольшой курс c CodeSchool  (на сайте много неплохих бесплатных курсов, и еще больше хороших платных) про использование Developer Tools в Chrome, почерпнул для себя много нового, в частности методику проверки утечки памяти вручную (вот например, соответствующая часть инструкции на сайте Chrome). Выясняется, что быстрее и надежнее вышеупомянутую ошибку (и многие другие) можно было выявить ручным тестированием с использованием технических средств.

И вот уже закругляя, хочу поднять провокационный вопрос. Одна из важных задач тестирования - нахождение *новых* ошибок, вы со мной согласитесь? Может ли быть, что автоматизация тестов с этой задачей не может справиться, ну или если справляется, то *значительно хуже* чем ручное?

P.S. В Фейсбуке горячая дискуссия:  https://www.facebook.com/alexei.vinogradov/posts/1109312402419661