Are you a tester by any means? From my experience, the hardest/most time-consuming part of testing is reading the text and remembering which branch you're on (and some characters have A LOT of them), making sure the dialogue is accurate to what has happened in that particular playthrough. While it takes around a week to test the code itself, making sure there's nothing that would lead to an error or wrong sprite display, which I can even fix on my own, the branch-tracking takes A LOT more time to do by yourself. You got to have notes of everything that happened per branch and cross-reference anything you read with that data. The problem is, there is no such data to cross-reference with and you only have to rely on your memory (and the guide). Like, I was able to spot some branch-related issues in Chapters 2 - 5 only recently, because while testing it never occured to me to try and commit to unpopular choices such as getting black-eyed by Robert and seeing that the image of Ian sitting in front of computer doesn't have a black eye overlay.
I think it matters a lot on how the scripts are structured and how you approach the testing. In an ideal world, this is how I see things. You have a master script that connects each chapter script and each chapter script is a master script of its own, connecting each scene of said chapter. Right now, it's a bit of a mix. The project started out with one file per chapter, then it evolved to 2 parts and after that we got 4 parts. Chapter 9 is event more tangled and hard to understand. There are different parts but we can also find individual scenes written in their own files. I was a bit surprised that this was not addressed in the remastered version. Anyway, moving on.
After the code is done and everything is linked together I can start testing. I'll do that by checking out the functionality. What do I want? I want to make sure that there are no typos in the variable names and that there are no issues with the images displayed in the VN. I will jump to the first scene label and look over the script. For example: lets say that I have to test the Cindy scene from the last chapter. I start by setting up the variables that triggered the scene. After that I can look at the script. I find out that when Ian_Cindy_V7_Kiss = true, I am supposed to see this text. Does that happens? Yes. Did I encountered any issue with the images? No. Was there any dialog line missing? No. I'll reload everything and try another path, and another, until I'm done with that scene. At the end I will know for sure that there isn't any path that wasn't covered.
After I've tested everything in isolation, now it's time to verify the chapter master script. Are the scene triggers ok? Yes. Perfect!
What is next? I need to do an end to end test. I load an existing playthrough and I'll try to get to the end of the chapter as fast as I can - at this point I don't care about the content in any way; I probably know all the choices by heart. Skip! Skip! Skip! When I am done, I move to another playthrough. This final process will reveal if there are any balancing issues. Maybe in order to get the scene X you should need only 5 lust, not 6. When everything is done, as far as I am concerned, at that point in time the VNs functionality was tested and I fixed any potential balancing issues. By now the game should be bug free.
One final thought about keeping each scene in a separate file. I strongly believe that this approach will offer the following benefits:
- you don't remember what Cindy said in chapter 7; if you don't remember something, it will be much faster to find the text that you are interested in.
- you could use a scene again, in a later chapter. Maybe I want to play a shy Ian, that gets to have his first date with Lena in chapter 10. The art can be reused. Of course, you need to write and hide some dialog, but in the end, that won't take too long to do it. The player gets one more option and the developer gets an easy win for not that much effort.
Maybe this sounds like there is a lot of work needed to pull it off, but I still think it's do-able. Now, I know that you are actively involved in the project development testing, proofreading, etc. You have more knowledge about what happens behind the scenes. Probably an approach like the one described above is not good. Or even if it is, it might take a hell of a lot more than a week to do it.