Недавно прочитал пару статей про “правильное” описание дефекта и решил в очередной раз потормошить тему управления дефектами на проекте. Я уже писал на тему того, какие типы дефектов существуют и как с ними быть в адекватной команде.
Давайте задумаемся, сколько усилий тратится на самом деле при работе с дефектом:
В результате, один и тот же сценарий запускается не менее 7 раз. А в большей части случаев гораздо больше… И все это делается руками! А теперь добавьте сюда проблемы разряда “это не повторяется на моей машине” и “у меня нет времени смотреть на новые баги”.
Оно и понятно – усилия со стороны разработчика на ручной прогон сценариев очень велики, а разработчики ленятся делать что-то руками. Получая информацию о дефекте, разработчик заранее понимает, сколько усилий ему нужно будет сделать и относится к этому негативно.
Тут притаилась и еще одна проблема – интерпретация информации. Тестировщик пишет сценарий для воспроизведения, вкладывая в него имеющуюся у него информацию. Потом разработчик ее пытается “декодировать” при чтении сценария. И этот процесс далеко не безошибочный. Из-за этого так часто и возникают проблемы взаимопонимания.
Ну и последняя проблема – мы все знаем, что дефект может проявиться снова. Поэтому сценарий должен быть добавлен к регрессионному тестированию. А это значит, что его будут запускать каждый раз при тестировании продукта, что требует еще больше времени.
Так может стоит сразу вкладываться в автоматизацию для дефектов? Ведь вопросов об объеме ручной работы тут не стоит. Мало этого, это будет ручная работа не только тестировщиков, а и разработчиков. Важно отметить, что на коротком интервале можно даже не заботиться о поддерживаемости сценария – ведь всегда можно будет запустить ту же версию кода и на ней прогнать сценарий. А это очень сильно облегчает автоматизацию. Возможно, если у вас и так уже имеется автоматизация, то сценарий будет всего лишь использованием уже реализованных шагов со специфическими данными и новыми проверками.
Если тестировщики вместо написания очередной “истории дефекта” будут предоставлять автоматизированный скрипт, то многих перечисленных выше проблем можно будет избежать. Вдобавок, можно будет сразу же добавить написанный сценарий в имеющийся тестовый набор или как раз и положить начало автоматизации тестирования. Задумайтесь об этом на досуге! 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Медленно, но верно мы подбираемся к юбилейному выпуску рубрики “полезное чтиво”. Трудно представить, что позади уже почти 50 выпусков, которые пополняли багаж знаний наших постояннх читателей. Итак, что интересного подобралось на этой неделе:
А вот список интересного видео для просмотра:
Читайте и набирайтесь новых знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Наш “Клуб анонимных разработчиков” продолжает регулярные встречи и на этот раз темой мы обрадуем Java разработчиков. 8 ноября пройдет очередная встреча на тему “Spring VS JEE”.
С появлением JEE 5 не угасает полемика вокруг темы Spring или JEE. Евангелисты с обоих сторон не устают ломать копья, интернет переполнен полезными и не очень сравнениями подходов. Совсем недавно прошли конференции Java One и Spring One, где вендоры отчитались о своих новинках. Мы бы хотели присоединится к дискуссии и, руководствуясь фактами, разобрать нынешнее состояние обоих стеков или скорее экосистем, рассмотрев их сильные и слабые стороны.
Сторону Spring будут представлять основатели SpringByExample.com.ua Алексей Резчиков и Евгений Скрипник. Алексей Резчиков – опытный Java разработчик и тимлид. В разное время работал project, resource, development и competency manager. Последователь Agile/Lean, а также сторонник XP инженерных практик. В данный момент занимается консалтингом по Testing Automation, Continuous Integration & Continuous Delivery. Евгений Скрипник – бывалый Java/Ruby разработчик, много лет работающий на Spring, программист-прагматик.
На стороне J2EE будет выступать Виктор Тесленко – архитектор по разработке ПО и Java-тренер с многолетним опытом.
Присоединяйтесь к дискуссии, будет интересно!
Встреча пройдет в четверг 8 ноября. Место проведения мы объявим ближе к дате мероприятия. Это связано с тем, кто число членов клуба постоянно растет и мы рискуем не влезть в уютный Киевский офис компании DataArt. Этот офис полюбился членам клуба своей уютной обстановкой и наличием всего необходимого для продуктивного общения. Но, по итогам прошлых встреч, есть риск, что все желающие не поместятся.
Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я заметил, что больше всего сложностей с внедрением Agile подходов вызывает работа над приемочными тестами. Кто-то вообще над ними не работает, кто-то делает это “для галочки”. Но, на мой взгляд, это одна из самых важных и полезных Agile практик, особенно в итеративных подходах.
Все начинается с митинга по планированию итерации. Задача, которая стоит перед командой и Product Owner – не просто обсудить план работ на следующие две недели, но и зафиксировать как можно больше деталей, чтобы избежать проблем в конце итерации. На каждую итерацию команда и Product Owner подписывают внегласный контракт о выполнении определенного объема работ, который определяется совместно. Но в любом договоре стоит оговаривать правила приема-сдачи готовой работы. Без четко сформулированных приемочных критериев все договоренности остаются размытыми и обе стороны могут этим воспользоваться.
Приемочные критерии становятся самой важной целью планирования. Их четкая формулировка позволяет обеим сторонам избежать проблем и недопониманий. Процесс обсуждения приемочных критериев порождает массу вопросов, которые могли не появиться в противном случае. Приемочные критерии станут в дальнейшем почвой для разработки автоматизированных приемочных, функциональных, интеграционных и модульных тестов. Любой написанный тест должен так или иначе иметь отношение к приемочному критерию.
Не менее важный аспект приемочных критериев – хранение информации о функциональности. Когда ваш продукт развивается интенсивно, в него быстро добавляется все новый и новый функционал. Но через некоторое время удержать все это в голове становится очень и очень непросто. Приемочные тесты, которые порождены правильными приемочными критериями, способны не просто сохранить эту информацию, но и привязать ее напрямую к приложению. То есть, в любой момент времени мы имеем возможность не просто освежить в памяти работу определенной части приложения, но и посмотреть ее в действии.
Ну и наконец, приемочные тесты становятся своего рода охранниками реализованной функциональности, живой постоянно активной спецификации к ней. Это своего рода регрессионная защита, цель которой постоянно контролировать сформулированные однажды приемочные критерии и не допускать их поломки в будущем.
Тема очень интересная и я показал лишь несколько моментов, связанных с работой над приемочными критериями и тестами. Для более детального изучения я рекомендую книгу Gojko Adzic “Specification by Example”. Книга действительно очень классная и в прошлом году стала самой популярной книгой на Agile тематику. К сожалению, у Gojko не получилось вырваться на нашу конференцию XP Days Ukraine в этом году. Но мы пригласили его партнера David Evans, тренера и разработчика с 25-летним стажем в IT, приехать и провести тренинг “Specification by Example” перед конференцией. Тренинг подготовлен по материалам книги и будет полезен всем, кто работает в Agile команде, начиная от бизнес аналитиков и заканчивая разработчиками. Данный тренинг в Европе проводится по цене около 1500 евро, но мы сумели договориться на специальную цену для Украины – 3200 гривен. Тренинг пройдет 14-15 ноября и еще есть 5 вакантных мест. Торопитесь зарегистрироваться!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
На прошлой неделе я так и не нашел времени на публикацию, поэтому на этой неделе выпуск будет толще и интереснее:
А вот список интересного видео для просмотра:
Читайте и набирайтесь новых знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Эта статья – вольный пересказ статей Майкла Болтона на тему, что не является исследовательским тестированием.
Зачастую, люди, которые ленятся разобраться с принципами, которые заложены в подход исследовательского тестирования, попадают под разного рода сомнения. В этой статье мы детально разберемся в самых частых заблуждениях относительно исследовательского тестирования.
Что не так с этой трактовкой? Давайте представим как происходит процесс тестирования по так называемому “туру”. Любимый пример Джеймса Виттакера (автора книги Exploratory Software Testing):
Вы турист, летите на самолете в Лондон, чтобы отправиться за покупками. Вы читаете карту и отмечаете места, в которых хотели бы побывать, при этом рассчитываете маршрут и время, чтобы успеть в каждый магазин. По прилету в Лондон вы начинаете следовать намеченному плану. Вы заходите в каждый магазин, следуя своему маршруту. Выбираете вещи, некоторые покупаете, некоторые нет. Также находите бракованные вещи и показываете их менеджерам магазина. И так далее пока не дойдете до последнего магазина, или пока у вас не закончатся деньги.
Давайте спроецируем это пример на тестирование. Что получается? У нас есть набор чекпоинтов, быть может чеклист end-2-end набор тестов, который указывает нам на порядок выполнения действий. Не нужно долго думать, чтобы ответить на вопрос “На что похоже такое тестирование?”. Конечно же – это скриптовый подход к тестированию.
Каким должен выглядеть процесс, чтобы он был похож на исследование? В первую очередь нам нужна цель. Говоря о Лондоне, целью может быть – купить красивое пальто или зонт. А где, в каком магазине и в какое время – не важно! Главное – результат. Что использовать для этого – дело сугубо индивидуальное. Кто-то может составить план, кто-то может доехать до центральной улицы и спрашивать у прохожих дорогу к ближайшему магазину одежды, а кто – банально зайти в первый попавшийся магазин и купить первое попавшееся на глаза. У каждого тестировщика свой стиль тестирования. И это правильно! Главное – это достижение цели, конечного результата. В этом разрезе, тестировщик более похож не на туриста, а на исследователя, который ищет пути решения поставленной проблемы.
Бред, вранье и полная чушь! Одно из самых частых заблуждений относительно исследовательского тестирования. Чаще все встречается у неграмотных Agile тестировщиков. Как вы можете заниматься исследованием лишь один раз в неделю? А чем же вы тогда занимались остальное время – тестировали? Нет, тогда вы не тестировали – вы проверяли на соответствие (checking). Исследовательское тестирование – всеохватывающий процесс, это подход к тестированию, а не одна из доступных техник. В пример этого заблуждения можно принести всем известные Agile квадраты.
Очень глупо было размещать Exploratory Testing в квадрате Q3. Почему? Давайте подумаем, можем ли мы делать исследования на этапе написания unit-тестов? Можем. Разработчики тоже могут исследовать код приложения, чтобы написать больше тестов. Проведение code review тоже можно отнести к исследованиям. Тоже самое касается остальных типов тестов. Например, вы можете записать в режиме исследования скрипт для нагрузочного тестирования, используя BadBoy. И запускать его при помощи JMeter с разными типами нагрузок. Кому интересно детальное опровержение этой матрицы – посмотрите выступление Элизабет Хендриксон на последней конференции CAST.
Если вы когда-то услышите эту фразу – смело ругайте этого человека. Какие инструменты можно применять для проведения исследовательского тестирования? Да любые! Это и скриншоттеры, и рекордеры, и логгеры. Используя автоматизированные скрипты можно подставлять разные массивы данных и тем самым заниматься исследованием системы автоматически, конфигурируя текстовые или xml-файлы. Тот же Selenium IDE и прочие record-and-play инструменты могут облегчить работу тестировщику во время проведения тестовой сессии.
Еще одно из часто упоминаемых заблуждений. Быстрые проверки или, как их еще принято называть, quick tests могут проводиться как в исследовательском, так и скриптовом режимах. Для примера скриптового подхода, вы можете описать набор smoke или sanity тест кейсов для вашего приложения и тестировать по ним. В исследовательском тестировании же можно использовать мнемоники и туры для проведения быстрого тестирования. Но обратите внимание, что не все туры бывают быстрыми, и не все быстрые проверки – это туры. Полный список – на сайте Майкла Болтона.
Напоследок – самое сладкое заблуждение, которое полно необоснованных убеждений. Все тестировщики, по долгу службы, привыкли к стандартному течению обстоятельств. Читаем требования, пишем тест кейсы, ждем пока разработчики что-то напишут и уже по этим тест кейсам приступаем к тестированию. Я не говорю, что тестирование по тест-кейсам это плохо. Напротив, в некоторых контекстах без них никуда: медицинское, авиа, банковское ПО. Но везде должен быть разумный предел того, что документировать, а что – нет. Самый ценный совет, который можно здесь дать – “Документируйте только то, что нужно”. Узнайте у членов вашей команды, менеджеров – какие документы им нужны, чтобы контролировать выполнение ваших обязанностей без постороннего вмешательства? Подумайте сами, какие документы вам необходимы для проведения тестирования. Но всегда держите в голове – “Keep it simple”. Кстати, то же самое имелось ввиду в Agile манифесте “Working software over comprehensive documentation”. Тестировщику нужно заниматься тестированием, а не администрированием процесса, точно так же как программисту – написанием кода, а не спецификаций. Но везде должен быть баланс. Если для поддержания рабочего процесса необходим документ – лучше его написать. В исследовательском подходе к тестированию документировать можно что угодно и сколько угодно. Главное договориться о том, что должно попасть в отчет тестовой сессии и какие сценарий следует формализовать.
Будьте готовы принять вызов и отстоять точку зрения о правильном исследовательском тестировании. Приводите примеры из своих контекстов. Задавайте вопросы и критикуйте, ведь этих пяти примеров может быть недостаточно, чтобы полностью ответить на вопрос “Что не есть Exploratory Testing?”
Хотите научится применять этот подход на практике? 26-27 октября в Киеве будет проходить тренинг “Exploratory Testing”. На множестве практических заданий под руководством опытного тренера вы освоите исследовательское тестирование и сможете применять его в своей работе.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
В эти выходные я выступал еще на одной конференции – AgileEE 2012. Долго не буду томить рассказом о том, как прошла конференция. Расскажу только, что мне понравилось, а что не очень. Начнем с позитивного:
Что не понравилось:
Я выступал на тему эволюции Agile процессов. Что там дальше за Scrum? Куда двигаться опытной команде? Почему и как эволюционировали современные Agile процессы? На эти и другие не менее важные вопросы я постарался дать ответ в своей презентации:
Судя по количеству оставленных карточек со словами благодарности, доклад участникам понравился и показался полезным.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я решил на этой неделе все таки опубликовать выпуск полезного чтива:
А вот список интересного видео для просмотра:
Читайте и набирайтесь новых знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Во вторник я вернулся с конференции YaC 2012 и наконец-то нашел время поделиться своими впечатлениями. В первую очередь, я хочу поблагодарить организаторов за приглашение выступить и заботу о докладчиках на протяжение всего пребывания в Москве. Для нас все было организовано отлично, начиная от встречи в аэропорту и заканчивая after-party. Но обо всем по порядку.
Я прилетел в воскресенье, потому что организаторы хотели провести экскурсию по офису Яндекса и показать площадку, где предстояло выступать. Да и зачем рисковать с пробками в день конференции. 🙂 Москва встретила не очень радушной погодой по сравнению с теплой осенью в Киеве. Таксист с табличкой Яндекс встретил в аэропорту и отвез в гостиницу “Космос” – огроменное здание советской постройки к олимпиаде.
Выглядит гостиница очень монументально, да и номеров там несчетное множество. Правда советская атмосфера в отеле царит до сих пор и в этом плане мало что поменялось. В воскресенье и понедельник там устраивали конференцию 1С-ники, поэтому в фойе болтался гигантский шар с надписью 1C.
Площадка конференции в этом году располагалась в ВДНХ. Я пришел в то время, когда сцены еще только обустраивались и сразу удивился количеству аппаратуры, которое устанавливали в разных местах. Создавалось ощущение, что будут работать десятки камер и снимать каждый закуток. Сцены было 4 и достаточно несбалансированных: около 2000 (не знаю сколько точно), 350, 350 и 500. Секцию тестирования организаторы поставили на главную сцену после обеда, что меня удивило, потому что редко когда тестированию выделяют такие большие залы. 🙂
Вечером докладчиков собралось побольше и нас дружно повезли в офис Яндекса. Перед этим я успел прокатиться вот на таком забавном аттракционе:
Сначала нам провели экскурсию по офису. Офис достаточно симпатичный, для себя отметил большое количество переговорок и велосипедов на улице. Еще в офисе работает удивительная система охлаждения без кондиционеров на трубах с водой, которые спрятаны под “деревянными обоями”. Офис сделан с должным уровнем креатива – повсюду стены, на которых можно писать и рисовать маркерами, что сотрудники и делают. 🙂 Было удивительно, что так мало людей сидят с несколькими мониторами, хотя может просто мы были не в комнатах разработчиков. Фотографировать, к сожалению, запрещено.
После экскурсии организаторы сделали фуршет с вином и кучей еды. Нас было не очень много, но зато все познакомились и отлично поболтали. На нашей секции должен был выступать Anthony Voellm из Google, который рассказал много интересного о работе в Google и отношении к тестированию в этой компании. Вечер мы решили продолжить со старыми знакомыми из Яндекса в ближайшем пабе…
С самого утра было понятно, что в ВДНХ что-то происходит для IT-шников. От метро тянулись многочисленные группы людей с рюкзаками IT-шной внешности. Причем много и постоянным потоком. На подходе к 75-ому павильону нас ждали очереди из участников конференции. Докладчики получали свои бейджи в отдельной VIP комнате, а остальные – в забавных машинах, которые печатали бейджи на месте по QR-коду. Не видел таких до этого, прикольное решение. Все участники получили мешки с кучей ништяков от Яндекса: конфеты, наклейки, протирашки и т.д.
А народ все прибывал и прибывал. К моменту открытия в главном зале все было забито. Поговаривали, что в остальных залах тоже было полно народу, которые смотрели открытие в трансляции. Технически сцена была организована просто великолепно: 4 огромных экрана, целая команда для работы со звуком и трансляции с камер, специальные мониторы перед сценой для докладчиков, классные микрофоны и мощный звук. В общем, придраться было не к чему. На втором этаже с участниками знакомился забавный робот, который был очень общительным и милым:
Открывали конференцию несколько ведущих людей в компании. Яндекс на этот день подготовил немало сюрпризов – свой собственный браузер, несколько новых сервисов и новый логотип. Браузер и логотип стали предметом жарких дискуссий в интернете. Статья на Хабре собрала сотни комментариев и множество примеров народного творчества на тему нового логотипа. Не берусь судить насколько полезным будет новый браузер, но с точки зрения автоматизации тестирования он точно новых проблем не создаст. 🙂
Я побывал на нескольких докладах, из которых отметил бы доклад из фронтенд секции “Профилирование и ускорение сложных JavaScript-систем на примере API Яндекс.Карт”. Тема действительно интересная и собрала толпу народа (стоя слушали столько же участников сколько сидя). Незаметно подошло время обеда и я обрадовался, что был докладчиком. Очереди за едой были огромными. Оно и неудивительно – ведь на конференции было 3-4 тысячи человек. Ближайший МакДоналдс тоже не остался в обиде и, думаю, заработал недельную выручку за день. 🙂
После обеда началась наша секция тестирования. Я остался очень доволен выступлениями. Не ожидал услышать столько всего интересного, причем в такой живой подаче. Мне кажется, что тестировщики должны были уйти с конференции с целой пачкой новых идей. Организации автоматизации тестирования в Яндекс многие компании могут только позавидовать. Лично мне нравятся тестировщики из Яндекс за то, что, когда им рассказываешь новые идеи, они говорят: “Классная идея, надо подумать как у нас применить..” вместо “Это невозможно в нашей команде, да и вообще в нашей компании!”. Вот презентация моего выступления, видео будет позже:
Наша секция была последней на конференции, но на этом все не закончилось. Все организаторы и докладчики отправились праздновать и веселиться на after-party в паб. Там было много общения, пива и веселья. Не смотря на завершение конференции, нас отвезли в отель и на следующий день утром доставили в аэропорт. Такая забота оставляет только приятные впечатления.
Подводя итоги, я хочу сказать, что это была действительно самая большая и интересная технологическая IT конференция в Восточной Европе с кучей разных секций, большим количеством докладчиков как из Яндекса, так и приглашенных, а также очень разношерстным составом участников. Желаю конференции и дальше развиваться и набирать обороты. Спасибо организаторам за возможность выступить! В следующем году приеду обязательно, даже если и не в статусе докладчика…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
25 сентября я принял участие в онлайн конференции Chief ConfeT&QA с докладом “Почему тестирование занимает так много времени”. Теперь я могу смело опубликовать материалы доклада, потому что по результатам зрительского голосования он занял первое место. Мой доклад выбрало больше 50% проголосовавших участников. Спасибо всем, кто за меня голосовал. Я рад, что сумел донести до вас полезные мысли.
На этот доклад меня вдохновила статья Болтона, которая в далеком 2009 году заставила меня пересмотреть взгляды на тестирование и помогла в дальнейшем избегать очень многих проблем: часть 1, часть 2. С тех пор эта тема является обязательным блоком моего тренинга “QA в Agile”.
О содержании доклада говорить нет смысла – проще просто его посмотреть. Есть версия слайдкаста:
Есть вариант видео:
Участники задавали много вопросов. Ответы на самые интересные я приведу тут:
Вопрос: Работали ли вы когда-нибудь тестировщиком?
Нет, я не работал тестировщиком. Но мне не раз приходилось ставить процесс тестирования на проекте с нуля, а также много-много раз консультировать компании по вопросам тестирования и проводить тренинги на эту тему.
Вопрос: Николай, так вроде бы это ты тот человек, у которого в проекте нет тестировщиков. Два предположения, это только предположения или все таки опыт?
От вас ничего не утаить. 😉 Да, на текущем проекте мы уже 3 года живем без тестировщиков. Параллельно с этим и до этого проекта мы работали совершенно разными составами команд и там было разное количество тестировщиков. Все, что я рассказываю, из личного опыта. К сожалению, не всегда приятного. 🙂
Вопрос: Где написание/поддержка тесткейсов?
В данном докладе оно не рассматривалось, потому что тут у меня тоже немного другие подходы и это отдельная тема для долгого обсуждения.
Вопрос: Как эстимировать работу тестировщика? Имеется в виду, что время на работу очень сильно зависит от качества работы девелоперов.
Если вы не делаете оценки в стиле Agile, то в тестировании вы полагаетесь сугубо на интуицию и попытки обезопасить себя буферами времени. В Agile команде вы не оцениваете тестирование как активность, вместо этого вы оцениваете насколько сложно/долго команде сделать ДО КРИТЕРИЯ ГОТОВНОСТИ определенную функцию продукта. А кто и как в команде будет что делать вас мало интересует. Тестирование должно оставаться в рамках каждой задачи, а не быть отдельной фазой в этом процессе. Посмотрите в материалах выступлений мой старый доклад “QA в Agile”.
Вопрос: Обычно верификация багов, найденных на данной итерации, переносится в следующую итерацию и нагрузка планируется, чтобы таких завалов не было.
О! Это очень долгая тема. У меня несколько другое отношение к понятию бага. Детальнее можно прочитать в этой статье.
Вопрос: Как-то непонятно. Неужели в планировании не было учтено, что вообще найдут баги?
Учтено то может и было, но как учесть сколько найдут. Это ведь зависит от разработчиков. Можно использовать накопленную за большой срок статистику, но ее еще надо накопить. И от колебаний в 20-30% она не защитит (на примере второй команды, которая делала мало багов). А это значит, что тестирование может не влезть в итерацию и снова проблемы…
Вопрос: А разве тестировщик виноват в том, что так много багов?
Ни в коем случае. Виноваты разработчики. Вина тестировщика в том, что он не “обеспечил качество” в процессе разработки. Для этого он должен был на этапе планирования помочь разработчикам понять правильно требования, обеспечить как можно раньше (желательно до реализации) весь набор приемочных критериев и тестов, смотреть на ранние результаты работы разработчика до конечной сдачи работ и т.д.
Вопрос: Кажется, хорошо так себя мотивировать, но рассчитывать на отсутствие дефектов – странно.
Так я не призываю на это рассчитывать. Над этим надо работать. Настоящая работа QA инженера – не допустить дефектов. Работа тестировщика (QC инженера) – проверять работу продукта, когда на его качество уже не повлиять. Поэтому мне ближе QA инженеры, часто в лице разработчиков. 🙂
Вопрос: Хорошее качество кода будет стоить достаточно дорого, дороже чем долгое тестирование. И часто заказчик выбирает именно долгое и более дешёвое тестирование и ре-тест, чем оплатить дорогущих девелоперов.
Долгое тестирование не улучшает качество кода. Его приходится все равно исправлять вашим дорогущим программистам, а чем позже они это сделают, тем больше времени (читать денег заказчика) они потратят. Гораздо дешевле не допустить плохого кода, чем его потом исправлять. А особенно ситуация усугубляется в случае большой ручной регрессии.
Вопрос: Понятно, что внедрившись ранее – ошибок будет меньше. И все же, как это спасет от того, что ошибки таки есть и “производительность” по сравнению с идеалм меньше в 5 раз?
Ну вот тут от вас и зависит как сделать чтобы “меньше” означало не в 5 раз, а на 5-10% к примеру. 🙂
Вопрос: Код ревью – не панацея. Ревьювить можно отступы и стилистику написания кода. На дев машине никто не гарантирует стабильность и следовательно время будет тратиться больше, что тоже не даст достаточный профит.
Из моего опыта, ревью кода устраняет огромное количество проблем, если оно делается обязательным для каждой задачи. В моих проектах это так уже больше 5 лет. В результате, мы можем работать без тестировщиков и выпускать отличный продукт, которым, без преувеличений, пользуются миллионы людей и множество компаний. Но для этого надо знать, как правильно делать ревью. Об этом мы рассказывали не раз в докладе “Code Review”, запись которого можно найти в материалах выступлений. По поводу стабильности на машине разработчика – тут все зависит от его стиля разработки. Если он работает, разбивая задачу на законченные куски, то с чего тут взяться нестабильности? Да и речь идет о первичном тестировании, которое не должно быть слишком детальное. Его задача – найти быстро наиболее видимые проблемы.
Вопрос: Вопрос к тебе как к разработчику. Внедрив инженерные практики наши разработчики стали еще хуже себя вести, теперь они отдают продукт еще позже, потому что хотят сделять конфетку. В результате в конце итерации просто нет времени на тестирование. Есть такой эффект?
Я на этот вопрос отвечал уже после доклада. Возможно, команда не понимает сути Scrum и как в него вписывается тестирование. Также, возможны случаи перфекционизма, когда инженерные практики существуют только ради факта применения инженерных практик. В нормальном процессе описанного эффекта быть не должно.
Вопрос: Что делать, если тебя “не пускают” в ранние этапы?
Для вас это означает, что вы не можете влиять на качество, а значит, предсказать продолжительность тестирования. Вам надо продать идеи руководству, команде, менеджерам. Продажа никогда не была простым делом. Но без нее никуда. Отличное место для продажи – это ретроспектива (у вас же она есть?). Давите на “больные мозоли”, забрасывая идеи по избеганию проблем. Предлагайте попробовать и делайте все от вас зависящее, чтобы команда в этих попытках не разочаровалась. А для этого вам важно полностью понимать какие могут быть подводные камни и как их обходить.
Вопрос: Какие есть реальные примеры коротких циклов обратной связи, что конкретно надо применять?
Писал об этом чуть выше. Договаривайтесь с разработчиком о разбиении его работы на стадии и раннем легковесном тестировании результатов. Обсуждайте с ним тестовые сценарии, чтобы он вложил их в модульные тесты.
Вопрос: Автотесты “глупые”, да, они много покрывают, но! Всегда есть “непокрытые2 участки, которые не заметили сразу. Как же не проверить еще раз в регрессии?
Автотесты глупые, но вы же умные. 😉 Нашли непокрытые участки и расширили набор автотестов. Автотесты должны пополняться постоянно из других активностей тестировщика, когда он видит, что повторная проверка уже попахивает роботизацией человека. 🙂
Вопрос: Если регрессию нельзя автоматизировать, то что тогда?
Тогда вы в печальном положении. Регрессионная спираль смерти вас все равно нагонит. Вы можете облегчить боль за счет хорошего покрытия модульными тестами и облегченного тестирования в регрессии (например, по чеклистам вместо тестовых сценариев).
Вопрос: Что делать в ситуации когда разработчики отдают новый функционал на тестирование за несколько часов до демо? Тестирование на локальных машинах не всегда возможно и не всегда имеет смысл (тк могут быть блокировки).
Тут важно понять, что для вашей команды входит в состояние ГОТОВО, которое согласовано с заказчиком. Если это полностью протестированный функционал, который готов к заливке на живые продакшен сервера, то выкатывание его за пару часов до демо не имеет смысла. Его ведь не успеют протестировать. Поэтому надо менять процесс разработки. Обсудите эти проблемы на ретроспективе.
Вопрос: А как насчет эксплоратори в регрессии?
Я только за, но делать его нужно в определенные запланированные моменты. Проверки основные стоит автоматизировать, чтобы регрессию можно было делать сотни раз за итерацию и она не допускала ошибок.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
