Welcome to SQA. I assumed you're a tester :-)
In short, do devs like being bothered by testers?
Well, that depends on many things.
- If you find a bug and won't bother a developer to fix it or answer area around it, she might bother you to explain it better later, when you're busy. So it is in interest of both of you to find the right time.
- Finding the right time might be easier if you're both working on the same functionality in the same time (e.g. during same iteration). She or he is implementing a given functionality, and you're preparing or executing tests for this functionality. You both are focused on similar things and care about both. On the contrary, if she is developing new things, and you're testing old stuff, it might be harder to find the right time. This is why it is so important to arrange testing and bug fixing cycles roughly in the same time.
- Sure, it depends also on personal preferences. Some people can switch context more quickly than others. Remember this refers also to you, so your preferences of cooperation should be respected by devs as well.
If the answer is yes, where is the line I shouldn't cross?
I read this question as who is responsible for investigating a defect? You want the developers to do it; they want you to do it. Answering that, you need to consider two things:
- Technical: You may know this area of the system better than a developer, you know the test context, etc. so you will be able to perform initial investigation faster. The section "Where to draw the line?" of How to Make your Bugs Lonely: Tips on Bug Isolation discusses this aspect in detail. Read it.
- Responsibility Razor: If you want a thing to happen, you're responsible to make it happen. You can do it yourself or persuade a developer with a good bug report to do it himself. Read Dale Emery's post on that.
You will find more info in related question "How does a tester decide how much debugging/investigation to do before handing an issue over to development?". In general, I want to respect devs' time. If I am able to reproduce the issue better now, I do it. If I can write the automated test to reproduce the issue, I do it. If I am able to narrow down the root cause myself faster then they would do, I do it.
As soon as I find a bug, tell you about it or make a summary of bugs found and tell you about it at the end of the day?
Well, it depends. It depends on:
- Is your organization tracking all bugs in some BTS (bug tracking system) like JIRA? For instance, in my team we usually report bugs during regression testing, when functionality is already done. On the other hand, in iteration we often test functionality that is not complete to provide quick feedback. Since we want feedback to be quick, we don't waste time to write reports but talk immediately to a developer.
- Writing is thinking: it may help you understand the defect better if you describe it in written form. You will see better what is missing, do you have all the steps to reproduce it, how sure are you about an expected result.
- Personal preferences of both of you.
Ask you tons of questions about the app you're developing or try to figure it out myself? Or maybe I shouldn't have to worry about the specific details of the app?
Both.
I found many programmers (sure, not all) like to talk about their work even when not asked for. Listen to them actively. Also, try to understand the application yourself: play with it, read the documentation, dig into the code if you can. This way you will learn their language and you become partners in solving the problem. For more information, I recommend you reading a lesson "Programmers like to talk about their work. Ask them questions" (and lessons around it) in Lessons Learned in Software Testing.