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

photo by Dave Proffe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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