On Sat, Dec 21, 2013 at 11:00 AM, Željko Filipin <[email protected]>wrote:
> "...we need more testing in software development. And it needs to be done > by the people building the product..."[1] > > Agree? Disagree? > Of course developers should write integration tests! Of course developers should do manual testing. Those aren't interesting questions. To me, at least, the interesting questions are: 1. What do you do with developers that think it is beneath them to write integration tests? Unit tests? 2. Where should you store those tests? (We've mostly settled on next to the production code which seems like the right answer to me for lots of reasons.) 2. What code/features/changes should have unit tests? Integration tests? What is the difference, any way? 3. How do you make sure you stick to #3? 4. Where does documentation live? Do you build documentation from tests? Do you build tests from documentation? (Which one of these do we do or is it even listed?) 5. If integration testing is really just another speciality like databases what does this mean for people that have spent years doing one or the other? 6. What do you do when your organization doesn't jib with this reality? (WMF has a QA team when it might make more sense to matrix integration test specialists into teams to teach them how to write integration tests, for example.) 7. Holy cow how does this all line up with volunteers who only want to do one thing or the other and we really should take any help we can get. 8. Who pays attention to build failures and what do they do about them? 9. What system, exactly, are those build failures testing? Now that I think about it, who is coming to the architecture summit? These kinds of questions would be pretty interesting to talk about and might deserve a (late) RFC. Nik
_______________________________________________ QA mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/qa
