Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my previous company we had a practice of doing smoke testing for 10 minutes before code commit by the developer. A QA need to sit with the associate developer and need to perform a quick smoke test(for details, you may see my blog post We are used to follow KAN BAN(customized).

  • What should be QA mind set while testing this?
  • What are the things need to take care about?
  • How they will interact on bug found or not found?
  • How can the QA person keep tracking the side issues that arise while working on the assigned task?
  • How to make a report to QA team on the test action that he just performed?

We had a practice, but I just want to know if there is more interesting ideas.

share|improve this question

closed as too broad by Dan Snell, corsiKa Jun 27 '13 at 15:39

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Given the low tester/dev ration and large number of commits per day I would say that either informal interaction with dev is preferred (as in pair programming or informal code reviews) or if you want to track the problems, then reviews should be less torough or not for every commit. – dzieciou Jun 2 '13 at 21:23
Why QA needs to track those issues? To me this looks reviewing and extending unit tests, the same way as in pair programming, only the peer doing a review is QA. And when a peer finds and issue it just tells dev to correct it or correct it herself. – dzieciou Jun 2 '13 at 21:24
Just to understand the practice better. Have your devs practiced pair programming? Did you have code reviews in any form (Peer reviews or more formal)? What was the benefit of QA pre-testing over those practices? What things QA found that devs overlooked? – dzieciou Jun 2 '13 at 21:26
And one more. How large where those commits? Did QA performed black box testing in the practice you describe, or he was rather supposed to know the code well and do unit testing? – dzieciou Jun 2 '13 at 21:28
Shantonu, I see questions in this post, but I am having trouble determining what your business problem you want solved is. Could you clarify what your end-objective is? – corsiKa Jun 5 '13 at 15:39