Говоря о качестве ПО, зачастую имеют в виду определенное соответствие фиксированным требованиям. Порой под требованиями подразумевают те ключевые особенности продукта, которые желает реализовать клиент или тот, кто уполномочен выдвигать такие условия. И очень плохо, если такие требования трактуются как неоспариваемые, что в конечном итоге ведет к самоцели – требованиям клиента.
Подобное регулярно встречается в аутсорсе, и такой фокус внимания негативным образом влияет на итоговый результат – то, что видит заказчик и с чем потом взаимодействовать потенциальному пользователю.
Данная статья рассматривает понятие «качество» в более широком понимании, чем это можно трактовать с позиции поддержки программного обеспечения, которое взято в обиход в компаниях по тестированию ПО.
Качество – это больше про разработку, а не про тестирование
Многие связывают понятие качества с процессом проверки программного обеспечения. Но это в корне неверная позиция, ведь качество определяется факторами того, как сделано ПО, а не как оно протестировано.
Вся команда несет ответственность за качество продукта, а не просто отдел разработки или технической поддержки. Но, конечно же, переживать за качество в первую очередь должен именно разработчик, так как это его персональная ответственность, если определенная фича не работает, так как нужно.
Крайне странно утверждать, что все готово, если до конца подобной уверенности нет. Ее получить можно сразу несколькими способами – процессными и технологическими (включая тестирование ПО).
Но нужно помнить, что всю ответственность на QA возлагать тоже неправильно. Выделенный этап мануального тестирования после реализации ПО не должен превращаться в узкое место, и в идеальных условиях даже не должен трансформироваться в необходимость.
Работы над качеством ПО должны входить в реализацию этого продукта. А качество должно быть равноценно слову «сделать».
Устойчивость к изменениям
Во всех проектах, которые длятся довольно долго, наряду с уровнем качества крайне важно и качество системы, их техническая устойчивость к возможным изменениям. А все мы знаем, что рано или поздно изменения будут!
Дабы тестируемая система могла нормально функционировать и развиваться, изменения должны быть частыми. К ним нужно относиться как к чему-то обыденному, рутинному, а не возводить в ранг исключительности. Для этого нужно усвоить тот факт, что изменения кардинально ничего не сломают.
Не всё, что ломается – баг
Восприятие багов можно поделить сразу на несколько составных. С одной стороны, их сумма зависит не только от того, как именно создан код (насколько он технически чист), а и от того, что конкретно принято именовать дефектом.
В программном обеспечении любого уровня можно обнаружить формальный дефект. Но не на постоянной основе нужно все фиксировать. Порой это всего лишь бессмысленная генерация лишнего труда, а соответственно и трата денег.
Конечно же, это не призыв игнорировать баги, а просто предположение касательно того, что нужно разграничивать важное и второстепенное.
Иногда случается так, что QA отдел попросту углубляется в детали, тратит массу времени и существенным образом отклоняется от составленного ранее маршрута следования. Можно потратить много времени и сил на тестирование верстки на соответствие макету, и при этом не оставив ничего на исследование базового пользовательского сценария.
Что вообще тогда нужно тестировать?
Тестер – это нулевой пользователь системы, который должен идеально знать работу ПО как снаружи, так и изнутри. Его деятельность стоит ориентировать на обеспечение работающего опыта пользователя, а не на банальную проверку выполненных задач отделом разработки.
Стоит тестировать то, что готово, а не что делалось изначально. То есть работать с фичами, а не с задачами.
Первоочередная задача любого тестировщика – не найти максимальное количество багов, а сделать все, чтобы их стало как можно меньше. Тесты эффективны только тогда, когда они могут приносить дополнительную ценность, а не просто компенсировать недостатки со стороны разработки.
Выводы
Из всего вышеописанного можно сделать следующие итоги:
- Выполнение изначально установленных требований – не самоцель тестирования. Важнее всего в конечном итоге выпустить хороший продукт.
- Клиентский опыт крайне важен.
- Тестирование – это своего рода бонус, который должен улучшать систему, а не критическая необходимость.
Оставить комментарий