As my company begins its first agile project, I'm wondering if it would be easier to have separate tasks for QA and development for each story/requirement. Is it a cleaner process or will the lack of insight into development tasks be hazardous for QA since their tasks will be separate. Any feedback would be greatly appreciated.
My company has been using Agile for a while so I can provide some answers.
First of all we do only black-box testing, we don't have the access to the code. Therefore each story has some technical sub-tasks defined and these tasks are handled only by developers. We don't test them.
As for the rest - we share all the tasks/stories (whatever you call it). There are reasons for that. One is that you mentioned - the lack of insight, lack of the "big picture" may become a problem. There is a difference between testing and quality assurance. You need the big picture, you need to monitor everything that's happening in a project, so you can see the risks early. I don't only report bugs to developers. My duty is also to report about the possible risks to project manager. While developers often work on just a part of the application, someone is needed to look at it as a whole. That's why I think separating tasks is simply not a good idea.
Another thing is that working on common tasks seems just easier and simpler to me. You asked if separating tasks is "cleaner" process. Well, I don't think so, I'd say just opposite. It would be much easier for everyone to define states (like implemented/tested/resolved etc.) for every task and implement a proper workflow.
Last thing - common tasks = better planning. If you are implementing the Agile you must have heard about colored cards on the wall (if not - google for 'color cards agile'). This is great idea - it lets me see what is currently being developed (or waiting in development queue). Thanks to that I can better plan my work (for instance - I can see that even if I don't have too much to do at the moment, things might get hectic soon (because there are lots of tasks being implemented so they will be assigned to me next day)).
I hope this helps. Good luck with transition to Agile. It may be difficult in the beginning but eventually things will get smooth. :)
On a true agile project the line between development and testing can become very, very blurry. A team that is properly implementing behavior driven development (BDD) will be automating acceptance tests as part of each feature.
There are pros and cons with this approach as each feature is not done until the automation is written, however the tests are typically at a lower level than a tester would right.
The other thing is that typically, they are not actually testing, they are checking instead. For actual testing you need someone with a testers mindset to research and apply sapience and utilize heuristics to find bugs in a typically exploratory manner.
I'm going to go with my favorite answer here - it depends.
Here's why: often testing is black-box, and testing tasks can have little relationship to programming tasks within the same user story, particularly if you're working with an existing code base that's got years of waterfall development (and not much unit testing) behind it. At the same time, you want to decide on the tasks as a team, and decide whether they fall into the testing realm or the programming realm (or somewhere else). Your testers might not have the technical skills to take programming tasks, but your programmers can take testing tasks.
I'd suggest that the team works together to decide the tasks, and whether for this particular task or story it makes sense to separate testing or not. For instance, where I work it's common to have programming tasks to create internal business objects or business logic engines. These can't be directly tested, so the testing realm for these tasks is pretty much missing - the testing happens when the GUI use of the objects or engines is available, and when the database changes reflecting them occur. Other tasks might have a lot of overlap, such as adding validation to a logon form.
Ultimately, the "best" solution is what works best for your team with that task.