As a tester, I love exploring partially developed code, and giving early feedback to the developer.
The key thing, as others have mentioned, is strong communication between developer and tester. I need to know what areas are likely to still be incomplete, so I don't waste time trying to isolate an issue. The developer needs to be prepared to outline what's finished, and perhaps discuss some tips on ways to workaround unfinished areas (for instance, if creating an order via the UI isn't finished yet, I might want to insert data directly into the database so that I can still look at other areas).
The biggest benefit of this is that my understanding of what we're building grows alongside the developer's, and I can feed in my questions about potential edge cases as they're building, thus saving them valuable time and deepening both of our understandings.
Some other answers seem to assume a test case based approach, where you run the same test cases time and time again. Frankly, if I was running exactly the same tests once the feature is done, I'd consider that I hadn't learned anything from my previous work, and would be worried. That early testing stage is where I develop my mental model, and think about test design.
That may seem a little long - but I wanted to describe how it can be done well. Your situation is clearly not being handled well:
- communication via bug tracker
- KPI driven testers attempting to raise the max number of bugs
- many duplicates, lack of communication between testers
- attempts from you to clarify scope totally ignored
to name just a few points. I'd recommend discussing with line management to understand the purpose of requesting that QA get involved earlier, and explaining the additional overhead of running everything through the bug tracker. If possible, if there is a particular tester who you respect, you could suggest that it would be more practical to assign one tester at this early stage, and that would let you work together to develop a process that works better.