Баг-репорт – важнейший документ. Тестировщикам нечего делать в профессии без умения четко и внятно донести необходимую и актуальную информацию до лиц, ответственных за принятие решений.
Непрофессиональные отчеты об ошибках могут являться причинами срыва сроков и задержек в поставке ПО.
Так почему бы нам не пойти по пути постоянного совершенствования в написании баг-репортов вместе? Какими путями я шел и иду к «просветленному» отчету, на что я обращал и обращаю внимание, что исправлял и исправляю в отчетах и почему — об этом и пойдет речь в моем докладе. Не стоит бояться наступать на грабли, совершенствуясь в работе. И даже когда всё кажется превосходным — посмотрите, можно ли улучшить баг-репорты?
В своем докладе я расскажу вам о том, как и почему появляются такие «обезьянки» и что можно с этим сделать.
Вот некоторые из них:
• отсутствующий (или некомпетентный) наставник;
• слаборазвитые процессы разработки и тестирования внутри компании;
• вытекающее из слабости процессов: «Ну потестируй что-нибудь, ты же QA»;
• отсутствие «вопросительности»
• непонимание цели тестирования;
• тестирование используется как вход в IT;
• в профессию пришли за деньгами;
• карма/другое :)
Также расскажу личную историю тестировщика-обезьянки: как я боролся с обезьянкой внутри меня :) как боролся с публичным мнением: «Тестировщик мобильных приложений – обезьянка». Кстати, иногда даже стоит давать обезьянке волю. Мы разберемся с ситуациями, когда это приносит пользу, и что я использую для этого.
* Как эти тесты продумать?
* Как обеспечить высокое покрытие не избыточным количеством тестов?
* Какие инструменты есть для тестирования состояний и переходов и как их использовать?
Доклад будет полезен тестировщикам и тест-дизайнерам, и после него (я надеюсь) вы сможете пропускать значительно меньше критичных дефектов.
Но, если вспомнить, кроме черного и белого в мире есть еще множество цветов и оттенков. Теперь не обязательно примыкать к одной из сторон, теперь можно пойти своим путем – взять самое хорошее из скриптового тестирования, разбавить творческим началом исследовательского и получить интеллектуальные карты.
С их помощью можно исследовать продукт, на их основе можно писать скрипты, но, главное – они помогают отлично структурировать информацию и быстро ее изменять – в соответствии с быстро меняющимися требованиями заказчика.
О том какие плюсы и минусы бывают у интеллект карт, где и как их можно применять – я расскажу в своем докладе. И даже покажу ту самую программку, которая уже несколько лет помогает мне в тестировании.
Версии хранятся в дженкинсе.
Баги ведутся в редмайне, а тест-кейсы вообще лежат в Тестлинке… Знакомо?
Так было и у нас. А потом все изменилось. На смену старой студии пришла новая, да не одна. А с TFS в придачу.
Как и у нас, во многих офисах стоит Visual Studio. Многие команды разработчиков пользуются TFS для разработки проектов. Но немногие знают, что в этом во всем есть бонусное место для тестировщиков.
О том, как можно использовать TFS для тестирования, что такое Test Manager и как с ним работать, почему все удобнее держать в одной системе — я попытаюсь рассказать в своем докладе на примерах.
Я встречал две крайности в применении этой техники.
Одна крайность – использование везде, с потрясающе простым обоснованием применимости – «ну, тестов же мало получается, это классно!» Другая крайность – полный отказ от использования этой техники, с не менее замечательным объяснением – «непонятно, как это работает, а тестов получается подозрительно мало, не верю!»
Да, непонятно как это работает внутри. И я не призываю изучать алгоритмы генерации магических комбинаций. Многие прекрасно водят автомобиль, не понимая его внутреннего устройства, принципа работы, использованных инженерных решений. Зато все должны знать, как рулить и как тормозить.
Я расскажу, не прибегая к теории, какие существуют кнопки и рычаги управления техникой покрытия попарных комбинаций:
* когда она эффективна, а когда не очень,
* какие зависимости между параметрами мешают применять эту технику, а какие не мешают,
* как «дробить» и «склеивать» переменные, чтобы заставить технику работать эффективнее,
* меняется ли результат от «перестановки мест слагаемых»,
* какие баги пропускает эта техника и почему.
Ах да, конечно, обязательно покажу Магические Инструменты, как же без этого :)
В докладе будут проведены параллели между особенностями как самих «умных» телевизоров LG и Samsung, так и приложений для них; будут даны рекомендации при проектировании и непосредственном тестировании приложения; будут рассмотрены и сравнены инструменты для функционального тестирования; также будет рассмотрен процесс размещения приложения в магазинах LG/Samsung, который включает в себе обязательное повторное тестирование сотрудниками этих компаний (строгость рассмотрения равна, а порой даже и выше, чем в AppStore) с необходимыми рекомендациями по успешному размещению приложения.
А теперь давайте поиграем … на работе. Нет, не в онлайн-игры, такие как WoW или Quake. Добавим фана и драйва в рутину.
Выбираем наиболее скучную, на ваш взгляд, но очень необходимую активность, добавляем игровые элементы и методы, устанавливаем правила игры – и добиваемся и результата, и фана.
В докладе я расскажу вам про Gamification – использование игровых методов и игровых элементов в не игровом контексте, например, в процессе Quality Assurance. Поделюсь необходимыми инструментами для этого, а также приведу практический пример применения Gamification в тестировании. Полученные знания вы можете использовать для создания своих QA-игр.
- работаете над web приложениями?
- цените свое время?
- умеете пользоватся поисковыми системами?
- хотите автоматизировать, но ещё не умеете программировать?
- не любите рутинные задачи?
- открыты новому и не боитесь трудностей?
Безусловно, я расскажу не только о плюсах, дабы не вводить вас в заблуждение.
Я постараюсь рассказать всё необходимое для знакомства с этим замечательным инструментом.
Мой доклад посвящен как раз таким ошибкам в работе специалистов по тестированию, опыт показал, что их можно типизировать и обособить, сформулировав симптомы, причины возникновения и потенциальные угрозы, более того я расскажу, как эти “болезни” вылечить!
Например, вот лишь парочка классических болезней тестировщиков:
“Я знаю систему, значит ее знают и все остальные”, приводящая к низкому качеству оформления багрепортов.
“Замыленный взгляд”, которая нередко сводит на нет результаты тестирования, так как тестировщик, без фокуса на продукте, уже не в состоянии находить дефекты в нем.
“Шеф, все пропало” – тяжелая болезнь упаднического настроения от чересчур критичного взгляда на возникающие в продукте ошибки.
А таких болезней куда больше, о наиболее распространненых из них я вам и расскажу, выписав вдобавок рецепты для их лечения.
