Мой ответ — ставить перед собой и достигать квартальных целей.

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

Современные багтрекеры представляют собой мощные инструменты, обладающие не только основной первоначальной задачей по ведению ошибок, но и, зачастую, рядом дополнительных возможностей, полезных в повседневной работе. В режиме «живой демонстрации» будут рассмотрены наиболее известные и популярные БТС (Redmine, BugZilla, FogBugz, Mantis, Jira) с точки зрения их функциональности, анализа общих черт и различий. По некоторым из них будут даны советы по улучшению ведения ошибок, а также приведены реальные примеры «жизненного цикла багов». В заключении будут даны рекомендации по выбору БТС исходя из конкретных задач и предъявляемых требований.

Доклад, во-первых, будет полезен новичкам, которые только познают все те вещи, с которыми каждый день сталкиваются рядовые тестировщики. Во-вторых, тем, кто находится на распутье и кого одолевают сомнения по выбору «самой лучшей» БТС для своей работы. В-третьих, любознательным, стремящимся расширить свой кругозор по современным БТС. И, наконец, всем тем, кому не чужда тема холивара.

Да, но какой браузер «самый главный», тот, в котором вы проверяете основную функциональность, вёрстку страниц, ищете «битые» ссылки, выполняете валидацию страниц на соответствие различным стандартам, выполняете негативные тесты и пытаетесь «сломать» приложение?

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

Никаких других инструментов — только Firefox и его плагины.

Данный доклад будет о
- том, как перенести свои знания о тестировании десктопных продуктов на мобильные приложения,
- нюансах в тестировании iOS и Andoid приложений,
- документации, без которой не обойтись,
- том, как создать собственный парк устройств и нужен ли он,
- процессах, предшествующих размещению продукта в маркете.

О плюсах, минусах, специфике работы тестировщика в таком режиме я попытаюсь рассказать в своём докладе.

В своем докладе я познакомлю вас с профайлерами для двух наиболее популярных СУБД – MySQL и MS SQL. Я расскажу что именно может показать профилировщик и что с этим потом делать.
Приходите – будет интересно!

А когда мы общаемся с тестировщиком-коллегой – эффективно ли наше общение? Достигаем ли мы цели коммуникации? А ставим ли осознанно цель?

Если вы сталкивались с проблемами непонимания во время или после коммуникации, мой доклад поможет вам посмотреть на «баги» в коммуникациях со стороны. Вы получите проверенные временем, психологами и айтишниками инструменты, которые могут помочь вам договариваться более эффективно.

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

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

Кейс, с одной стороны, помогает понять, что должна делать Система, т.е., что ожидается. А с другой стороны, показывает что может сломаться в данной ситуации и как это выявить.

Основная проблема, с которой сталкиваются начинающие тестировщики: они не понимают зачем вообще нужны тест- кейсы, как правильно написать кейс и какие элементы кейса являются обязательными. Надо ли использовать определенную методологию или нет? Какой стандарт брать за основу? Как быстро и наглядно убедить заказчика, что действительно все основные сценарии проверены?

Тестирование, основанное на кейсах, является более объективным, чем исследовательское тестирование. Вторым достоинством является четкое понимание времени, которое надо на проведение тестирования.

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

Баг-репорт – важнейший документ. Тестировщикам нечего делать в профессии без умения четко и внятно донести необходимую и актуальную информацию до лиц, ответственных за принятие решений.
Непрофессиональные отчеты об ошибках могут являться причинами срыва сроков и задержек в поставке ПО.
Так почему бы нам не пойти по пути постоянного совершенствования в написании баг-репортов вместе? Какими путями я шел и иду к «просветленному» отчету, на что я обращал и обращаю внимание, что исправлял и исправляю в отчетах и почему — об этом и пойдет речь в моем докладе. Не стоит бояться наступать на грабли, совершенствуясь в работе. И даже когда всё кажется превосходным — посмотрите, можно ли улучшить баг-репорты?

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

Вот некоторые из них:
• отсутствующий (или некомпетентный) наставник;
• слаборазвитые процессы разработки и тестирования внутри компании;
• вытекающее из слабости процессов: «Ну потестируй что-нибудь, ты же QA»;
• отсутствие «вопросительности»
• непонимание цели тестирования;
• тестирование используется как вход в IT;
• в профессию пришли за деньгами;
• карма/другое :)

Также расскажу личную историю тестировщика-обезьянки: как я боролся с обезьянкой внутри меня :) как боролся с публичным мнением: «Тестировщик мобильных приложений – обезьянка». Кстати, иногда даже стоит давать обезьянке волю. Мы разберемся с ситуациями, когда это приносит пользу, и что я использую для этого.

* Как эти тесты продумать?
* Как обеспечить высокое покрытие не избыточным количеством тестов?
* Какие инструменты есть для тестирования состояний и переходов и как их использовать?

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

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

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

О том какие плюсы и минусы бывают у интеллект карт, где и как их можно применять – я расскажу в своем докладе. И даже покажу ту самую программку, которая уже несколько лет помогает мне в тестировании.

Так было и у нас. А потом все изменилось. На смену старой студии пришла новая, да не одна. А с TFS в придачу.

Как и у нас, во многих офисах стоит Visual Studio. Многие команды разработчиков пользуются TFS для разработки проектов. Но немногие знают, что в этом во всем есть бонусное место для тестировщиков.

О том, как можно использовать TFS для тестирования, что такое Test Manager и как с ним работать, почему все удобнее держать в одной системе — я попытаюсь рассказать в своем докладе на примерах.

Я встречал две крайности в применении этой техники.

Одна крайность – использование везде, с потрясающе простым обоснованием применимости – «ну, тестов же мало получается, это классно!» Другая крайность – полный отказ от использования этой техники, с не менее замечательным объяснением – «непонятно, как это работает, а тестов получается подозрительно мало, не верю!»

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

Я расскажу, не прибегая к теории, какие существуют кнопки и рычаги управления техникой покрытия попарных комбинаций:

* когда она эффективна, а когда не очень,
* какие зависимости между параметрами мешают применять эту технику, а какие не мешают,
* как «дробить» и «склеивать» переменные, чтобы заставить технику работать эффективнее,
* меняется ли результат от «перестановки мест слагаемых»,
* какие баги пропускает эта техника и почему.

Ах да, конечно, обязательно покажу Магические Инструменты, как же без этого :)

В докладе будут проведены параллели между особенностями как самих «умных» телевизоров LG и Samsung, так и приложений для них; будут даны рекомендации при проектировании и непосредственном тестировании приложения; будут рассмотрены и сравнены инструменты для функционального тестирования; также будет рассмотрен процесс размещения приложения в магазинах LG/Samsung, который включает в себе обязательное повторное тестирование сотрудниками этих компаний (строгость рассмотрения равна, а порой даже и выше, чем в AppStore) с необходимыми рекомендациями по успешному размещению приложения.

А теперь давайте поиграем … на работе. Нет, не в онлайн-игры, такие как WoW или Quake. Добавим фана и драйва в рутину.
Выбираем наиболее скучную, на ваш взгляд, но очень необходимую активность, добавляем игровые элементы и методы, устанавливаем правила игры – и добиваемся и результата, и фана.

В докладе я расскажу вам про Gamification – использование игровых методов и игровых элементов в не игровом контексте, например, в процессе Quality Assurance. Поделюсь необходимыми инструментами для этого, а также приведу практический пример применения Gamification в тестировании. Полученные знания вы можете использовать для создания своих QA-игр.

• работаете над web приложениями?
• цените свое время?
• умеете пользоватся поисковыми системами?
• хотите автоматизировать, но ещё не умеете программировать?
• не любите рутинные задачи?
• открыты новому и не боитесь трудностей?

Безусловно, я расскажу не только о плюсах, дабы не вводить вас в заблуждение.
Я постараюсь рассказать всё необходимое для знакомства с этим замечательным инструментом.

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

Например, вот лишь парочка классических болезней тестировщиков:

“Я знаю систему, значит ее знают и все остальные”, приводящая к низкому качеству оформления багрепортов.

“Замыленный взгляд”, которая нередко сводит на нет результаты тестирования, так как тестировщик, без фокуса на продукте, уже не в состоянии находить дефекты в нем.

“Шеф, все пропало” – тяжелая болезнь упаднического настроения от чересчур критичного взгляда на возникающие в продукте ошибки.

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