Da dies meine erste Antwort ist, möchte ich meinen Kommentar ein wenig erweitern.

Was ich seit ein paar Wochen versucht habe, ist, mir selbst Ziele zu setzen und Techniken für das Zeitmanagement zu verwenden. Wenn man das zeitlich einplanen kann, funktioniert es ganz gut. Das nutze ich zum Beispiel, wenn ich mich auf eine Klausur vorbereiten muss und konzentriert bleiben muss, und das Prüfungsthema etwas ist, das ich nicht mag oder das mir keinen Spaß macht.

Techniken wie Pomodoro ermöglichen es Ihnen, Ihre Zeit zu planen und Pausen einzulegen, um Ihren Geist "aufzufrischen".

Zumindest in meinem Fall habe ich festgestellt, dass es mir erlaubt, konzentriert zu bleiben, wenn ich ein Ziel habe. Es gibt viele mobile und Web-Apps, die Sie verwenden können, um die Zeit zu planen, die Sie behalten, und Ihre Ziele können zwischen den einzelnen Pomodoros variieren, dh eine bestimmte Anzahl von Tests absolvieren.

Wenn ich die Ziele erfülle, macht es mir sogar Spaß, etwas zu tun, was vorher schwierig war.

Ich kann nicht sagen, dass ich Ihren Prozess mag, aber manchmal ist es so, wie es ist. Anscheinend glauben sie nicht, dass sie sich echte Tester leisten können, also müssen Sie mit dem gehen, was ist.

Manchmal kann es helfen, deine Einstellung zu ändern, wenn du über etwas denkst. Im Moment sehen Sie dies möglicherweise als eine lästige Pflicht, bei der Sie außer Langeweile nichts gewinnen. Wenn Sie Ihre Perspektive ändern, können Sie Ihre Motivation ändern.

Da Sie die Arbeit anderer testen, tun Sie ihnen und sich selbst einen Bärendienst, indem Sie es schlecht machen. Es wird schlecht aussehen, wenn sie Fehler haben, die Sie hätten finden sollen, um es in die Produktion zu bringen. Wenn es dir nicht reicht, schlecht auszusehen, ist es vielleicht ein Motivator, deine Teamkollegen zu enttäuschen.

Sie können es auch als Chance betrachten, wirklich herauszufinden, wie man besseren Code schreibt. Testen, ehrliches Testen, nicht nur das Herumspielen, lehrt Sie, wie Benutzer Dinge tatsächlich verwenden und welche Randfälle Sie in Ihren eigenen zukünftigen Projekten handhaben müssen. Es gibt Ihnen auch einen Einblick, wie die Dinge anderer Leute funktionieren, was hilfreich ist, wenn Sie aufgefordert werden, Änderungen vorzunehmen, nachdem Joe zu einem anderen Projekt oder Job gewechselt ist.

Und Testen kann Spaß machen. Betrachten Sie es als einen Kampf zwischen Ihnen, dem Tester, und der Person, die den Code geschrieben hat. Wirst du mit einer Reihe von Bugs als Sieger hervorgehen oder wird er, der gerissene Gegner, der er ist, mit dem begehrten Titel "Bug Free" hervorgehen?

Sie können sogar spielen, indem Sie versuchen, zu sehen, wie viele Fehler Sie in jedem Test-Sprint finden können, und versuchen, bessere Ergebnisse zu erzielen.

Oder man folgt dem sehr guten Rat von @Gonzalo und wendet die Pomodoro-Technik an.

Ich sehe das nicht als ein vom Vorgesetzten verursachtes Problem. Es liegt wirklich an einem Einzelnen, konzentriert zu bleiben. Ein Vorgesetzter hat bereits ein normales Verfahren für diese Art von Situation und würde wahrscheinlich damit umgehen, indem er eine schlechte Bewertung abgibt, anstatt zu versuchen, es „lustiger“ zu machen. Es ist ein Leistungsproblem, das sich negativ auf Sie auswirken könnte.

Das Gute ist, dass Sie erkennen, dass es ein Problem gibt, das Schlechte ist, dass Sie erwarten, dass andere es für Sie lösen. Wir alle müssen irgendwann Jobs machen, die uns keinen Spaß machen, eines der Kennzeichen eines Profis ist, dass er/sie sie alle erledigt, ohne den Fokus zu verlieren.

Sie müssen Strategien entwickeln, die Ihnen helfen, damit umzugehen, genau wie alle anderen auch.

Beim Testen geht es nicht um Produktivität, sondern um Wiederholung

Als Entwickler sind Sie sehr konditioniert, Dinge aus der Output-Perspektive zu betrachten. Das Testen erfüllt dies nicht wirklich. Es ist eine alltägliche und langweilige Arbeit – aber das bedeutet nicht, dass Sie keine gute Arbeit leisten, wenn Sie sich unmotiviert fühlen.

Die unglückliche Realität des Testens ist, dass es sehr repetitiv ist. Die Freude daran muss darin bestehen, etwas kaputt zu machen oder einen Fehler zu finden – was bei gutem Code selten vorkommt.

Fokussieren beim Testen?

Testfälle schreiben. Das hört sich so an, als würde es einer ohnehin schon langweiligen Aufgabe zusätzliche Arbeit hinzufügen, aber ich finde, dass ich als Entwickler sehr leistungsorientiert bin. Wenn ich eine Reihe von Testfällen durcharbeiten muss, verspüre ich jedes Mal dieses Gefühl der Erfüllung, wenn ein weiterer auf dem fertigen Stapel landet. Darüber hinaus ist es wichtig, eine Aufzeichnung der durchgeführten Tests zu haben, und dies wird dringend empfohlen.

Finden Sie die Freude an der Fehlersuche! Das Finden eines Fehlers in Ihrem oder dem Code eines anderen Entwicklers ist eine rohe Lernerfahrung. Ich finde es ziemlich angenehm, einen interessanten Fehler zu einem anderen Entwickler zu bringen und gemeinsam der Ursache auf den Grund zu gehen. Sie sollten sie nicht oft finden, aber wenn Sie es tun, kann es eine großartige Lernerfahrung sein, nach der Sie beim Testen suchen.

Sie sind einfach produktiver, wenn Sie Dinge tun, die Ihnen Spaß machen.

Wenn Sie die Möglichkeit haben, den Prozess zu ändern

Machen Sie es intelligenter und integrieren Sie mehr von dem, was Sie am besten können.

Sie geben die Art der Software, die Sie entwickeln, nicht an, aber die meisten Tests können und sollten automatisiert werden (aus mehreren Gründen, z. B. weil es sich um eine sich wiederholende Aufgabe handelt, die anfällig für menschliche Fehler ist, die Möglichkeit, Funktionstests als Teil der kontinuierlichen Integration durchzuführen usw).

Nachdem die Regressionstests automatisiert wurden, besteht die Aufgabe darin, neue Tests für neu eingeführte Funktionen zu schreiben. Dies verbindet Testen und Entwickeln miteinander. Wenn Tests ordnungsgemäß gewartet und in einem wiederverwendbaren/modularen Ansatz erstellt werden, werden sie einfacher zu schreiben sein, da neue Funktionen eingeführt werden. Langfristig muss Ihr Team weniger Zeit und Mühe in das Testen investieren und die Produktivität wird insgesamt steigen.

Wenn das Ändern des Prozesses keine Option ist

Ändere dein Verhalten.

Versuchen Sie, Ihre Perspektive zu ändern, und verstehen Sie, warum das Testen ein sehr wichtiger Teil der Entwicklung ist. Sie können versuchen, die innere Qualitätssicherung in sich selbst zu entwickeln – identifizieren Sie, wo und warum Software kaputt gehen kann. Viele Entwickler antizipieren einfach nicht alle möglichen oder wahrscheinlichen Szenarien. Sie denken an den direkten Fall, wo der Benutzer das Richtige tut. Beim Versuch, Software zu beschädigen, lernen Sie, wie Sie häufige Fallstricke erkennen. Wenn Sie dann neuen Code schreiben, haben Sie diese Dinge im Hinterkopf und Ihre Ausgabe wird besser sein.

Testen Sie nach Möglichkeit Features, die von Ihren Kollegen entwickelt wurden, und lassen Sie sie Ihren Code testen. Wir alle neigen dazu, vorsichtiger zu sein, wenn wir etwas testen, das wir selbst erstellt haben. Das hat noch eine weitere positive Seite – Sie sind immer auf dem Laufenden, wer was geschrieben hat und wie es verwendet wird. Ich war in Teams, in denen Teammitglieder nicht wussten, was ihre Kollegen im selben Team taten. Mit dieser Sensibilisierung wäre es einfacher, Aufgaben zu wechseln oder eine Aufgabe dort fortzusetzen, wo ein Kollege sie verlassen hat. Wenn Sie etwas testen, das Sie nicht erst in der Woche zuvor geschrieben haben, fühlt sich die Arbeit weniger repetitiv an.

Unabhängig davon, ob Sie automatisierte Tests implementieren können oder nicht, stellen Sie sicher, dass Sie die verschiedenen Szenarien, die Sie ausführen, im Auge behalten. Sie sollten dies tun, bevor Sie überhaupt mit dem Schreiben von Code beginnen - beim Schreiben der Tests können Sie Probleme mit den angegebenen Anforderungen entdecken. In vielen Fällen hätte der Product Owner ein bestimmtes Szenario nicht vorhergesehen, und Sie können die Anforderungen mit ihm klären, sodass Sie das Problem beseitigen können, bevor es überhaupt auftritt.

Eine gute Organisation der Testfälle sorgt für eine ausreichende Abdeckung. Sie können den Fortschritt verfolgen, die Arbeit auf die Mitglieder Ihres Teams verteilen und leicht überprüfen, ob etwas getestet wurde. Wenn Sie schließlich herausfinden müssen, warum ein Fehler in die Produktion gelangt ist, können Sie sehen, wo der Grund lag – ob Sie beim Codieren einen Fehler gemacht haben oder ob Sie dieses Szenario vielleicht nicht getestet haben.

Hinweis: Dies ist meine erste Antwort überhaupt. Wenn Sie Feedback zur Verbesserung haben, machen Sie bitte weiter!