Определенные экстремальные вовлеченности можно запросто применить к любой современной профессии. Подобное дело касается даже QA-инженеров разноплановой направленности. Но, всегда есть определенные оправдания, к которым склонны все мы, в процессе выполнения своих профессиональных обязанностей.

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

Далее рассмотрим наиболее популярные «рабочие» оправдания, которые можно применить к тестировщикам.

Оправдание №1: «Я не понимаю, как этот функционал должен работать»

Порой, тестировщики слепо следуют скудным указаниям со стороны программистов. Как итог – тестировщик вообще не понимает, чем конкретно он занят и что именно необходимо проверить.

Например, менеджер проектов поставил задачу проверить, что SQL-запрос проходит корректно, а конечный итог равен значению «1». Но почему? Какой дополнительной информацией можно воспользоваться? Как понять, что полученный ответ корректен? Если будет так, что внутри тестируемой особенности баг, как можно будет  потом доказать менеджеру проектов, что вы реально ее проверяли?

Если вам, как ответственному за качество проекта, вручили сотни страниц технического текста, из которого вы вообще ничего не можете понять, попробуйте «нагрузить» менеджера или разработчика вопросами. Если программист не в состоянии  внятно объяснить принцип работы новой особенности, поищите того, кто точно сможет.

Как вариант, можно попробовать переформулировать данные, с которыми вас предварительно ознакомили, чтобы максимально понять, что вы все правильно поняли. По возможности, [highlight dark=”no”]требуйте чтобы информацию вам «выдавали» в той форме, в которой она на 100% имеет смысл и логику.[/highlight]

Пример: если тестировщик позиционирует себя как человека, которому лучше всего визуального «поглощать» информацию, можно вместе с разработчиками попробовать выстроить логически понятные графики и диаграммы, где детально будет отображен каждый шаг и тест.

Оправдание №2: «Эту особенность невозможно проверить»

Представьте себе, иногда некоторые тестировщики с полным серьезом произносят подобную фразу!

Подобным словам никогда и ни при каких условиях не нужно верить. Да, порой случаются ситуации, когда функционал не может быть проверен из-за того, что у тестировщика банально нет доступов в панель администратора. Решение простое – вежливо [highlight dark=”no”]попросить программиста показать, как эта особенность работает.[/highlight] Можно даже скоординироваться и прогнать парочку тест-кейсов под их (разработчиков) строгим наблюдением.

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

Оправдание №3: «Программист создал «не тот» код»

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

Подобные ситуации не будут возникать при условии, когда [highlight dark=”no”]проектная группа всегда будет принимать общие и заранее проговоренные решения[/highlight] и [highlight dark=”no”]если критерии приемки в тест будут подтверждены тестировщиком.[/highlight]

Если тестировщик проводит проверку продукт только на основании слов программиста и проверяет выборочные части кода, то это исключительно его профессиональная вина.

Тестировщик – это своего рода «крайняя защита»продукта перед тем, как он попадет конечной группе пользователей.

Задача тестировщика – постоянно убеждаться в том, что клиент получает именно то, на что изначально рассчитывал!

Оправдание №4: «Этот баг пропустил другой тестировщик»

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

Как вариант, можно использовать [highlight dark=”no”]попарное тестирование:[/highlight] например, тестировщик №1 изначально проверяет ПО, а тестировщик №2 прогоняет тест-кейсы программного обеспечения в другом окружении. Как итог, второй тестировщик обязательно найдет несколько существенных ошибок, неумышленно пропущенных первым.

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

Подобное явление – это банальная обыденность, которая в науке именуется «ситуационной слепотой».

Оправдание №5: «На полноценную проверку не хватило выделенного времени»

Будем честны сами с собою, на полноценный тест продукта, заявленного в отдел тестирования, [highlight dark=”no”]никогда и ни при каких условиях не хватит времени.[/highlight]

Программисты, как и тестировщики обладают профессиональными временными рамками. Может они бы с радостью перешли к разработке нового функционала еще до того, как ответственный тестировщик согласился проверить проверяемою особенность.

Совет: прочь отговорки, тестируйте самые важные части продукта, пытайтесь правильно и с умом распоряжаться выделенным временем.

Оправдание №6: «Если я найду дефект на готовом сайте, меня спросят, почему я не сделал это во время основного теста»

Если в вашей компании есть менеджеры, которые ругают тестеров за то, что баги найдены уже на готовом сайте, бегите от подобных управленцев как можно скорее!

Нет еще в мире тестировщика, который за один или даже несколько циклов проверки программного обеспечения нашел бы в нем все до исключения баги! Программное обеспечение запросто может функционировать некорректно тысячами различных способов!

Все что может проверяющий, это [highlight dark=”no”]своевременно сообщить о найденном дефекте[/highlight] ответственному лицу (менеджеру или программисту), и впредь знать и понимать, где в потенциале «водятся» баги.

Совет: если вы зашли на готовый сайт и увидели там даже мало-мальски заметный баг, немедленно сообщайте об этом разработчикам, иначе в следующий раз его заметит заказчик или сотни тысяч пользователей!

Оправдание №7: «У меня нет знаний языков программирования, я не умею создавать ПО»

Процесс создания программного обеспечения на начало 21 столетия и сейчас (2020 год) сильно изменился. Если раньше продукты выпускались, в лучшем случае, раз в полгода и тестировщик имел достаточно времени на регрессионное тестирование, то сейчас темп разработки существенно возрос.

У тестировщика нет времени полноценно проверить продукт, а значит, без процесса автоматизации тестирования уже никак не обойтись. Идти на специализированные курсы, например, по Java, нет острой необходимости, так как современные языки программирования базируются на понятных принципах логики, которые освоить не составляет существенного труда даже новичку. Наибольшая сложность лишь в том, что нужно знать синтаксис каждого языка по отдельности.

Если в фирме, где вы устроены, нет автоматизации, можно банально [highlight dark=”no”]попросить программистов создать несколько простых тестов.[/highlight] Затем можно обратиться к умелым тестировщикам, чтобы они помогли визуализировать созданные разработчиками сценарии.

Стартуйте с малого! Не нужно в одночасье пытаться освоить все и сразу. Анализируйте процесс создания кода, как изучение нового для вас языка. В процессе, когда вы изучаете для себя новый язык, никто же не требует от вас максимальных знаний уже через два дня после старта изучения. Вы учите несколько фраз и так двигаетесь дальше. То же самое применимо и к процессу познания нового языка программирования.

Краткий итог

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