Partager via

Why QA need to read source code...

  • Article

Many cases, QAs are working based on test plan which is generated based on

- Spec of feature

- User scenarios

- Feedback from Dev/PM

- Previous experiences

- Etc...

However we oftenly miss the apect of understanding the feature at the code level. well some people may not agree with me and say that it is not necessary to do white box testing all the time and we'd better be at the user level perspective because we have too complex system and don't have enough time to understand whole detail.

Yes, I agree that it is not easy to spare resource to understand whole detail with limited resource. and Yes, it is important to see the product in customer's perspective which is not based on how the code is implemented at code level.

But, in many cases, if we as QA engineer don't understand the internal structure and data flow with a certain degree of understanding code, we may be ended up with missing test coverage here and there. and the overall quality of product will be just mediocre.

Understanding product at code level will give us benefits like

- better test case generation

- efficient approach in test to the feature

- Can make faster and accurate decision on the impact and scope of changes

- Prove self-esteem and confidence

 

Well, However we need to have balance to be realistic. we only have limited resource(time and men). so it may not be necessary to understand every single line. drawing the line appropriately will be key to success....

Comments

  • Anonymous
    February 16, 2004
    I definitely have to agree with you. My employer takes the stance of QA not ever coming close to seeing the code. I don't think the problem we have is missing code coverage (which is a problem), but the exact opposite - testing the same code paths multiple times. It's quite frustrating, that's for sure.
  • Anonymous
    February 16, 2004

    Totally disagree. A QA should distance himself as much as he can only to make sure that he mimics a real user experience. If a QA acts like a developer, then they fall short of real world use cases.

    I think that the requirement for a QA not to dive and drown into technicalities is a matter of methodology, and is IMHO in the TOP 3 requirements for that job.

    Claiming the opposite strikes me a lot when you see how much products develop on the technical side never succeed in the real world (deployment, user look and feel, ...).
  • Anonymous
    February 16, 2004

    I didn't know you where in the VC# team, and this might make me change a bit my previous answer. You are certainly highly technical endsin your day job because the product you are testing is actually highly technical from both, and for that reason I think you are not really representative of QAs out there.

    A QA that would be responsible of the SDK alone in some software product could come up with thoughts like yours, but again I don't think there are too many doing that in the real world, in percentage.
  • Anonymous
    February 17, 2004
    I think looking at the code is probably where I would draw the distinction between a "Tester" and a "Software Quality Engineer". QA should include checking the quality on code level - whitebox testing, coding standards, automated unit tests etc...

    If I only had 1 QA person though, I would go with the traditional blackbox/non-code-level approach.
  • Anonymous
    February 17, 2004
    I don't think that is a good idea. In my experience, When I saw testers doing this I've to rescue them to refocus on testing rather than coding.
  • Anonymous
    February 17, 2004
    SDE/T should read code and run static analysers.

    STEs can run the SDE/Ts tools and theyre own "blackbox" testing.

  • Anonymous
    April 08, 2004
    Min is QA for the area I own as Dev (the Debugger), and him reading our source code has exposed some interesting issues indeed. Of course if I was insane I would tell my team to stop commenting our code :-)

    Min is very technical. Reading source probably doesn't make sense for not-so-technical QA, but if they are savvy enough, bring it on.
  • Anonymous
    April 14, 2004
    This is depends on situation. I defentely agree with you. If you see the code you will find better test conditions. But it is not suitable in all types of system implementation. Assume that you are testing application developed in SAP, ERP, Siebel etc, you cannot see the code. So testing based on requirements and design is the better idea.
  • Anonymous
    May 25, 2004
    Please help me with the QAS questions below :
  • Anonymous
    May 25, 2004
    Below where? :)
  • Anonymous
    June 22, 2004
    I think this is not relevant question. In my view actually we don't read the source code, instead we just check the functionality.
  • Anonymous
    June 22, 2004
    I think this is not relevant question. In my view actually we don't read the source code, instead we just check the functionality.
  • Anonymous
    November 18, 2004
    Why QA need to read source code...
  • Anonymous
    November 18, 2004
    Why QA need to read source code...
  • Anonymous
    June 16, 2009
    PingBack from http://workfromhomecareer.info/story.php?id=33730