Мы работаем в командных спринтах — и после пары спринтов разработки у нас есть тестовый спринт перед внедрением наших изменений в производственную систему. Это в дополнение к модульным тестам и ожиданиям, что люди проверяли свой код, когда писали его, чтобы убедиться, что он работает.
Я заметил, что моя продуктивность сильно падает во время тестового спринта. Тестирование всегда наименее увлекательная часть разработки ( для меня ), и у меня есть проблемы с концентрацией внимания на работе в это время, которых у меня нет при разработке.
В то время как я пытаюсь улучшить свою собственную дисциплину, я также задаюсь вопросом, как это может быть решено с точки зрения руководителя.
Что я могу сделать, чтобы улучшить свою концентрацию и дисциплину? Если бы я был начальником сотрудника, у которого возникла эта проблема, как бы я мог помочь ему добиться большей дисциплины?
Поскольку это мой первый ответ, я хочу немного расширить свой комментарий.
Что я пробовал несколько недель назад, так это ставить перед собой цели и использовать методы тайм-менеджмента. Если вы можете запланировать это, это работает очень хорошо. Я использую это, когда, например, мне нужно подготовиться к экзамену и мне нужно оставаться сосредоточенным, а предмет экзамена мне не нравится или не нравится.
Такие техники, как Pomodoro , позволяют вам планировать свое время и делать паузы, чтобы «освежить» свой разум.
По крайней мере, в моем случае я обнаружил, что наличие цели позволяет мне оставаться сосредоточенным. Существует множество приложений , мобильных и веб-приложений, которые вы можете использовать для планирования времени, которое вы проводите, и ваши цели могут варьироваться в зависимости от каждого помидора, например, выполнить определенное количество тестов.
Когда я выполняю задачи, мне даже нравится делать то, что раньше было трудно делать.
Не могу сказать, что мне нравится ваш процесс, но иногда это то, что есть. Видимо, они не думают, что могут позволить себе настоящих тестировщиков, поэтому приходится довольствоваться тем, что есть.
Иногда изменение того, как вы думаете о чем-то, может помочь изменить вашу мотивацию. Прямо сейчас вы, возможно, видите в этом рутинную работу, от которой вы ничего не получаете, кроме скуки. Если вы измените свою точку зрения, вы можете изменить свою мотивацию.
Поскольку вы проверяете работу других, вы оказываете им и себе медвежью услугу, делая ее плохо. Это будет выглядеть плохо, когда у них будут ошибки, которые вы должны были поймать, чтобы запустить их в производство. Если плохого вида недостаточно для мотивации, может быть, подвести товарищей по команде.
Вы также можете рассматривать это как шанс действительно понять, как писать лучший код. Тестирование, честное тестирование, а не простое движение, учит вас тому, как пользователи на самом деле используют вещи и какие крайние случаи вам нужно уметь обрабатывать в своих будущих проектах. Это также дает вам некоторое представление о том, как работают вещи других людей, что полезно, когда вас призывают внести изменения после того, как Джо переходит на другой проект или работу.
И тестирование может быть забавным. Думайте об этом как о битве между вами, тестировщиком, и человеком, написавшим код. Выйдете ли вы победителем с чередой жуков или он, хитрый противник, выйдет с заветным титулом без жуков?
Вы даже можете геймифицировать, пытаясь увидеть, сколько ошибок вы можете найти в каждом тестовом спринте, и попытаться получить лучшие результаты.
Или вы можете последовать очень хорошему совету от @Gonzalo и использовать технику Pomodoro.
Я не вижу в этом проблемы, вызванной надзором. Это действительно зависит от человека, чтобы оставаться сосредоточенным. У супервайзера уже есть нормальная процедура для такого рода ситуаций, и он, скорее всего, справится с этим, дав плохой отзыв, а не пытаясь сделать его более «забавным». Это проблема с производительностью, которая может плохо на вас повлиять.
Хорошо, что вы понимаете, что есть проблема, плохо то, что вы ожидаете, что другие решат ее за вас. Нам всем приходится выполнять работу, которая в тот или иной момент нам не нравится, и одним из признаков профессионала является то, что он справляется со всеми, не теряя концентрации.
Вам нужно разработать стратегии, которые помогут вам справиться, как и всем остальным.
Как разработчик, вы очень привыкли смотреть на вещи с точки зрения вывода. Тестирование действительно не удовлетворяет этому. Это обыденная и скучная работа, но это не значит, что вы плохо работаете, когда чувствуете себя немотивированным.
К сожалению, реальность тестирования заключается в том, что оно очень повторяющееся. Радость в нем должна исходить от того, что вы что-то сломали или нашли изъян, что редко случается с хорошим кодом.
Пишите тест-кейсы. Звучит так, будто это добавляет дополнительную работу к и без того скучной задаче, но я считаю, что как разработчик я очень сосредоточен на достижениях. Если мне предстоит проработать серию тестовых случаев, я испытываю чувство выполненного долга каждый раз, когда в завершенную стопку попадает еще один. Кроме того, важно иметь запись о проведенном тестировании, и это настоятельно рекомендуется.
Получите удовольствие от охоты на жуков! Поиск уязвимости в вашем коде или коде другого разработчика — это необработанный опыт обучения. Я нахожу довольно приятным передавать интересную ошибку другому разработчику и вместе выискивать причину. Вы не должны находить их часто, но когда вы это делаете, это может стать отличным опытом обучения, который вы начинаете искать при тестировании.
Вы просто более продуктивны, занимаясь тем, что вам нравится.
Сделайте его умнее и включите больше того, что у вас получается лучше всего.
Вы не указываете тип программного обеспечения, которое вы разрабатываете, но большинство тестов можно и нужно автоматизировать (по многим причинам, например, это повторяющаяся задача, подверженная человеческим ошибкам, возможность запускать функциональные тесты как часть непрерывной интеграции и так далее).
Поскольку регрессионные тесты были автоматизированы, задача будет состоять в том, чтобы написать новые тесты для новых введенных функций. Это сочетает в себе тестирование и разработку. Если тесты поддерживаются должным образом и создаются с использованием многоразового/модульного подхода, их станет легче писать с введением новых функций. В долгосрочной перспективе вашей команде потребуется тратить меньше времени и усилий на тестирование, а общая производительность возрастет.
Измените свое отношение.
Попробуйте изменить свою точку зрения и поймите, почему тестирование — очень важная часть разработки. Можно попробовать развить в себе внутренний QA — определить, где и почему ПО может сломаться. Многие разработчики просто не предвидят всех возможных или вероятных сценариев. Они думают о прямом случае, когда пользователь поступает правильно. Пытаясь взломать программное обеспечение, вы научитесь определять распространенные ловушки. Затем при написании нового кода вы будете помнить об этом, и результат будет лучше.
Если возможно, протестируйте функции, разработанные вашими коллегами, и позвольте им протестировать ваш код. Мы все склонны быть более осторожными при тестировании того, что мы создали сами. У этого есть и другая положительная сторона — вы всегда будете в курсе, кто что написал и как это использовалось. Я был в командах, члены которых не знали, чем занимаются их коллеги в той же команде. С таким уровнем осведомленности было бы проще переключаться между задачами или брать задачу с того места, где ее оставил коллега. Кроме того, тестирование чего-то, что вы не написали за неделю до этого, сделает работу менее повторяющейся.
Независимо от того, можете ли вы внедрить автоматическое тестирование, убедитесь, что вы отслеживаете различные сценарии, которые вы выполняете. Вы должны сделать это еще до того, как начнете писать код — при написании тестов вы можете обнаружить проблемы с заданными требованиями. Во многих случаях владелец продукта не мог предвидеть данный сценарий, и вы сможете согласовать с ним требования, чтобы устранить проблему еще до того, как она появится.
Хорошая организация тестовых случаев обеспечит достаточный охват. Вы сможете отслеживать прогресс, распределять работу между членами вашей команды и легко проверять, что что-то было протестировано. Наконец, когда вам нужно определить, почему ошибка попала в рабочую среду, вы сможете увидеть, где была причина — допустили ли вы ошибку во время кодирования или, возможно, вы не тестировали этот сценарий.
Примечание. Это мой первый ответ. Если у вас есть отзывы о том, как его улучшить, пожалуйста, продолжайте!
край