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