Что же это за школы, и чем они заслуживают наш интерес?
Школа тестирования - это призма восприятия отрасли, философия нашей деятельности, которая влияет на подходы, выбор инструментов и т.д. Существуют различные школы психологии, различные школы искусств и языковые школы. Они подразумевают различные подходы, трактовки, методологические инструменты для достижения одинаковых целей. Какие же школы существуют в тестировании?
Аналитическая школа
Появившаяся первой на заре становления компьютерных технологий, аналитическая школа утверждает: "всё можно протестировать, всё можно измерить, есть один наилучший подход к тестированию в каждом конкретном случае". Приверженцы этой школы стараются всё измерить, применяют массу формальных измеримых метрик и стараются делать процесс тестирования наиболее технологичным. Стандартный тестировщик аналитической школы, на самом-то деле, разработчик :)
Стандартная школа
Чуть позже появилось понимание тестирования как действия, которое не может быть "абсолютным", но в каждой ситуации оно должно максимально помогать выпуску релиза, быть планируемым, контролируемым, измеримым. Сторонники стандартной школы тестирования в основном занимаются валидацией - проверкой реализации требований, для чего они создают тесты, детальные планы, измеряют покрытие требований тестами. Самый распространённый тестировщик в стандартной школе - вчерашний студент, ежедневно выполняющий однии те же детально описанные тест-кейсы.
|
|
|
Гибкая школа
А потом появился Agile! Короткие итерации, отсутствие документации, маленькие дружные команды, отсутствие чётких границ ответственности повлияли на восприятие роли тестировщика. Чаще всего, в Agile воспринимается только две роли тестировщика: это либо разработчик, пишущий автотесты, либо аналитик-внедренец-тестировщик, который исследует продукт больше, чем тестирует. Основная задача тестировщика в Agile - сказать, что итерация готова.
Школа качества
В тестирование чаще всего идут люди с определённым складом характера: перфекционисты, желающие счастья конечным пользователям. Поэтому они далеко не всегда готовы выпускать продукт, в котором самая редкоиспользуемая кнопочка на один пиксел левее, чем должна быть. Критерием качества является их субъективное мнение, для реализации которого можно и нужно менять процессы, заставлять разработчиков менять продукт и жизненные принципы и стоять на своём: "Этот продукт выпускать нельзя, пока не исправить...".
Контекстная школа
Адепты контекстной школы говорят: неважно, какое тестирование, нет "правильно" и "неправильно", есть пододящие в наших условиях техники и методы, а есть неподходящие. Давайте договоримся, что нужно нам?
|
|
|
А теперь - главное. Зачем все эти разговоры про школы, зачем их разделять, в чём сакральный смысл?
1.Мы очень часто "заигрываемся" в свою философию. Сторонник гибкой школы всегда убедит себя, что бага некритична, и продукт следует выпускать - в то время как сторонник школы качества будет стоять на своём, пока не вынесет мозг разработчикам и не убедит в необходимости исправлять дефект. Кто из них прав, спросите вы? Тот, чьё мнение наиболее уместно. Которое соответствует реалиям проекта, а не "является правильным, потому что правильное".
2.Нам очень сложно найти с кем-то общий язык, если мы используем разные словари. Если вы и ваш руководитель - адепты разных школ, то понимание вам не светит! В этом случае лучшим решением будет обсудить, проговорить требования к тестированию в вашем проекте. Вообще, почти все конфликты в тестировании (как внутри команды, так и с разработчиками, РМами) происходят именно из-за следования различным школам. Обсудите это!
3.Есть люди с гибким восприятием, которые следуют контекстной школе и могут комфортно работать в различных условиях, а есть такие, которым нужен определённый привычный подход. Если вы относитесь ко второму типу - при выборе работы обязательно убеждайтесь в соответствии школы вашей и принятой в компании. Несоответствие школ неизбежно приведёт к неудовлетворению на работе, а ведь вам это врядли нужно, правда? :)
|
|
|
4.Пересмотрите принятые в вашей компании решения: автоматизировать тесты или нет, документировать или нет, как оценивать качество продукта... Являются эти подходы "правильными потому, что так принято" - или они используются исходя из особенностей проекта и действительно соответствуют контексту?
5.Вспомните хорошенько все споры на тему "баг это или не баг", "насколько он критичный", "когда его исправлять" и т.д. Почему происходили эти споры? Помогла ли вам сегодняшняя заметка в понимании причины конфликтов, сможете ли вы теперь более адаптированно искать баги и нивелировать конфликты?
Всем удачи и до скорой связи!
Выпуск #8: Баг-трекинг
Привет,
Сегодня я хочу рассказать про баг-трекинг: что это, зачем он нужен и что такое качество заведения дефектов.
Начнём с самого главного: что такое баг-трекинг и зачем он нужен?
В большинстве современных компаний используются специальные системы для регистрации дефектов, или багов. В эти системы тестировщики заносят найденные ошибки, разработчики их исправляют, а менеджеры проектов смотрят статус продукта. Ведение дефектов в таких системах и называется баг-трекингом.
|
|
|
Кстати, если ты читал книгу Канера, то явно знаком с подходом к баг-трекингу, который применялся десятки лет назад: печать багов на бумажках в трёх экземлярах с передачей этих листков разработчикам :) К счастью, эти времена давно прошли, и для баг-трекинга используются специальные системы, называемые баг-трекерами.
Но зачем что-то в них регистрировать, почему нельзя устно сообщить о проблеме? Причин несколько:
·Информация может забыться, потеряться, поэтому её важно хранить в одном месте
·Менеджеры проектов используют баг-трекер для анализа: "готов ли продукт?", "сколько задач ещё необходимо выполнить?" и "когда я могу обещать выпуск релиза руководству?". Для этого они считают баги, смотрят графики, анализируют сходимость дефектов, а сделать это по бумажкам не представляется возможным.
·Структурируя информацию мы можем отслеживать статус и не забывать про свои задачи, связанные с уже заведёнными дефектами. Да-да, просто завести их мало, их ещё поддерживать надо, но об этом ниже.
При этом от того, насколько качественно мы заводим дефекты, во многом зависит, будут ли они исправлены и когда. Что же такое качество заведения дефекта?
·В первую очередь, это точность дефекта. Чем точнее мы можем определить причины неработоспособности, тем лучше. "Иногда здесь что-то не работает" - это не дефект. Когда именно? При каких условиях? Обобщая влияющие факторы, мы проводим генерализацию дефекта, а сужая набор факторов, мы локализуем дефект. К примеру, мы тестируем калькулятор, и 2+2 не работает. Двоечник сразу заведёт ошибку, а джедай начнёт анализировать: а другие операции? А другие числа? А другие последовательности, окружения, условия? Чем точнее дефект, тем проще разработчику его исправить, а менеджеру проекта понять его влияние.
·Во-вторых, это добавление любой полезной информации. Логи, краш-дампы, скриншоты. Не жалуйтесь, что это долго, иногда одна минута на добавление полезных файлов сэкономит несколько часов вашему проекту!
·В-третьих, это оформление дефекта. Понятно ли всё описано? Иногда то, что понятно вам, абсолютно непонятно другим людям. Занося дефект, вы его уже знаете, и вам кажется, что всё ясно. Возьмите за привычку перед отправкой дефекта прочитать его глазами "человека со стороны". Точно ли всё понятно?
Конечно, помимо вышеперечисленных пунктов в каждой компании есть свои собственные правила: как формулировать заголовок, какие поля заполнять и т.д. Но перечисленные выше пункты являются общими и всегда очень важны для любой команды.
Ну хорошо, представим, что мы заводим качественные дефекты. Этого достаточно?
К сожалению, нет. Также нам очень важно:
·Правильно указывать критичность дефекта. А это зачастую невозможно, если вы плохо знаете заказчиков, клиентов, бизнес-сторону вашего продукта. Если РМ или аналитик регулярно понижает критичность вашим дефектам, значит, вам экстренно не хватает знаний о бизнесе! А если это так, то у вас и тестировать продукт правильно не получится. Вывод? Узнаём, исследуем, спрашиваем аналитиков, РМ'а, внедренцев.
·Проверять исправление дефектов. Каждый раз, когда разработчик помечает дефект как исправленный, в этом ещё надо убедиться. Причём, помимо проверки самого дефекта, посмотрите немного "вокруг": вдург при починке было сломано что-то "рядом"? Обычно, так оно и происходит.
·Регулярно узнавать мнение о дефектах у коллег (разработчиков и РМа): устраивают ли их заводимые дефекты? Всё ли понятно? Если кто-то на что-то жалуется - выясняйте, как это можно улучшить. Только непрерывно совершенствуя своё мастерство вы можете начать заводить действительно отличные дефекты.
Пожалуйста, не забывайте, что заводимые вами дефекты - это интерфейс взаимодействия со всей командой на проекте. Я неоднократно сталкивалась с ситуациями, в которых опытный тестировщик находит много отличных дефектов, но заводит их так ужасно, что вся команда над ним посмеивается и он теряет авторитет, да и проект от этого только страдает.
Думаете, что это не про вас и что у вас всё отлично с дефектами? Поговорите с разработчиками прямо сегодня и узнайте их мнение ;-) Если вам все ответят "твои баги заводены просто отлично", то будет серьёзный повод погордиться, а если они расскажут о проблемах, то появится отличная возможность их решить.
Удачи!
Дата добавления: 2018-02-28; просмотров: 756; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!