Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

If you're a dev and I'm the tester, do you expect me to...

  • 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?
  • 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?
  • etc

In short, do devs like being bothered by testers? If the answer is yes, where is the line I shouldn't cross?

share|improve this question
1  
I would ask also what testers expect from devs, but that's a different question :-) –  dzieciou Sep 22 '13 at 8:56
1  
It might help to ask them. They will probably have an opinion. –  user246 Sep 22 '13 at 12:39
add comment

5 Answers 5

up vote 6 down vote accepted

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.

share|improve this answer
    
Thanks for such a detailed answer :) –  l19 Sep 22 '13 at 23:35
add comment

This depends entirely on preferences of the programmers. Some don't want to be interrupted, others don't mind it at all. Some want to discuss problems before they are reported to make sure they are problems and to provide more information in the bug report, others are happy just to receive as clear report as possible. One team can of course have all types.

The only way to deal with this is to ask them what they prefer.

One method you can suggest is to go to the programmer as soon as you are relatively sure you have found something but not interrupt her until she stops and indicates that now is good time to stop for talking. If she's in flow, she's not required to stop and you can go away and come back later if you get tired of waiting. This way no-one needs to be irritated of interruptions but you can discuss things as soon as possible. It's anyway good idea to explisitly agree on this method or any other you end up using.

share|improve this answer
add comment

I am also a tester so as per my experience I can tell you some points which can help you. Answer to the 1st question -

Qn - Does the tester need to report a bug as soon as he finds it?

Ans - YES.If you have a proper BTS(Bug Tracking System),it is the 1st duty of a tester to report the bug provided he is sure that it is a bug. In case you are not sure whether the issue you see in the application is a genuine one then please take some pain and discuss with the developer about the same.But after discussion without wasting any time a tester should report the issue. Again the time of reporting the issue depends on the severity of the bug and also the priority e.g blocking issues should be reported immediately whereas cosmetic issues could wait for sometime. But a tester should make sure that all the bugs are reported/go into the BTS by EOD. The above process holds good in case you have a proper process in place for bug handling. In case you do not have a process/BTS, take a note of the issues alongwith the steps to reproduce and screenshots,if any. You can maintain the same using any text editor like MSWord,Wordpad etc. Send the sheet to the developer depending again on the severity and priority of the issues found. Do not forget to mark the Test Manager/Dev Manager in Cc while sending.

Now answer to the 2nd question.

Qn - Do the testers need to have complete knowledge of the application before testing?

Ans - A definite YES.Because it is the tester who assures quality. SO without having complete knowledge of the application this thing is impossible.The tester should have complete understanding of the application/part of application he is testing.In that case only (s)he could think of better scenarios to test the application. Also a tester should also think from the perspective of an end user while testing any application.A tester should go to the developer to clarify the queries in case things are not clear in the functionality document.But at the same time the tester should be patient enough to allow the developer to spare some time for you.Of course you have the rights to overload him with questions in case the functionality is a critical one and you are blocked with testing due to lack of knowledge on the same. But YES,you need to have complete idea about the application under test (AUT).

Thanks

Khushboo

share|improve this answer
    
Welcome to SQA! The OP never asked "Do the testers need to have complete knowledge of the application before testing?". The OP asked whether it is necessary to know specific details of the AUT. Knowing specific details helps, but you don't need to have a complete knowledge about the AUT to start testing. Working with large enterprise applications I can tell you there many areas I don't know or don't understand. I'm learning on a way, during testing. Despite my limited knowledge, I was able to provide useful feedback about the product to the team. –  dzieciou Sep 26 '13 at 5:36
    
+1: Considering severity when deciding how urgent is reporting a bug is a good point! –  dzieciou Sep 26 '13 at 5:42
add comment

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?

I'll say yes. Why? Let's say I found something at noon and fill it out by the end of the day along with the others. A) Issue is not going to be as fresh as before in my head to investigate, and B) if dev has to fix it because its something important (client has a demo, it blocks other features, etc) or its just a very easy fix he knows he has time to work on now, but he may not have as much time tomorrow or he is coding with a dependency of the issue its always better for him to know in advance. .

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. First you try to figure it out yourself (read documentation, navigate flows, I find it useful to read lates tickets as well) and, once you have all your tons questions noted, you ask them. You have to know the details to have better test results(not also app details, but also business knowledge).

share|improve this answer
add comment

I agree to dzieciou.

In addition , QA should be referring to implicit/explicit requirements while raising bugs. He should mention it clearly in bug description by way of expected/actual results. Screenshots/test data are also necessary fields. During our projects , we have used bug tracking systems that send automatic notifications to developers/interested people on particular events. In addition, continuous communication with developers is necessary to I) establish rapport ii) have quick turnaround on defects ii) share knowledge about functionality and technology supporting it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.