Выступление Евгения Ефимова на онлайн-конференции для тестировщиков Fun ConfeT&QA
«А сколько времени тебе надо что бы протестировать билд?» и «А почему так много?» одни из наиболее часто задаваемых вопросов QA-инженерам независимо от проектов и места работы.
Я расскажу, как ответить на эти вопросы себе и другим и быть уверенным в своем ответе.
Мы посчитаем, из каких кусочков состоит время, затрачиваемое на тестирование, и научимся составлять из этих кусочков формулы, подходящие вашему конкретному проекту и позволяющие точно и обоснованно отвечать на вопрос, сколько времени нужно на то или иное тестирование.
Выступление Андрея Иваровского на онлайн-конференции для специалистов по автоматизации тестирования Auto ConfeT&QA, весна 2013 года
При автоматизации тестирования веб-приложений часто возникают трудности с распознаванием элементов.
Веб-элементы могут не распознаваться, у них могут меняться идентификационные свойства.
Это, пожалуй, самые распространенные проблемы, возникающие при взаимодействии инструмента автоматизации с веб-интерфейсом приложения.
Однако самая серьезная проблема возникает, когда имеется много веб-элементов, много тестов и функционал приложения часто меняется.
В этом случае на поддержку автотестов могут потребоваться значительные затраты времени. Уж лучше протестировать руками.
Как оптимизировать распознование элементов так, чтобы не тратить столько времени на поддержку? Как вдохнуть жизнь в ваш тестовый фреймворк? Как же сделать так, чтобы автоматизация тестирования вновь обрела смысл на проекте?
Продолжаем публикацию заметок Джона Стивенсона о важных для тестировщика навыках. Предыдущие выпуски: навык делать заметки, абдуктивное мышление. Эта статья – про то, как общаться с менеджментом, если вы тестировщик.
Тестировщикам бывает трудно объяснить свою ценность и значимость высшему менеджменту компании. Обычно мы ударяемся в технические детали, или - что еще хуже - разговариваем с менеджерами так, как будто они дурачки, не имеющие ни малейшего понятия о важности и нужности тестирования. Запомните главное правило - общаясь с представителями бизнеса на тему тестирования...
Доклад Елены Поплоухиной (Фалилеевой) с онлайн-конференции Auto ConfeT&QA.
Часто к инструментам генерации кода тестов для автоматизации тестирования UI приложений относятся с некоторым пренебрежением, аргументируя это тем, что такие тесты тяжело поддерживать – и в случае изменений в UI их легче переписать.
В своем докладе я хочу показать, что генерация C# тестов в Visual Studio 2012 при помощи Coded UI достигла такого отличного уровня, когда мы можем поддерживать их, прилагая минимум усилий.
Приближается последний месяц 2015-го года. Все мы начинаем думать: чего я достиг в этом году? Что изменилось в лучшую сторону? Чему я научился? Что я планирую на следующий год?
Конечно, судьбу мы читать не умеем, мы её сами только строим. Зато Наталья Руколь*, автор и ведущая курса “Школа Тест-Менеджеров”, предлагает своё видение гороскопа на 2016 год для различных знаков зодиака. Как ведут себя различные тест-менеджеры, в зависимости от их знака зодиака? Что им следует улучшить в 2016-м году? А в конце Наталья дает общие рекомендации для всех знаков зодиака.
Овны в астрологии считаются самым смелым знаком зодиака. Они всегда рискуют, а значит, они чаще всех пьют шампанское! В новом году овны обязательно попробуют внедрить несколько новых инструментов, поменять баг-трекер, изменить правила документирования тестов… При этом, сделают они это несколько раз за год! Овнам точно не будет скучно, и их квалификация гарантированно вырастет. Чего им стоит опасаться? Ненависти бедных несчастных исполнителей, третий раз за год меняющих правила своей работы, и неуверенных, что это надолго! Возьмите паузу в 2016-м, и попробуйте довести хотя бы одно из нововведений до логического завершения.
Тельцы. Эти терпеливые и упорные тест-менеджеры не будут, как овны, регулярно менять свои решения. “Если мы выбрали баг-трекер и систему управления тестами, значит, мы будем их использовать”, говорят они. Чтобы не попадаться в ловушку собственного упорства, тельцы, присмотритесь: точно ли выбранное вами решение верное? Может, стоит немного его откорректировать, поменяв процесс работы, формат документов, или набор полей? В 2016-м году вам надо уделить особое внимание метрикам оценки эффективности своей работы, чтобы точно знать, какие ваши действия ведут к улучшению процесса, а какие вы поддерживаете лишь в следствии врождённого упрямства.
Близнецы многогранны. Они могут вести себя по-разному, проявляя и упрямство, и авантюризм. Чаще всего, их отличительной чертой может быть некоторый уровень безответственности: “будь, что будет”. Но в тест-менеджменте это недопустимо! Близнецы, помните: мы - последний рубеж обороны качества! Всё, что мы делаем, влияет на удовлетворение клиентов, продажи продукта, сроки и стоимость разработки. Успешные близнецы в 2016-м - те, кто возьмут на себя полную ответственность, и постараются сделать всё, от них зависящее, для успеха проекта!
Раки - добродушные, иногда немного застенчивые знаки зодиака. Они боятся быть слишком жестокими по отношению к окружающим людям, и эта доброта иногда чревата для проекта! РМ уговорил вас выпустить продукт с критичной ошибкой, и теперь ваши клиенты несчастны? Вам не хватает весомости и авторитета в конфликте “баг или фича” с разработчиком? В 2016-м году ваша главная задача - обучение управляемым конфликтам, чтобы отстаивать собственную точку зрения. Иногда главная задача тест-менеджера не получить информацию о продукте, а суметь её донести до руководства!
Когда я готовил презентацию "Ведущие тренды 2016 года" для шведской конференции OreDev, я задумался о том, как сильно изменилась индустрия разработки ПО за последние 15 лет. Я помню времена, когда специалисты по тестированию и обеспечению качества считались вторым сортом, а миром правили разработчики. И тут меня осенило: ведь сейчас все мы - тестировщики.
Смещение влево
Во многом это произошло благодаря стратегии "смещения тестирования влево" (стратегия раннего тестирования) как можно раньше в ходе разработки. В результате ваша команда концентрируется на качестве с самого начала проекта, а не рассчитывает на то, что баги будут найдены в конце жизненного цикла разработки.
Все больше и больше компаний применяют этот подход, и в результате тестирование и автоматизация перестают быть прерогативой исключительно QA, и роли разработчика и тестировщика постепенно размываются. Перемены всегда пугают, но ваша команда может облегчить себе жизнь при "смещении влево", выполняя ряд несложных рекомендаций.
Программа пяти шагов
Эти пять шагов очень помогли командам, с которыми я работал:
сделайте разработчиков ответственными за тестирование;
Выступление Алексея Петрова на онлайн-конференции для специалистов по тестированию Chief ConfeT&QA.
Инструкции, шаблоны, регламенты и workflow, да даже всемогущие автотесты не появятся и не заработают сами собой.
Но как же найти нужных специалистов, где их искать и что спрашивать у них на собеседовании? Что рассказать о компании, о проектах, отделе? Какие тестовые задания подготовить и на что обращать внимание при их решении?
За последние три года я провел несколько сотен собеседований со специалистами в области тестирования самых разных профилей и уровня подготовки. Поэтому мой доклад будет содержать по-максимуму практических примеров и ситуаций, с которыми мне приходилось сталкиваться, а также принятых решений и рекомендаций по успешному найму тестировщиков.
27-28 ноября 2015 года в Москве состоится международная конференция для специалистов по обеспечению качества - Software Quality Assurance Days, или, если коротко, SQA Days-18.
Software Quality Assurance Days - это лучшая профессиональная конференция в сфере QA на русскоязычном пространстве, одна из крупнейших в Восточной Европе. В этом году она проходит уже во второй раз - это стало возможно благодаря активному интересу и энтузиазму QA-специалистов, их стремлению к профессиональному росту и самообразованию.
Место проведения конференции: Россия, Москва, 1-й Зачатьевский переулок, дом 4, «ИнфоПространство»
Программа конференции укомплектована полностью.
При использовании промокода s-t.ru - скида на участие 10%.
Почему умение записывать так важно для тестировщика?
Зафиксировать результаты тестирования можно массой различных способов. Но если ваши заметки недостаточно подробны, это снижает ценность тестирования. Умение делать записи позволяет нам лучше узнать и понять тестируемый продукт. Чтобы развить этот навык, необходимо использовать критическое мышление.
Вот что пишет Роберт Ламберт про ценность этого навыка для исследовательского тестирования:
"Хороший тестировщик ведет заметки о ходе сессии, фиксируя свои наблюдения и описывая свои действия. Детальные заметки помогают ему выявить причинно-следственные связи, сообразить, какие вопросы надо задавать, и наметить план будущих сессий".
О важности умения делать записи писал также Майкл Болтон:
"Одна из главных проблем исследовательского тестирования с точки зрения тест-менеджеров и менеджеров проектов - это его неуправляемость и отсутствие отчетности. Тем не менее, профессионалы других отраслей - например, полицейские, врачи, адвокаты - умеют отчитываться о непредсказуемых случаях при помощи навыка делать записи".
Скоро 2016 год - яркий, наполненный бурными событиями, легкий и веселый — таким обещает быть год обезьяны.
Уже сегодня нужно задумываться о том, что подарить коллегам айтишникам на Новый год…
Мы сделали недорогой, но при этом красивый настольный календарь, сочетающий символику нового года и айтишную тематику. Мы надеемся, что он станет отличным подарком и порадует всех кто работает в it-сфере: программистов, тестировщиков, аналитиков, менеджеров.
В своей работе мы сталкиваемся с багами каждый день. Какие-то баги мы легко узнаем и ловим их, а на какие-то не обращаем внимания. Наш календарь напомнит о том, что баги бывают разные, а обезьяна, символ нового года, продемонстрирует их так, что даже ребенок это запомнит.
А для тех, кто хочет не только порадовать своих сотрудников или друзей, но и подарить полезный подарок мы предлагаем Подарочные сертификаты на обучение.
Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно. Чтобы такого не происходило, мы обычно заранее, до релиза, стараемся оценивать качество тестирования: насколько хорошо и тщательно мы проверяем продукт? Каким областям не хватает внимания, где основные риски, какой прогресс? И чтобы ответить на все эти вопросы, мы оцениваем тестовое покрытие.
Зачем оценивать?
Любые метрики оценки – трата времени. В это время можно тестировать, заводить баги, готовить автотесты. Какую такую магическую пользу мы получаем благодаря метрикам тестового покрытия, чтобы пожертвовать временем на тестирование?
Поиск своих слабых зон. Естественно, это нам нужно? не чтобы просто погоревать, а чтобы знать, где требуются улучшения. Какие функциональные области не покрыты тестами? Что мы не проверили? Где наибольшие риски пропуска ошибок?
Редко по результатам оценки покрытия мы получаем 100%. Что улучшать? Куда идти? Какой сейчас процент? Как мы его повысим какой-либо задачей? Как быстро мы дойдём до 100? Все эти вопросы приносят прозрачности и понятности нашему процессу, а ответы на них даёт оценка покрытия.
Фокус внимания. Допустим, в нашем продукте около 50 различных функциональных зон. Выходит новая версия, и мы начинаем тестировать 1-ю из них, и находим там опечатки, и съехавшие на пару пикселей кнопки, и прочую мелочь… И вот время на тестирование завершено, и эта функциональность проверена детально… А остальные 50? Оценка покрытия позволяет нам приоритезировать задачи исходя из текущих реалий и сроков.
Автор: Джо Колантонио