Евангелист Качества
0,0
рейтинг
20 августа 2012 в 18:40

Разработка → Тестирование — это не поиск ошибок!

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.

Что такое поиск ошибок?

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

Какие области я буду тестировать в таком случае? В первую очередь, самые нестабильные. Зачастую они нестабильны потому, что менее приоритетны, но это неважно, значительно важнее количество багов.

Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?

Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные. Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.

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

Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием.

Что такое тестирование?

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

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

Что будет, если я столкнусь с трудностями? К примеру, со сложновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или нехваткой требований? Если это важный функционал, то я буду выяснять «что не так», «как правильно». На заведение дефекта в итоге может уйти немало времени, и с точки зрения баг/время результат эффективности тестирования будет не очень высок, зато у меня появятся более глубокие знания о продукте, архитектуре, пользователях.

Какие тесты я буду проводить в первую очередь? Конечно, самые-самые стандартные. Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает. И только после этого я перейду к менее стандартным сценариям.

Результаты тестирования и поиска ошибок

В случае с поиском ошибок, в краткосрочной перспективе результаты выше: багов заводится больше и сразу.

Но в долгосрочной перспективе всё не так радужно:
  • из-за отсутствия глубоких знаний о продукте, постепенно начинает расти % пропущенных дефектов
  • команда разработки занята исправлением страшных-ужасных-немыслимых багов, полученных путём клика на одну и ту же кнопку 144 раза под IE в полнолуние
  • в релиз попадают некоторые ужасно неприятные и очевидные для пользователя баги
  • количество находимых ошибок в ДОЛГОСРОЧНОЙ перспективе падает


Как перейти от поиска ошибок к тестированию?


Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, необходимо следовать простым правилам и использовать ключевые инструменты тестирования:

1. Анализ продукта и документирование тестов

Кликая на кнопки, можно завести много багов — но нельзя сказать, что было проверено. Единственное решение — документирование тестов. Подробные тест-кейсы, удручающие тестировщиков и отнимающие уйму времени, бывают нужны очень редко. А вот чек-листы с перечнем «что нужно проверить» — необходимы.

Что они дают:
  • Вы анализируете продукт, выписываете основные фичи, действия, их параметры. Таким образом существенно снижается риск что-либо забыть.
  • Чек-листы — отличная напоминалка «здесь надо вникнуть глубже». Есть какая-то невнятная фича с недостаточным описанием. Как её тестировать? В тестировании без тестов проще всего сказать «я вернусь к этому позже», и уже никогда не вернуться. А с тестами — у вас будет висеть тест, в котором непонятно как и что проверять, вы будете такие тесты видеть и не забудете необходимость выяснения.
  • Чек-листы можно и НУЖНО согласовывать. С разработчиками, аналитиками. Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.


Залог успеха в ведении тестов — создание карты, по которой вы будете идти. Цель — покрыть весь продукт. Только пожалуйста, не надо отмазок об ужасной ресурсоёмкости — я покрывала проекты с миллионами строк кода меньше чем за месяц-полтора. И в процессе написания таких тестов поднимались неожиданные вопросы и всплывали критичные ошибки, которые несмотря на наличие горе-тестеров болтались в продукте годами.

2. Оценка тестирования

Чтобы не быть слепыми котятами, необходимо оценивать эффективность тестирования. Анализировать пропущенные ошибки и причины их пропуска. Покрытие функционала и кода тестами. Уровень удовлетворения пользователей, через анкеты и сбор обратной связи. Качество заведения ошибок, опрашивая разработчиков.

ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.

3. Обсуждение целей тестирования с командой

Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.

Как бы не так!

В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?

Чтобы приносить максимум пользы, надо хорошо понимать, в чём эта самая польза заключается. И не удивляйтесь, если мнение РМов и разработчиков не будет соответствовать вашему. Надо не переубеждать их, а подстраиваться под текущие проектные цели!

4. Понимание пользователей и их бизнес-процессов

Для меня загадка, как это возможно, но тем не менее это факт: зачастую тестировщики проверяют продукт, ничего не зная о пользователе.
  • Как этот продукт используется?
  • Зачем он вообще нужен, какие проблемы решает?
  • Какая средняя квалификация у пользователей?
  • В каких условиях работают пользователи? На каких окружениях, оборудовании?

Не надо догадок и додумок про «в среднем про отрасли»! Тестировщики должны ИДЕАЛЬНО знать СВОИХ пользователей. Часто им эту информацию не предоставляют аналитики. Одумайтесь! Не зная пользователя, тестировать продукт по-нормальному невозможно.

5. Техническая квалификация и понимание архитектуры

Для иллюстрации приведу баг, который на меня недавно завели в баг-трекере:
Зайти на сайт тестируемого продукта http://****.ru в браузере Firefox
Ввести логин и пароль
Зайти с того же компьютера в браузере Opera
Просит повторно ввести логин и пароль, автоматически не логинится.


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

Выводы

Очень многие разработчики не любят тестировщиков. И правильно делают!

Зато хороших тестировщиков любят и ценят все. Но тестировщиков, а не кликеров и багозаводильцев!

Учитесь узнавать, что не так, что не нравится другим участникам команды разработки. Обязательно исследуйте пропущенные ошибки и делайте всё для того, чтобы больше их не пропускать. Не гонитесь за заведением багов — вашей мантрой должны быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «завести как можно больше багов» — ОЧЕНЬ часто эти 2 цели оказываются слишком далеки друг от друга.

И да пребудет с вами сила!
Natalya Rukol @NatalyaRukol
карма
140,7
рейтинг 0,0
Евангелист Качества
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (71)

  • +5
    Все что описано в статье, мне, как разработчику, очевидно. Надеюсь, для некоторых тестировщиков тоже.
    • +1
      А чек-листы лучше составлять по каждому модулю, если система модульная. Это удобно. Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.
      Ну и должен быть глобальный чек-лист, который проверяется для КАЖДОГО релиза. Там должен быть самый главный и важный функционал, который ни в коем случае не должен сломаться.
      • +3
        «Можно прямо по репозиторию смотреть, изменили ли разработчики код модуля к текущему релизу. Если да, то, очевидно, нужно прогнать тесты этого чек-листа.»

        Такая логика предполагает, что изменения в одном модуле никак не скажутся на функциональности другого — что, к сожалению, далеко не всегда верно.
        • 0
          В идеале так и должно быть — изменения в одном модуле не должны сказываться на функциональности другого.
          На практике, конечно, такое не всегда возможно, но зависимости модулей можно учитывать.
          Например, изменения в компонентах, связанных с правами доступа (самое «ядерное» ядро) должны быть протестированы все модули, которые от него зависят — то есть практически вся система.
          А если вся команда «пилила» лишь функционал интернет магазина, то нет смысла (да и времени) тестировать модуль «Обратная связь».

          А вообще, в основной чеклист может быть занесено по одному — два не сложных теста каждого модуля, чтобы тестировщик хотя бы зашел в них и проверил живые ли они.
        • +1
          «Модули» — это хорошо, но обычно нет ничего настолько удалённого друг от друга. Когда разработчик исправляет ошибку, которая относится с точки зрения пользователя (и чаще всего тестировщика) к функционалу Х, логично проверять работу фичи Х. Только исправление могло вноситься в какую-то системную библиотеку, и проверить на самом-то деле важно сквозные моменты использования этого кода во всех фичах.

          Поэтому я всегда стараюсь вместе с разработчиками, архитекторами, нарисовать карту взаимосвязей в продукте. Тогда после слов разработчика «я правил это здесь» я сразу по карте вижу, что могло быть затронуто и что нужно проверять. Постепенно эта карта расширяется и становится ОЧЕНЬ полезной: мы экономим время, не тестируем лишнее, быстрее находим свежие дефекты.
          • 0
            А как выглядит ваша карта взаимосвязей? Это случайно не импакт анализ имеется ввиду?
            • 0
              нет, мы просто рисуем физические модули и стрелочки между ними.
    • +1
      Для «некоторых» — да, но к сожалению далеко не для всех :(
      • +3
        Счас кол-во минусов/плюса коммента даст более точную статистику =)
  • +5
    Все правда, но только тестер это обычно намного менее оплачиваемая должность, чем разработчик, и времени на их развитие уделяют меньше, что очень печально. И при критическах багах с продакшена вопрос «а это вообще как тестировалось?» задается далеко не в первую очередь.

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

    PS. Чую, скоро в теме будут тонны баттхерта от разрабов на тестеров и наоборот.
    • +8
      Насколько я сталкивался — зарплаты примерно равны. Нередко хороший синиор тестировщик получается больше среднего синиор программиста.
      • 0
        В хороших компаниях, с грамотным отношением к качеству и грамотными тестировщиками, это действительно так. Но 80% компаний берут на работу «студентов, потому что тестировать — это просто».
        • +2
          также студентов берут и в программисты, потому что программировать — это просто.
          Но на деле оказывается, что для того чтобы создать команду нужно с этими студентами выпустить не один релиз. А сколько граблей можно встретить по дороге…
          • –1
            Ну к программистам вменяемые требования значительно чаще предъявляются. А в тестировщики я лично видела как берут людей, которые на вопрос «что такое тестирование?» отвечают «а вот прийду работать к вам тестировщиком и заодно узнаю».
            • –1
              Программистов можно хорошо проверить на собеседовании, т.к. от программиста требуется умение писать код, знать определенные фреймворки, подходы, алгоритмы — все это можно проверить задав вопрос: «А напиши ка мне...»

              А что спрашивать у тестировщика, тем более начинающего? Прособеседовав парочку тестировщиков, я уже сам выучил какие бывают виды и типы тестирования, как можно протестировать ручку, чашку, окно, форму..., какое тестирование нужно проводить в первую очередь. Такими вопросами не проверишь сколько ошибок может найти тестировщик на реальном проекте. Можно только выяснить мыслит ли человек логически, мыслит ли нестандартно, проверить знает ли он теорию.

              Так что вполне нормальная ситуация, когда говорят «а вот прийду работать к вам тестировщиком и заодно узнаю». Главное, чтобы было у кого узнавать и чтобы качество продукта не страдало.
              • +1
                Ну я всегда даю задачки по тестированию :) И сразу вижу, делит ли человек продукт на составные части, декомпозирует ли функционал, как приоритизирует тесты и т.д. Тестирование чашек и карандашей показывает, как человек умеет ломать продукт. Знание терминологии — лишь его заинтересованность и готовность полистать статьи или книжки перед собеседованием.
                А вот тестирование маленького продукта (на бумаге) показывает очень много: умение задавать вопросы для выяснения требований, определение граничных значений, приоритизация, вспомнит ли человек про нефункциональные тесты и т.д.

                Теоретические вопросы «а что такое вот это?» и «а как делать вот то?» плохи тем, что на них человек отвечает «как написано в книжке/статье». А в реальной жизни он зачастую будет делать по-другому.
                • 0
                  Наталья, а не поделитесь ли парочкой таких «задачек» на бумаге? было бы очень интересно и весьма полезно!
                  • 0
                    Вот здесь будет веб-конференция, посвящённая поиску людей в ИТ: itbrunch.com.ua/it-recruitment/

                    Я на ней планирую как раз об этом рассказать. Участие абсолютно бесплатное, так что регистрируйтесь :)
                    • 0
                      Спасибо, зарегистрировался. Жаль только, что конференция через месяц, а знания пригодились бы непосредственно сейчас :)
        • +1
          Я думаю, что 80% компаний по этому же принципу и программистов набирают
          • +1
            Наверное, потому что руководство 80% компаний считает, что в принципе писать софт — это просто.
            Особенно если сравнивать со строительством )
            • 0
              с точки зрения компаний, студенты будут работать за еду и писать тот же продукт, что и матерые программисты. А т.к. зачастую интересует только внешний вид, а не внутренности, то и сталкиваемся с тем, что эти компании нанимают неопытных джуниоров. К строительству тоже подойдет — штукатурка ляжет одинаково на кирпич и на пеноблоки и гипсокартонные перегородки от кирпичных внешне не будут отличаться после обработки. Только в таком строительстве и в таком ИТ проекте получится один исход: «Стоит нормально, только лучше не трогать, чтоб не поломать».
              • +1
                Чего вы на студентов так понаехали??? Проблема не в студентах, а в организации их работы — в нормальных конторах студентов доверяют опытным наставникам, которые и задачу грамотно поставят, и проверят выполненную работу указав на ошибки. Многие студенты уже после полугода работы набираются достаточно опыта и качественно делают свою работу.
                • 0
                  На студентов никто не наезжает, все начинают работу без опыта.

                  НО! Многие берут студентов в условия, где этих самых опытных наставников просто нет. А когда человеку не у кого учиться, развитие идёт в разы медленннее, это плохо и для него, и для компании.
    • +3
      >… времени на их развитие уделяют меньше, что очень печально
      Очень печально что далеко не все тестировщики уделяют время на собственное развитие.
      Чтобы быть хорошим тестировщиком (ИМХО), надо иметь особый склад ума и характера и любить свою работу, постоянно изучая специалзированную литературу самостоятельно.
      Из своих знакомых я знаю только одного человека, которому действительно нравится тестирование и который посещает кучу конференций и растет профессионально. А так же знаю пару человек, кто в прямую говорят что занимается этим временно, и на самом деле это не особо интересно.
      • 0
        О! Это бич отрасли тестирования!

        Сколько я уже видела младших тестировщиков, которые занимают эту роль лет этак пять и «хотят быть программистами» или аналитиками. И в разработке на развиваются, и в тестировании. А толку?

        Главное правило тест-менеджера: брать на работу сотрудников, которые мечтают развиваться именно в тестировании.
      • +1
        Тестирование разное бывает, — устроился человек на работу тестировщиком веб-сайтов в студию, которая делает эти сайты. А за душой у него 3 года пентеста, мозг у него работает на определенном уровне, на своих оборотах и шаблонах. Естественно, что он сквозь пальцы пропустит различие в пиксель или изменение курсора при наведении на ссылку, а поставит в приоритет blackbox и пентест. Как быть с такими тестерами? Разрывать им шаблоны и переучивать, либо держать в штате в роли личной армии? палка о двух концах.
        • 0
          Ну всё зависит от ваших целей и что от тестирования нужно. Если такие результаты не устраивают — очевидно, что нужно что-то менять. Либо мышление этого тестера, либо самого тестера.
          • 0
            Полностью согласен с Вами, но не вижу смысла переучивать тестера, если только забить определенные шаблоны в голову. А что обычно требуют от тестирование? — заказчик нашел баг, ага, надо тестера попинать за него. Не учитывая того факта, что заказчик баг нашел не в продукте и вообще это просто не реализовано и не прописано в ТЗ. За это по голове получают и ПМ и тестеры, ведь клиент всегда прав. А то, что они сами не додумали (ПМ и тестеры) функционал, это языковой барьер. Тут глубже копать надо, дело не в найденных багах. дело в отношении к разработке.
  • +5
    Вообще тестирование — это измерение качества продукта. Задача QA не в поиске ошибок и не в пропускании их в как можно меньшем количестве, а в предоставлении менеджменту или руководителю проекта актуальной и достоверной информации о его качестве. Качество продукта это очень многогранная характеристика. Туда входит и количество ошибок и их приоритеты, удобство им пользования, качество документации и много чего еще
    • +4
      Теоретически да, за несколькими поправками:

      1) тестирование это не только предоставление информации, но и предоставление её в правильной последовательности, в нужные сроки, требуемом объёме и подходящем формате
      2) информация «мы нашли такие-то баги» и формирование 25-ти разных диаграм из баг-трекера не принесёт много пользы, если в этом самом баг-трекере нет половины критичных багов.
      • 0
        На моей практике, критические баги от заказчика — У меня не печатает на принтер! По факту в принтере — отсутствует бумага. Как определить эти критические моменты? Когда тестировщик не знает, что у заказчика в принтере нет бумаги? Естественно, такой баг (тестироващиком) описывается как не критичный, а потом возникает проблема — откуда знать заказчику, что у него нет в принтере бумаги, ведь вы же тестировали? а? не? Частенько так получается, когда ПМы все свешивают на тестеров, а тестеры с надеждой закрывают глаза.
        • 0
          Критерии критичности багов должны быть обговорены и согласованы с заказчиком, чтобы не возникало проблем в будущем.
    • +2
      в текущей практике QA engineer и software tester стали почему-то синонимами
      хотя смешивать тестирование с QA — обеспечением качества — не совсем правильно

      в задачи QA включаются например такие далекие от тестирования
      процессы для обеспечения качества:
      — внедрение систем continuous integration
      — внедрение систем для code review
      — проведение статического анализа кода
      — внедрение систем проверки лицензионной чистоты кода
      — build and release активности

      • 0
        Это да. Но qa звучит солидней и оплачивается выше, оттого самопровозглашают себя тестеры qa специалистами, забывая, что полномочия qa настоящего лежат недалеко от руководителя проекта.
        • 0
          звучит солидней — есть такое
          хотя тут рекрутеры тоже постарались — вакансии с заголовком qa engineer через одну по факту требуют скилов мануальных мышкотыкателей и\или админов
          • +1
            Недавно у меня был необычный опыт, я очень удивилась.

            Мы предоставляем услуги по аутсорсу тестирования. Я на проект выделяю ведущего тестировщика, прошу добавить его в чат разработчиков на проекте. Нас добавляют с комментарием «познакомьтесь, это наши тестеры». Мой тестировщик мне лично пишет: «Наташа, а тебе не обидно, что тебя назвали тестером?».

            ОБИДНО??? Вот так я невзначай узнала у ТЕСТИРОВЩИКА, что его это оказывается может задеть. Да я горжусь что меня тестером назвали, я ж тестер как-никак! А многие бодаются, стесняются, не любят таких слов.

            И вот что я вам точно скажу: в том небольшом количестве компаний, где работают правильные тестировщики и где к качеству относятся тоже правильно, слова «тестер» и «тестировщик» — это очень хорошие слова :)))
            • +1
              в диалогах это замечал тоже когда-то

              Слово «тестер» могут исправлять вовсе не потому, что обижаются,
              а если например в компании (обычно характерно для больших >1000 человек бодишопов)
              принята внутренняя градация квалификации тестеров и где QA-engineer квалифицируется и соответственно оплачивается выше тестера

              Тот факт, что персонаж, занимающий позицию QA-engineer, может не знать что такое вообще qa и по факту заниматься тестированием — никого не волнует

              Но если вы скажите такому перцу, что он тестер — он вас поправит
              потому, что в терминах компании, где он работает, он просто называется по-другому

              В таком контексте объяснять человеку, что у него позиция называется неправильно — т.к занимается он вовсе не внедрением процессов обеспечения качества, а контролем качества — причем в ухком контексте — уже как-то и глупо

              Товарищ мой стебал меня, говоря:
              — как ты сказал, кем ты там работаешь?.. амперметром?.. а ну да — тастером
              • +2
                Тут еще частенько возникает проблема в том что народ иногда забывает про четыре Q и месит вме в одну кучу: Quality assurance, Quality Approval, Quality Control, Quality check. (Я даже не лезу в ITIL, там веселее).
                В общем виде: обеспечение качества продукта (не только ПО) состоит в контроле производственного процесса (Quality assurance при производстве элементной базы должно контролировать даже уровень загрязнения воздуха в рабочих зонах, а при разработке ПО в эти процедуры как раз входит code review и сверка накарябанного кода с проектной документацией), проверке работоспособности полученного продукта (Quality Approval), Quality Control отлавливает недокументированный функционал типа нажатия 144 раза на вершний правый угол кнопки в IE 2.0 когда Луна в тротике Рака, и элементарная операция это Check (Quality Check), эта операция имеет свой номер и лицо ответственное за ее проведение, которое можно бить если в заданном чеке у клиента чтото вылезло.
                Так вот… К чему это я. QA engineer — это лицо занимающееся инженерной деятельностью (в идеале), то есть планирование операций по Quality Assurance, Approval & Control для технического персонала, а технический персонал это либо tester, либо QA-tech.
                Хотя это не идеал к сожалению. Введение адекватных процессов тестирования и отладки продукта в IT сфере это мечты :) Так как требуется адекватное начальство, адекватный HR, адекватные разрабы(как инженеры-планировщики, так и техники-кодеры) и адекватные тестеры(опять же как и постановщики-планировщики, так и эмуляторы клацательных скриптов). Одновременно все эти люди в одной компании резко работают :)
      • 0
        (материализовался в привычный толсто-зеленый образ):

        А есть ли действительная польза от code review? Насколько я испытал на своей шкуре, это сталкивание двух (или более) взглядов на код, чаще всего только тормозящий разработку.
        Лично я вижу профит в этом только в обучении менее опытного кодера матерым.

        Наконец, если выразить уж совсем субьективное имхо — мое фи код-ревью!
        • +1
          Код-ревью — это хорошо, особенно когда есть ответственный за модуль, и он делает ревью всех коммитов, и всегда в курсе что в его модуле происходит и не допускает бардака.

          И да, ошибок на этапе код-ревью тоже много отлавливается, если проводить его не для галочки.
        • –1
          > А есть ли действительная польза от code review?
          > это сталкивание двух… взглядов на код, чаще всего только тормозящий разработку.

          примерно то же можно сказать о тестировании

          к слову о толсто-зеленом образе
          известен очень эффективный способ обойтись без код-ревью, тестирования, как отдельной активности,
          и без qa/тестировщиков как таковых: просто начать штрафовать дэвов за баги, отданые заказчику в релизах

          после внедрения такой практики обычно отношение и к код-ревью, и к тестированию может поменяться
        • +1
          — Взглянуть на код и логику свежим взглядом (как своим, так и чужими)
          — Когда сам расскажешь другим людям про свой код (особенно про алгоритмически или логически сложные места) — сам можешь понять в чем могут быть проблемы
          — Познакомиться с кодом и логикой, которая происходит в параллельном компоненте/классе
          — Научиться у гуру и научить недогуру
          — Получить фидбек на свою работу у коллег
          — Синхронизировать понятия хорошего кода с коллегами (ведь хорошо когда код в проекте хороший не только ИМХО)
          — Найти баги
          — Найти забытые грязные хаки
          — Найти забытые закоментированые участки кода и прочий мертвый код

          У нас на ревью (чаще, правда, не кода) порой была практика аля «до конца недели каждый должен найти по 5 уникальных проблем и описать их в трекере» — мотивирует почитать не для галочки. :)
        • +2
          Kevin Burke и еще масса людей с вами не согласны, есть и статистика.

  • 0
    Сейчас работаю над такой задачей: Завести как можно меньше багов, те есть находить дефекты, которые исправят сейчас. Желательно, без трекеров и прочей волокиты. На те, что не признают подлежащими фиксу времени не тратить.

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

    Как-нибудь напишите об одном месяце и миллионе строк кода. Любопытно и полезно, я думаю.

    Еще хотелось бы услышать ваше мнение о разнице в тестировании проектов и продуктов, b2b и b2c, чует мое сердце, разница есть и приличная, а на b2c поработать не довелось.
    • +1
      Про «отсутствие трекеров и волокиты» — сталкивалась с таким, но редко. Обычно всё-таки нужны баги, которые и через месяц не грех исправить, но прямо сейчас времени нет.

      Опять же, всё зависит от контекста, тестирование везде разное и цели у него разные. Возможно, в вашем случае именно так и должно быть, именно это — самое подходящее тестирование. Каждый второй шаблонизированный тестировщик будет пускать ахи и охи, говоря, что «баги надо заносить все!». Но умение подстраиваться под нужды конкретного проекта — искусство.

      Про тесты на миллион строк кода как-нибудь напишу, а про b2b и b2c врядли. Опыт большой и там и там, но магических отличий я не вижу. Между 2-мя проектами b2b или 2-мя b2c зачастую отличия больше, чем между b2b и b2c. Это как отличия в ДНК: между мужчиной и женщиной их больше, чем между мужчиной и обезьяной-самцом или женщиной и обезьяной-самкой :)))
    • +1
      > Искать баги просто чтоб менеджер знал, имел информацию и мог принимать решения не вижу ни смысла, ни радости.

      А смысл в этом следующий. Тестирование — работа с качеством продукта, то есть со степенью соответствия продукта его назначению и требованиям (а менеджер ведет продукт от идеи до деплоя). И результат тестирования — заключение о качестве конкретного релиза. Хотя бы потому, что тест — это проверка (чего? соответствия чего чему? какой уровень соответствия?). В конечном итоге решение о выпуске принимает менеджер, поэтому если он не знает уровня качества, решение он принять не может. А радость для тестировщика заключается в следующем — если менеджер выпускает продукт с отрицательной визой тестирования — тестирование не несет ответственности.

      Что касается, как называть QA или тестирование, проверку качества продукта, то QA больше работает с процессами и на предупреждение дефектов, нежели с конкретным продуктом.
      • 0
        Лирика.

        А на практике менеджеру не интересно, сколько некритичных для выпуска дефектов есть в продукте.
        Решение по выпуску зависит от того, есть ли критичные для выпуска баги. На них и стоит тратить время.
        • 0
          Не лирика, некоторые так живут. Что касается что неинтересно, сколько некритичных дефектов — вообще-то интересно, но конечно не настолько, насколько про критичные. Кстати решение о критичности — бывает и совместным решением, менеджера и тестировщика, а то и менеджера и тестировщика и аналитика.

          В общем смысл моего предыдущего поста в том, что измерение качества продукта — отдельное дело, и результат измерения — вход для процесса определения дальнейших действий. То есть результат тестирования не баг в трекере, а картина по продукту, желательно в разрезе корневых причин. Сам по себе баг не очень-то нужен, нужно исследование о работоспособности продукта в некоторых условиях (например, в условиях платного MS SQL, и может не волновать, работает ли на SQL Express, пусть там хоть падает — менеджер например знает, что в такие места поставляться не будет).
        • –1
          К счастью, не всегда. Практика «не выпускать релиз с больше чем N некритичных багов на KLOC» достаточно популярна. Но естественно всё зависит от проекта и его текущих приоритетов.
  • 0
    Всегда думал, что правильно составленый список тест-кейсов — залог качественного тестирования продукта.
    • 0
      Всегда проблема их правильно составить. Разработчик знает систему, которую разработал, поэтому, что называется, «глаз замыливается» — начинает полагать, что с системой будет работать его двойники.
  • 0
    Тестирование — это не поиск ошибок, это процесс разработки системы. Чтобы понятна была мысль, вот риторический вопрос (разработчикам): сколько времени вы проводите, отлаживая код? правильно, 80% минимум.
    Так что, тестирование — это не работа тестировщика (точнее, не только его), но работа разработчика.
    Соответственно, в ход пущены автоматизированные средства: юнит-тесты, автоматические, интеграционные, реже — стресс-тесты, и это все ДО того, как готовый модуль попадет в беспощадные лапы тестировщиков.

    При таком подходе тестировщики скорее выявляют не столь явные ошибки, а скорее, логичное с точки зрения ТЗ, но не очень понятное человеку, поведение системы, юзабилити-проблемы, реже — баги из области «проявляются при особом расположении звезд», а также те, на которые чел с обычными девелоперскими мозгами ни за что не обратит внимания проверить, но зато очень часто натыкаются те юзеры, которые всю жизнь провели за бумажками, а тут их обязали использовать эти страшные и коварные консервные банки с непознанной душой.
  • 0
    Автору могу порекомендовать ознакомиться с ACC от Google — очень помогает в распределении приоритетов в тестировании, и создании общей картины потенциальных проблем в приложении.
  • +1
    Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает.

    Хм, так почитаешь и начинаешь думать, что сможешь работать тестером, причём будешь хорошим тестером. :) А если серьёзно, то не понимаю а как можно тестировать по другому? Я хоть и не тестер, но автоматические тесты разного уровня пишу постоянно, просто чтобы зафиксировать поведение унаследованного кода, о котором толком ничего неизвестно, вплоть до того, что фиксируя что-то тестом не понимаешь баг это или фича. А через некоторое время получаешь багрепорт, пишешь на него тест, фиксируешь баг, исправляешь и видишь другой свалившийся тест, думаешь «приплыли, опять ночь не спать», смотришь тест, а он инверсия к бажному :) Но, отвлёкся, по мне так самое естественное зафиксировать основной поток выполнения, самую штатную операцию. Если говорить, например, о переводе средство с одного счёта на другой, то сначала делаю перевод с одного аккаунта на другой имеющейся на первом суммы, и только когда увижу зелененький начинаю продумывать «а если денег не хватит» и т. п., и только потом лезу в код чтоб покрыть ветвления и переполнения. Как может быть по другому просто не представляю.

    Так вот, фиксируя тестом
    • 0
      Так вот, фиксируя тестом
    • +4
      1. если денег не хватит
      2. если денег слишком много
      3. не потерялось ли по дороге
      4. отменяется ли в случае ошибки (разрыва связи, выкл. сервера и т.д.) и правильно ли отменяется
      5. корректна ли сумма? (только цифры, только положительна)
      6. нет ли накапливающейся ошибки округления?
      7. а если кнопочку нажали два раза?
      8. а если забыли нажать и закрыли окно?
      9. а если параллельно два перевода на\с один из счетов?
      10. если валюта разная и в те мс, пока идет перевод, курс валют поменялся?
      и т.д.

      многие ошибки ой как неочевидны, а еще многие и вовсе заставляют идти на компромисс с человеческим пониманием процессов конкретной области.
      • 0
        Андрей, отличный тест-набор!!!

        Только не хватает ПЕРВОГО пункта — «а что если всё хорошо?» :)

        То есть и эти 10 прогнать надо, и самый основной. И НАЧАТЬ нужно с ОСНОВНОГО, когда всё хорошо. Но ведь основное редко ломается, поэтому тестировщики часто начинают сразу с негативных сценариев. А критичность негативного в разы меньше, чем самой стандартной ситуации.
        • 0
          да, Наталья, это нулевой )
          а на самом деле я еще не покрыл различных комбинаций этих и многих других ситуаций — скажем, все эти одиночные тесты пройдены, а редкая их комбинация, которую еще с большим трудом и сымитировать-то можно — баг.
      • +1
        Это всё потом, сначала убедиться, что фича в штатном случае работает именно как я её понимаю. Иначе можно попасть в ситуацию вроде такой: при переводе автоматически списываются проценты с отправителя и получателю приходит уже уменьшая на, скажем, 0,8% сумма. Не сделав этот тест первым я многие остальные тесты напишу неправильно и буду искать ошибку там где её нет.
        • 0
          Да, это самый глубокий корень багов — недостаточно формализированное или непонятое ТЗ.
          Отчасти эту проблему помогает решить методика BDD.
          • 0
            Ну, в моём случае всё ещё хуже. Есть исходники, которые как-то работают. Ни ТЗ, ни внятной документации нет, автора не найти, да и вряд ли он что помнит. Собственно и пытаюсь привести проект к виду как будто он разработан с помощью BDD/TDD (толком разницу между ними не понял), восстановвить ТЗ так сказать.
    • 0
      Ну это вы как обычный человек отвечаете :)) А не как тестировщик ;))
      • +1
        Судя по посту либо как обычный человек, либо как хороший тестировщик :)
  • 0
    Где-то так, да. Причем чем больше проект тем ближе это к истине.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    > И да пребудет с вами сила!
    Логика, не магия.
  • 0
    Обожаю выковыривать нестандартные баги. Это такая форма айтишношго троллинга. Типа, " а вот если я в вот тут вот нажму четыре кнопки, то вот там вот шнурки развязываются, а не должны".
  • 0
    Может вы и правы, имея ввиду тестирование вебсайтов, которые все равно через полгода будут переделаны и ненайденные баги пропадут необнаруженными.
    Но есть и другие продукты, с другими требованиями. например, Java компилятор и JVM. Казалось бы, прогнали компилятор через себя, работает, что еще надо? Но нет, при тестировании ставилась задача проверить все утверждения из спецификаций. Написано, что размер кода метода должен быть больше нуля и меньше 65536 — значит надо сделать методы длиной 0, 1, 65535 и 65536, и если 65536 машиной не отвергается — файлишь баг. Но это самай простая ситуация. А есть еще правила вывода типов переменных при слиянии ветвей исполнения, поведение volatile переменных (до появления нынешней memory model) и многие другие пыльные углы. И если бы тестировщики и разработчики относились к тестированию также как Вы, то Java никогда не стала бы столь популярной как сейчас.
    • +1
      Эм.

      Не поняла, с чем Вы спорите.
  • 0
    в целом все верно написано

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.