One for those of you who work in QA..


  • Discourse touched me in a no-no place

    Should the QA (Quality Assurance) department, as a matter of course have routine access to the source code?

    Presume development are documenting their unit testing and making that available (and thus reproducible if necessary.)


    System concerned is an embedded system, with the OS compiled from scratch with our own applications, largely written in C, put on top of it.

    There is no suggestion about preventing QA from looking at the code, the argument I'm looking for an answer to is should they be looking at it to do their job.


    I'll update this post should further questions elicit more pertinent information.


  • I survived the hour long Uno hand

    I don't see why not. Most types of testing wouldn't use it, but it can be helpful when doing automation and whatnot. And many teams that use BDD put their acceptance tests in the same repo as their source code.



  • @PJH I would say yes they should. One of my previous places had developers only on code reviews, and they always picked out the easy stuff. Bits like inconsistent indentation and poor variable names were the main features of the code reviews.

    Then the software went to QA and fell over. Repeatedly and for stupid shit. Once QA joined in the code reviews, and were routinely looking over code they were picking up things like not checking array bounds, not zeroing sensitive memory and other relatively simple stuff at every review.

    Having QA involved with the code reviews meant that much more was caught early, and less bugs ended up in test.

    /Preaching


  • FoxDev

    @Nocha said in One for those of you who work in QA..:

    One of my previous places had developers only on code reviews

    As both a coder and an amateur writer, I can say for sure the worst person to proof-read something is the person who wrote it. On that basis alone, I'd agree QA should have source access.


  • I survived the hour long Uno hand

    @PJH said in One for those of you who work in QA..:

    should they be looking at it to do their job.

    Depends on what job duties you have them doing. And what type of QA professionals you have.



  • When I was doing QA it was very helpful to be able to read the source code. For example, when I would see strange behavior in edge cases or when coverage testing didn't come up 100%, being able to see what they wrote and compare it to the requirements let me determine if there's a lowest-level requirement missing, a software bug that needed to be fixed, or if I wasn't sure and had to kick it back for someone more knowledgeable to determine.

    Your QA team members have to know when to use that power, of course, but unless there's a pressing need for separation I'd let folks have read access.


  • Discourse touched me in a no-no place

    @PJH said in One for those of you who work in QA..:

    Should the QA (Quality Assurance) department, as a matter of course have routine access to the source code?

    I'd say yes. Some types of testing need access, since those are the types of testing that focus on ensuring that weird edge cases are handled correctly, and being able to see the source makes finding candidate edge cases much easier. (There are other types of testing too, but having black-box and fuzz testing doesn't guarantee that tricky bits will be caught. Targeted white-box testing is a useful tool in the armoury.)



  • Source access is also useful if QA are supposed to guess which dev team should receive the bug report.



  • @PJH They might not need it, depending on what type of QA they're doing (in my company, we have both testers-programmers and completely non-technical testers that do manual clickthroughs), but I see very few drawbacks to that.

    I guess if you really want to be pedantic about black-box testing, maybe? But it still helps the more technical testers to figure out whether they fucked up the test, or the developer fucked up the feature.



  • @Parody said in One for those of you who work in QA..:

    When I was doing QA it was very helpful to be able to read the source code

    I'm pretty sure our QA would have no idea what they were reading if they saw our source code. It's hard enough finding qualified programmers that can. (Yes, we're looking.)



  • @dcon said in One for those of you who work in QA..:

    @Parody said in One for those of you who work in QA..:

    When I was doing QA it was very helpful to be able to read the source code

    I'm pretty sure our QA would have no idea what they were reading if they saw our source code. It's hard enough finding qualified programmers that can. (Yes, we're looking.)

    That sounds like when I was doing testing for a desktop publishing application. There we didn't have access to the source code; testing builds were made about once a week and bugs were filed against a specific build number. Most of the folks we had as testers were not coders, though everyone learned a little bit of AppleScript. (It helped that the application was recordable. One of Microsoft's big failures with the Scripting Host and VBA.)

    Being an interested hobbyist, I wrote a ton of scripts and spent time answering questions on the mailing list. Eventually I was able to move up to development when they went cross-platform.

    Projects like the one I mentioned earlier in this thread were for an aerospace company. There all of the testing we did involved writing test scripts and running them against a simulated or actual device; the setup allowed you to rerun multiple tests, all tests for a specific module, and so forth. Many of the folks doing testing had written code for that device or similar ones in the past; you couldn't test code you wrote, but you could work in other parts of the overall system. There were a few non-coders attached to the QA team, but in that phase they were mostly concerned with the (virtual) paper trail. (They may have been further involved after I'd moved to other projects.)

    So it definitely depends on what role you expect (the various parts of) your QA team to play.


  • Discourse touched me in a no-no place

    @Parody said in One for those of you who work in QA..:

    There were a few non-coders attached to the QA team, but in that phase they were mostly concerned with the (virtual) paper trail.

    Documentation needs QA too.



  • @Maciejasjmj said in One for those of you who work in QA..:

    @PJH They might not need it, depending on what type of QA they're doing (in my company, we have both testers-programmers and completely non-technical testers that do manual clickthroughs), but I see very few drawbacks to that.

    My company has three QA teams:

    1. The Validation team tests new features and bugfixes that the Product Development team creates. They have access to the source code.
    2. The QC team tests the client-specific customizations that my team (Operations) creates. They probably could access the source code, but most of them wouldn't know how to read it.
    3. The QA team ensures our paperwork complies with our company's policies and governmental regulations. They don't review our code; I'm not sure whether they can access the code, but I don't think most of them would be able to read it if they could.

    I don't know what sorts of code reviews the Prod Dev and Validation teams go through, but my team has one Ops programmer assigned as the "primary" programmer for each client's instance, and a "secondary" programmer from Ops reviews the primary's work. We have a weekly meeting with the Prod Dev team to review our implementation methods to see if there's a feature request that should be entered, if there's a better solution than the one we used, or if the requirement was unique and so appropriate for the code customization.



  • I read that there are three kinds of testers.

    1. White box testers - They are the one who write Unit Tests for developers. Obviously they should have source code access.
    2. Black box testers - They tests behaviour of application like normal users. Since this position does not require knowledge of programming, it's okay for them to not have access to source code.
    3. Grey box testers - They write automated test scripts for developers. Usually have UI level of source code access is enough (for them to pinpoint UI element to be automated), no need for access of business logics modules.

  • Discourse touched me in a no-no place

    @dcon said in One for those of you who work in QA..:

    I'm pretty sure our QA would have no idea what they were reading if they saw our source code

    I think this is the main concern with the QA member who was arguing against it...


  • Discourse touched me in a no-no place

    @PJH said in One for those of you who work in QA..:

    I think this is the main concern with the QA member who was arguing against it...

    As noted by many people above, some types of testing need access and some don't. The QA member above might be best staying on the side that doesn't, but should stop pissing in the shoes of those who do need it. And even if they have access, it doesn't mean that they have to use it; they can pretend that they're ignorant…


  • I survived the hour long Uno hand

    @cheong said in One for those of you who work in QA..:

    They are the one who write Unit Tests for developers.

    Fucking lazy-ass devs



  • @Yamikuronue Depending on where you work, you may as well call those developers with people writing documentation for them "Fucking lazy-ass devs" too. :P


  • 🚽 Regular

    @Yamikuronue said in One for those of you who work in QA..:

    @PJH said in One for those of you who work in QA..:

    should they be looking at it to do their job.

    Depends on what job duties you have them doing. And what type of QA professionals you have.

    Agreed.

    I've been employed in places where QA is an entry-level position for future programmers, where a lot of what they're doing is part of the learning experience. In such cases, having access to the source code (and even dabbling with it to fix small bugs) is encouraged.

    Other places, QA is its own full-service department with seasoned QA professionals who have done this their whole lives. Often times they don't have programming experience, or at best rudimentary experience, and thus they are best not distracted with looking at source code. If they do have any programming experience, it's often often in the form of configuring their own automated black-box testing processes.

    That said, I don't think there has to be some kind of draconian policy that locks up the source code in a vault or anything. Personally, I prefer employers that have the latter type of QA, since often times the former is organized too ad-hoc and you're left with a bunch of inexperienced interns and entry-levels checking for bugs. If you're going to hire entry-level programmers, it's best to leave them in a support-level position where they actually do programming full-time.



  • @The_Quiet_One said in One for those of you who work in QA..:

    That said, I don't think there has to be some kind of draconian policy that locks up the source code in a vault or anything.

    Just want to inform you that, some employers lock their precious source code like money in the bank that only people have absolute need for access can touch it. And they also tend to treat any developers resigning the company like would-be criminals who will steal the source code of the company's product for sell to their competitors.

    It happened to be one of my employer before. While he trust staffs employed in Hong Kong so we did enjoy much relaxed control to the source, those who were hired in mainland China are only allowed to remote desktop to a terminal server in application mode to do programming, plus with copy and paste functionality completely removed. The server is locked in a safe-like server rack that only the power button is accessible. There was a firewall in between to ensure only RDP traffic can pass-through. You can still access sites like CSDN on the workstations booted with Linux LiveCD and without harddisk installed, but for any code you found and tried to copy and paste into the project, thanks to how rdesktop works, copy and paste into the project is still possible, and it'll be pasted as if you've typed it yourself.

    I personally think this is a lame idea because whatever we code we can write it again without having to reference the original source itself (often the rewrite has better quality too), but meh...


  • I survived the hour long Uno hand

    @cheong said in One for those of you who work in QA..:

    documentation

    Depends on the target audience. Don't let devs write end-user documentation, for the love of all that's holy. Do make devs write documentation for future devs.


  • 🚽 Regular

    @cheong said in One for those of you who work in QA..:

    @The_Quiet_One said in One for those of you who work in QA..:

    That said, I don't think there has to be some kind of draconian policy that locks up the source code in a vault or anything.

    Just want to inform you that, some employers lock their precious source code like money in the bank that only people have absolute need for access can touch it. And they also tend to treat any developers resigning the company like would-be criminals who will steal the source code of the company's product for sell to their competitors.

    Well, yeah. You don't have to inform me of that. The fact that they exist are why I said what you quoted.


  • kills Dumbledore

    @Yamikuronue said in One for those of you who work in QA..:

    Don't let devs write end-user documentation, for the love of all that's holy.

    QFT. I consider myself fairly good at this, for a developer, but I still wouldn't want to have to write anything an actual user of my software would need to rely on


  • Java Dev

    @Yamikuronue said in One for those of you who work in QA..:

    @cheong said in One for those of you who work in QA..:

    documentation

    Depends on the target audience. Don't let devs write end-user documentation, for the love of all that's holy. Do make devs write documentation for future devs.

    Just now I documented a database table. It mostly says things like:

    • FOOBLE: Integer. Number of foobles.


  • @PleegWat said in One for those of you who work in QA..:

    @Yamikuronue said in One for those of you who work in QA..:

    @cheong said in One for those of you who work in QA..:

    documentation

    Depends on the target audience. Don't let devs write end-user documentation, for the love of all that's holy. Do make devs write documentation for future devs.

    Just now I documented a database table. It mostly says things like:

    • FOOBLE: Integer. Number of foobles.

    At least it's not returns an integer for a function named something like PositionOfFoobleOnScreen



  • @Yamikuronue said in One for those of you who work in QA..:

    Depends on the target audience. Don't let devs write end-user documentation, for the love of all that's holy. Do make devs write documentation for future devs.

    I have absolutely no idea for whom most of the documentation I write is intended. I'm simply required to emulate existing formats and levels of detail (easier said than done with the level of consistency that our documentation set doesn't have). Some of it's high level but highly technical, some mostly non-technical, and some of it's low level to the extent that there's almost no circumstance where you'd not be better off reading the source code.

    I'm pretty sure none of the stuff I'm actually expected to do is intended for my teammates or a hypothetical successor, though. (We do have a Confluence space intended as a knowledge base but it sees tragically little input.)


  • I survived the hour long Uno hand

    @CarrieVS said in One for those of you who work in QA..:

    I have absolutely no idea for whom most of the documentation I write is intended

    0_1480439819082_upload-81b90527-9326-420a-bf9e-ae718c85098e



  • @CarrieVS said in One for those of you who work in QA..:

    I'm simply required to emulate existing formats and levels of detail

    I remember once I did write documentation for reports of a replacement system too, and I have to write down the parts where the calculation is wrong on the old system and the users insist our output must match the old reports, thus the "special overriding rules".

    That's what we called "emulate existing formats and levels of detail" and for sure these has to be documented. 🤷


  • kills Dumbledore

    @CarrieVS said in One for those of you who work in QA..:

    We do have a Confluence space intended as a knowledge base but it sees tragically little input

    That is the fate of all confluence knowledge bases ever


  • Discourse touched me in a no-no place

    @Jaloopa said in One for those of you who work in QA..:

    That is the fate of all confluence knowledge bases ever

    It's not the software's fault, as that rot happens with all knowledge bases I've ever seen.



  • @dkf In one of my previous companies, we did have knowledgebase built into our CRM solution, and it got a total of 5 entries... all of them was written by me. And it turns out even I wrote those things there, my colleagues still ask those question to me.

    I didn't bother to add entries there again.


  • Impossible Mission - B

    QA and development are two very different skillsets. All of the best QA people I've worked with were people who wouldn't know what to do with source code if they did have access to it. (There was one who had a pretty solid grasp of SQL, which was useful for many tasks involved in testing our database-heavy program, but she knew next to nothing about actual coding, and that didn't really matter because she's not a developer.)

    And then there's the guy who used to be a developer. I know this because he'll tell anyone who asks. Loudly. Even if you don't ask, but he thinks invoking his past development experience might help score points in whatever argument he's trying to make about why you did something wrong even though you did exactly what the spec says and he's introducing scope creep.

    Admittedly, it's a sample size of 1, but... yeah. In my experience, (former) developers make absolutely lousy QA people.


  • FoxDev

    @masonwheeler It's certainly the case that some developers hate testing, but there's also the fact that the worst person to test some code is the person who wrote said code, as they can subconsciously avoid bugs that another person would find.


  • Discourse touched me in a no-no place

    @masonwheeler said in One for those of you who work in QA..:

    In my experience, (former) developers make absolutely lousy QA people.

    They're distinct skill-sets, but occasionally they overlap. I think we've just hired someone like that; they start next month. ;)



  • @Yamikuronue said in One for those of you who work in QA..:

    @cheong said in One for those of you who work in QA..:

    They are the one who write Unit Tests for developers.

    Fucking lazy-ass devs

    From a different perspective: fucking lazy-ass people writing tests but not the code that makes the tests pass. 🚎


Log in to reply