«

»

Июл 17

О 10 вариантах замедления производительности вашей команды

photo by Dave Proffe

photo by Dave Proffe

Увидел интересную ссылку на простенький пост о том, что из тестирования влияет на скорость работы команды. Десять вариантов подсмотрены здесь.

Эта простота заставила задуматься, так ли это преступно с точки зрения тестировщика? Нет. Злодейски ли с позиции командного духа? Velocity?
Ммммммм…

Ниже вольный перевод и мои мысли, без какого-либо позиционирования.

  1. Тратите время на отчеты о проблемах, которые есть на продакшине и о которых не сообщают пользователи.

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

    Неисправленные дефекты с продакшина в баг-трекере. Их много, работу работать надо, беда-беда… — это нормально.

    Сообщенный дефект пользователем (да пусть, например, новым), и наличие этого дефекта в багтрекере, созданным тестировщиком несколько релизов назад. Крайнего точно искать никто не будет, и уже исследовать ошибку так досконально не надо.это прекрасно.

  2. Требуете исправления всех ваших ошибок, несмотря на приоритеты других.

    Мои ошибки самые важные!!!111 Вы не один, у всех все самое важное…это ужасно.

    Ошибки должны быть исправлены. Ну здесь, как бы, догма 🙂это нормально.

    У ошибок есть приоритеты, которые могут быть пересмотрены. У людей есть запланированные задачи в рамках спринта\итерации. Планирование — этап какой-никакой зрелости и повод для роста-развития.это прекрасно.

  3. Не сообщаете результаты тестов, пока не закончите тестирование.

    Держите интересную информацию при себе. Невидимый прогресс-бар, представьте себе… — это ужасно.

    Молчание — золото! «Иногда лучше жевать…» — это нормально.

    По неполной информации могут быть сделаны неверные выводы. Не дадим ошибиться команде и менеджменту. Чип и Дейл inda Test Department.это прекрасно.

  4. Не рассматриваете использование тестерских инструментов.

    Проводим тестирование нагрузки быстро-и-часто-кликая? не новость, да. — это ужасно.

    Это время. Это учить. Это не понятно, как сработает. Отмазки… отмазки…это нормально.

    Новое! Попробовать! Быстрее и интеллектуальнее делать работу! Тренинги, семинары и консультации.это прекрасно.

  5. Пытаетесь провести все тестирование самостоятельно, не обращаясь за помощью к не-тестировщикам.

    А как это?! А какого это?! Откуда растут ноги у этого модуля? А как это должно работать на самом деле?это ужасно.

    Тестировщик в идеальном мире существо самостоятельное и самодостаточное.— это нормально.

    Кросс-функциональность. Налаживание коммуникаций. Акутуальность и правдивость проверяемой информации. — это прекрасно.

  6. Тратите все больше и больше времени на регрессионное тестирование, в каждом новом спринте.

    Проверять одно и то же. Каждый спринт. Не важно, есть там регресс или нет.— это ужасно.

    Так бывает — это НЕ нормально.

    Анализировать область регрессии и уменьшать количество «ненужных» тестов. — это прекрасно.

  7. Не чистите тестовое окружение.

    И «грязные» данные тянущиеся от спринта к спринту — заставляют ломать голову лучшие умы. Данные, которые не могут появиться в боевой версии приложения.— это ужасно.

    Время. Не очевидно влияние «грязных» данных — это нормально.

    Иногда данные не «грязные». Иногда накопление информации спринт за спринтом вскрывает проблемы. А уж как удобно проверять версионный апгрейд на старых данных, не создавая их специально.— это прекрасно.

  8. Тестируете так же как и всегда. Не улучшаете свои навыки.

    И выходя на пенсию пользуетесь только методом граничных значений на примитивном уровне.— это ужасно.

    На самом деле знания в технологиях растут до уровня достаточного на проекте.

    Познания в тестировании — на уровне пары книг. — это нормально.

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

  9. Если на тестирование чего-то требуется ещё времени, переносите для тестирования на следующий спринт.

    Задача не выполнена — тестирование не завершено. Да и протестировать хочется всё сразу. — это ужасно.

    Так бывает. — это нормально.

    Можно оттачивать навык оценки задач и планирования дальше. — это прекрасно.

  10. Не начинаете тестирование, пока программист не скажет «Все хорошо, все готово к тестированию».

    Фича медленнее становится готовой. Сначала варим, потом жарим, потом тушим. Микро-ватерфолл на лицо.— это ужасно.

    Программисты тестируют то, что написали! — это нормально.

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

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>