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.

We have a big remote SQA team now who have identified about 600 bugs with test cases to both assist in manual testing and prepare for us to start automation testing.

Our development lead has setup a Jenkins server with Selenium and PHP driver for our Zend Framework environment.

My next assumed step is to start having SQA Engineers write the PHP code for each test as per our template:

class WebTest extends PHPUnit_Extensions_Selenium2TestCase
{
    protected function setUp()
    {
        exec('DISPLAY=:0');
        $this->setBrowser('firefox');
        $this->setBrowserUrl('http://www.google.com/');
    }

    public function testTitle()
    {
        $this->url('http://www.google.com/');
        $this->assertEquals('Google', $this->title());
    }

}

I'm now remembering hearing that developers should understand how to write unit tests into their code... So, are there different cases which will require developers to write unit tests or can it fully be the responsibility of the SQA Engineers?

share|improve this question
    
Welcome to SQA. What do you mean by "SQA team [...] have created about 600 bugs"? They introduced defects to the code base? –  dzieciou Dec 22 '12 at 8:41
    
Sorry, AdHoc by testers identified 600 bugs. –  lalalalalalalambda Dec 22 '12 at 9:22
    
I think @Leon means "have logged 600 issues in the tracker" - experience shows at least 10% will be dupes, and 10% will be "Behaviour as expected"... a chunk will be "the requirements are wrong" some "the test case is wrong" leaving the balance as "proper bugs" –  Andrew Dec 22 '12 at 9:59
1  
What do you mean by unit test ? That example doesn't look much like one ? –  Phil Kirkham Dec 22 '12 at 11:13

4 Answers 4

up vote 3 down vote accepted

Let's get things straight. Unit Tests are different from SQA Test Cases that have been automated. How?

Unit Tests are the developers responsibility because it mainly involves knowing whether their work, in this case a software unit (where unit testing comes from), is correct and complete with the ability to repeatedly check it when they make changes. It is not a QA activity as the writing of unit test itself maybe subject to QA. This is mostly seen in development teams that practice TDD (test-driven development) or BDD (behavior-driven development).

Automated SQA Test Cases are test cases developed by the SQA Team that was originally run manually. This involves the steps, data and permutations of such derived from user expectations or requirements. This is mostly front-end and mostly involved blackbox testing with some exceptions. They are not supposedly meant to test implementation but rather test the application if it met functional and non-functional requirements as users experience it.

Your example is an Automated SQA Test Case using PHPUNit - the same tool you use to create Unit Tests. To simplify it for your team, if it involves testing what a method or function returns, then it is a Unit Test and developers are responsible for it. If it involves inputting data from the browser or application and automating that, then it is the SQA automation team's responsibility.

share|improve this answer
    
Thanks @RumVerse. I think the difference between white box and black box helped me understand the differences. So, developers know and are required to know the code they right, making it "white box". SQA staff may not need to know the code inside out to create functional black box tests. –  lalalalalalalambda Dec 22 '12 at 17:42
    
I think as another poster mentioned, the roles may be interchangeable, but with our current resources and to entice developers to write better code, it makes sense for devs to be the ones to create white box unit tests. SQA staff will create front-end/input based tests. –  lalalalalalalambda Dec 22 '12 at 17:49

If your devs are writing such buggy code then they should definitely be writing tests for their code. Why can't it be a team effort rather than an either/or ? The devs can write the code with the testers helping with test ideas, or the devs can help the testers code up their tests

share|improve this answer
    
Thanks @Phil, yes, I think as others have mentioned, there are different tests which may be suited to different staff roles but the key will be in collaboration. –  lalalalalalalambda Dec 22 '12 at 17:52

According to my opinion. Writing unit test cases is the primary responsibility of developers. But QA Engineer can also writing unit test cases in rare cases. Seperate from Unit test cases. QA engineers have to write other test cases for different type of testing i.e load, performance, functional. Developers write unit test cases to make sure that product is fully functional and free of bugs.

share|improve this answer
    
Welcome to SQA, Usman. If developers write test cases to make sure the product is fully functional and free of bugs than what is the goal of QA engineers in writing tests? Is that goal different? –  dzieciou Dec 22 '12 at 8:43
    
BTW making sure that product is free of bugs is practically impossible, given the number of variables that impact the code base. You can only get some level of confidence about that. –  dzieciou Dec 22 '12 at 8:46
    
Thanks guys, @Usman is actually one of our new remote SQAs. The word there is "functional tests"... vs "unit tests". What is the difference, with an example if possible? –  lalalalalalalambda Dec 22 '12 at 9:21

There is more than one way to address quality problems. The best strategy for your group will depend on a lot of factors, e.g. the individual capabilities and attitude toward quality, personal dynamics in the team, the maturity of the product, and the profitability of the company.

It helps for the whole team to understand the extend of the quality problem. Even better, it helps if the team understands that they jointly "own" the problem. At that point, you can try to have a rational conversation about who should write tests -- with the understanding that if the approach doesn't work, you will have to try something different. Automated testing is a means to an end, not an end in itself. If you can decide, in measurable terms, whether your automated testing is achieving your goal, you will have an easier time deciding whether your strategy needs adjustment.

share|improve this answer
    
Thanks @user246, I think that is also a very good perspective to look at this from. –  lalalalalalalambda Dec 22 '12 at 17:50

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.