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

[highlight dark=”no”]Именно они помогают «выживать» на работе и превращают вас из неуверенного новичка в сурового инженера за контролем качества ПО[/highlight], если вся ваша команда по тестированию – это только вы!

Подружитесь с бюрократией

В принципе есть очень ограниченное количество полезных для тестировщика категорий. Одни из них – бюрократия и процедуры.

И все дело не только в том, что ее придумали не просто так, а устареть и потерять актуальность она еще не успела.

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

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

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

Нужно понимать, как все работает

Главное, что всегда требовалось и будет требоваться от тестировщиков – понимать то, что сделали разработчики и каким именно образом. Только понимание того, из чего состоит работа, позволяет мгновенно вникнуть в ситуацию, осознать личностные границы ответственности на определенном проекте.

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

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

Программисты – ваши самые лучшие друзья

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

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

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

Планирование и еще раз планирование

Без приоритетов никуда. Четко проставленные цели позволяют не только осознавать, что человек делает и зачем, но и позволяет выкинуть из головы тревогу о том, к примеру, что до конца недели (условно) нужно допроверять функционал навигации или же занотировать ошибки в отчетах об ошибках.

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

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

Тестировщик – не единственный, кто отвечает за качество ПО

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

Это значит, что тестировщик может и даже должен доносить этот постулат до остальных заинтересованных лиц внутри своего трудового коллектива.

Работайте над тест-кейсами

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

Ищите информацию

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

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

Поиск чего-то нового это не просто улучшение общего процесса покрытия проверками функционала, но и существенная прокачка так называемого experience based testing (методики создания тестов на основе опыта).

Перфекционизм прочь

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

Идеального ПО попросту нет. Хотя бы по той причине, что представление идеала у всех нас разное. Создать ПО под каждого отдельного клиента – непозволительная роскошь.

Другими словами, дело всегда зациклено на поиске всеобщего компромисса.

Создавайте личную историю в бэклоге

Дайте ей название, например, BUG, и вносите в нее все новые дефекты, которые по каким-то причинам пока не можете подложить к текущим проектным задачам. Это имеет можество преимуществ.

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

Получайте от работы удовольствие

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

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