Тестирование ПО – стрессовое занятие.
Причины бывают разные – от жестких сроков и недостатка коммуникации до внутреннего давления. Это связано со спецификой работы в данной сфере. При всей любви к своей работе тестировщики всегда сталкиваются с определенными проблемами, понятными только им.
1. Недооценивание.
“Наши разработчики сами могут проверить свой код”.
Некоторые компании используют это объяснение, чтобы оправдать отсутствие тестировщиков в штате. Это особенно распространено среди организаций с небольшим бюджетом.
Всем нужны тестировщики. Сокращение расходов на тестирование программного обеспечения – не лучшее решение. Команда опытных QA инженеров сэкономит компании гораздо больше времени и ресурсов в долгосрочной перспективе. Выпуск продукта с дефектами приведет к потере огромного количество пользователей, а исправление ошибок повлечет за собой дополнительные финансовые и временные затраты.
Разработчики могут написать программу без ошибок, вводить элегантные строки кода в мгновение ока и даже обнаруживать самые трудноуловимые моменты. Но этого недостаточно.
Несмотря ни на что, в команде всегда нужны грамотные тестировщики программного обеспечения, которые будут применять как ручное, так и автоматизированное тестирование, объединяя эти подходы.
Тестировщики не просто ищут ошибки. Они также улучшают функциональность продукта для заказчика в соответствии с требованиями. Недостаточно просто хорошо сделать ПО. Компания должна выпустить продукт с высоким уровнем юзабилити, который полюбят пользователи.
Следующий аргумент:
«Тестировщики уступают разработчикам». К сожалению, многие люди до сих пор так считают.
Это неправильно.
Хороший разработчик может оказаться плохим тестировщиком, а хороший тестировщик может, в свою очередь, оказаться плохим разработчиком. Для тестирования необходим определенный набор навыков, к которым относится общее знание систем, баз данных и способность к эффективной коммуникации. Коммуникативный навык часто является серьезной проблемой.
2. Временные ограничения.
Тестировщиков обычно включают в проект в последний момент. Но бывают ситуации и хуже:
«Эй, мы планируем запустить этот продукт уже на следующей неделе, можешь ускориться?», – говорит проджект менеджер.
“Ну да, технически…”
После чего мы пытаемся завершить все свои задачи, но невозможно так быстро устранить столько рисков.
Очень часто мы фокусируемся на поиске незначительных ошибок вместо того, чтобы получше вникнуть в программное обеспечение. Мы пропускаем трудноуловимые ошибки в системе, игнорируем поддерживаемость кода и его качество. И это еще не самое страшное при данных обстоятельствах. Как ни старайся, невозможно провести действительно качественное тестирование в условиях дедлайна.
Стоит рассмотреть возможность привлечение QA инженеров к тестированию и сотрудничеству с разработчиками на ранних этапах процесса. Это поможет заранее предотвратить потенциальные проблемы и не пропускать дедлайны. В результате все будут счастливы, особенно пользователи, для которых был разработан продукт.
3. Отсутствие информации
Это худший кошмар тестировщиков. Представьте, что вы провели много времени за чтением кода и написанием тестовых сценариев. Затем вы предоставляете отчет о 32 найденных ошибках, но получаете в ответ:
“О, да это не ошибки. Мы немного обновили функционал. Разве мы не сообщили вам об этом?”
“Нет…”
После чего вы возвращаетесь в свой угол, переписываете все тестовые сценарии и повторяете процесс заново.
Несвоевременная коммуникация между разными командами может привести к множеству ненужных действий и перепроверок. В конечном итоге такие ситуации выливаются в потерю времени и финансов.
4. Тот, кто приносит плохие вести
Никому не нравится слышать фразу “Твой ребенок уродлив”.
Некоторые разработчики не хотят даже думать о том, что их работе требуется “исправление”. Но наша задача – сообщать об ошибках. Это не самая приятная из зон ответственности.
Тестировщик: “Эй, здесь ошибка в строке x”
Разработчик/менеджер: “Приготовься. Я собираюсь долго и упорно объяснять тебе, почему ты полностью не прав.”
В этом случае тестировщики должны привести твердые аргументы, чтобы доказать, что это действительно ошибка.
Но что, если мы ошиблись?
В следующий раз наше мнение не захотят даже слышать. У тестировщиков практически нет права голоса, потому что это не “их продукт”.
Тем не менее, тестировщики формально имеют право заблокировать выпуск продукта, который они считают некачественным. Они несут ответственность за принятие решения о прекращении тестирования и готовности продукта к выходу на рынок. Это может привести к множеству конфликтов между ними и менеджерами. Иногда тестировщиков также обвиняют в намеренном замедлении процесса.
5. Это не всегда интересно.
Не поймите меня неправильно, мы любим свою работу. Это всего лишь общая проблема, с которой каждый сталкивается в какой-то момент своей карьеры, будь то офисный работник или строитель.
Писать одни и те же отчеты об ошибках и выполнять одни и те же тестовые сценарии снова и снова не так увлекательно. Каким бы творческим и неутомимым ни был тестировщик, он всегда будет сталкиваться с повторениями. Трепет и интерес, возникавшие во время поиска багов, со временем начинают угасать.
“А что насчет автоматизации процесса?”
Это одно из решений проблемы. Однако мы, как тестировщики, должны быть очень осторожны. Следует убедиться в том, что все работает, как надо, и уровень тестового покрытия достаточно высокий. Одна ошибка может подвести всю команду. Автоматизация – это палка о двух концах, особенно в тех случаях, когда главная задача тестировщика – обеспечение качества. Всегда нужно оставаться эффективным и при этом находить способы снижения затрат на тестирование программного обеспечения.
Мы спим, чистим зубы, принимаем душ, работаем каждый день. Мы выполняем рутинные задачи, чтобы закрыть базовые потребности и иметь возможность заниматься любимыми делами. То же самое касается тестировщиков. Выполнив основные задачи, мы ломаем программу. И это увлекательно! Мы изучаем программное обеспечение и ищем скрытые ошибки в поисках ценной информации. Тестирование снова вызывает интерес.
6. Это неблагодарная работа.
Работа тестировщика аналогична работе команды, занимающейся подготовкой спектакля за кулисами. Мы убеждаемся, что все идет гладко. Однако только компания, менеджер и разработчики всегда получают уважение и признание. Когда все в порядке, никто не вспоминает о тестировщиках. Ведь это же “наша работа”.
Но что, если компания выпустит свой продукт, и в нем обнаружится баг? Конечно, это будет вина тестировщиков!
Тестирование – это последний этап, который проходит продукт перед тем, как попасть к пользователям. Поэтому крайним всегда будет тестировщик. Все всегда должно быть идеально, даже при горящих сроках и сложных обстоятельствах. И на этот моменте мы возвращаемся к пункту № 2.
Так держать, тестировщики!
Перевод статьи «6 Struggles Only a Tester Will Understand».