Заблуждения о тестировании

Второе заблуждение звучит так - “тестировать может любой человек”, если подойти к этому вопросу с чисто физиологической стороны - то да, а если с профессиональной - то нет. Тестирование включает в себя разные стадии от анализа требований до подготовки и выполнения сложных сценариев и формировании отчёта об ошибке, на самом деле процесс тестирования это более глубокий процесс, и уровень тестирования зависит напрямую от накопленных знаний, предыдущего опыта, правильного применения техник и методов, грамотной коммуникации, личных качеств от усидчивости и сообразительности до критицизма и креативности. Для того чтобы начать тестировать нужны как минимум минимальные знания о теории тестирования, а как максимум приходит с опытом.

 

Третье заблуждение о том что “в тестирование необходимо отдавать только готовые продукты”, думаю что это заблуждение напрямую коррелирует с первым заблуждением о том что “мы не можем себе позволить дополнительные расходы на тестирование”, и зачастую является итогом первого заблуждения. Желание сэкономить на тестировании в самом начале часто впоследствии оборачивается намного большими расходами.

 

Четвертое заблуждение звучит так - “тестировщики полностью тестируют программу и гарантируют 100% покрытие”. Представьте себе одну из форм на сайте где вы заполняете идентификационные данные - ФИО, город, адрес, дату рождения, телефон, место работы, емэйл, резервный адрес второй почты, адреса в соц.сетях, секретный вопрос и т.д., к тому же страница поддерживает к примеру 5 языков и кроме того ваши идентификационные данные подтягиваются в разные формы на других страницах. И представьте что вам нужно проверить все существующие комбинации ввода данных - все существующие имена и фамилии, все даты рождения и так далее притом с учётом всех языков на странице и интеграцию с другими формами. Это тысячи комбинаций. Сколько на это уйдёт времени? Вы скажете - так оно и не нужно! И будете правы. Специалист по тестированию с учетом своих знаний и опыта создает нужные логические комбинации на основе специальных методов и техник тестирования, которые способны выявить ошибки в программе и это наиболее подходящие и выверенные комбинации для поиска дефектов, которые предотвращают ошибки, обнаруживают дефекты и помогают увеличить уверенность в качестве продукта, но этих комбинаций не тысячи и не десятки тысяч и соответственно это не 100% всех возможных комбинаций.

 

Пятое заблуждение - “тестировщик виноват в пропущенном баге”. А всё ли было гладко на предыдущих этапах жизненного цикла разработки программного обеспечения? Не были ли внесены изменения в документацию без уведомления специалиста по тестированию? Не появилась ли часть нового функционала раньше чем планировалось на одной из тестовых сред или вообще без уведомления специалиста по тестированию? Достаточно ли было времени на анализ и подготовку тестовых сценариев у специалиста по тестированию? В идеально построенном правильном процессе разработки программного обеспечения редко встречаются критические ошибки после релиза, но зачастую много других факторов влияют на сам процесс разработки - несвоевременное информирование других участников команды об изменениях, слабая или негативная коммуникация внутри команды, несоответствие ожиданиям по срокам бизнеса и разработки, неверно построенный процесс и другие. Важно понимать и брать за основу что в пропущенном баге виноват не тестировщик, а вся команда в целом и искать не виноватого, а пути оптимального роста команды, устраняя грамотно, выверено и толерантно негативные факторы влияющие на это.

 

Поговорим о шестом заблуждении - “тестировать скучно”. Этот вопрос скорее относится к психоанализу и философии человека. Любая работа может быть как скучна так и наоборот, смотря как на сколько ты любишь свою работу, любишь то что ты делаешь, как ты выстраиваешь свой рабочий процесс, какие взаимоотношения внутри коллектива в котором работаешь. Скучна ли работа к примеру второго помощника тренера по хоккею который открывает и закрывает калитку когда команда едет на смену? Если смотреть на это как чисто на механический процесс - то вероятно да, разнообразия мало, другое дело как человек чувствует себя при этом, чувствует ли он себя частью команды, ценит ли команда его за его работу, верит ли он в успех команды, не чувствует ли собственную неприязнь к своей работе, не хочет ли что-то изменить, чтобы делать другую работу, любит ли он то, что он делает. Всё зависит от конкретного человека.

 

Ну и наконец седьмое заблуждение “автоматизация заменит ручное тестирование”.
Ответ однозначный - одно без другого жить не может. Невозможно отрицать факт технологического прогресса автоматизационного тестирования, а также невозможно отрицать того что человеческий мозг прагматичнее и логичнее машины. Невозможно начать автоматизировать предварительно не проанализировав всю имеющуюся информацию, а также не составив лист проверки, тестовых сценариев, а это часть ручного тестирования. А также нет смысла выполнять одни и те же тестовые сценарии многократно в ходе регрессии и ретестинга в ручную если есть возможность их один раз закодировать и поддерживать чтобы они выполнялись автоматически. Специалисты по автоматизированную тестированию углубляются в чистоту кода и соответственно в его сопровождаемость, тогда как специалисты по ручному тестированию делают упор на сложность и логику тестовых сценариев, быть одновременно и тем и тем - большая удача в жизни!

 

 

 

 

 

 

 

Читайте на Facebook:  http://bit.ly/351QYZF

Знаете ли вы чем занимаются тестировщики программного обеспечения? Какова их миссия в общем процессе разработки программного обеспечения? Какие цели они преследуют? Как думаете необходимо ли тестирование и если да - то на какой стадии разработки?

 

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

 

Первое заблуждение “мы не можем себе позволить дополнительные расходы на тестирование”. Сразу хочется вспомнить фразу “скупой платит дважды”, а если разложить по полочкам все стадии процесса разработки программного обеспечения и подсчитать убытки которые несет заказчик в ходе внесения изменений на стадиях общего планирования, формировании пользовательских и системных требований, технической архитектуры и детального дизайна, а также времени потраченного на исправление в ходе разработки, отладки и интеграции модульных тестов - то, все эти убытки выливаются в человеко-часы разработчиков, аналитиков, менеджеров и других членов команды - в итоге получается что “скупой платит в n раз больше”. Чем раньше специалист по тестированию включится в процесс, тем дешевле обходится весь процесс в целом. Так скажем “несоответствие” найденное на ранней стадии - стоит десятки, сотни человеко-часов в будущем.

 

gallery/photo_2020-01-27_12-31-11