Testers are important for product development

Over the years, I have formed some of my views on testing, testing, and the entire software quality management system. And I was inspired by a post about the Facebook test, so I wanted to write it down and show it to people. There may be some points of contention. Well, in fact, even a little representation of that in a conversation can get people to despise.

1. Most development teams do not seem to need an independent test role. Even with one, all of his development time and all the test time should be >20:1. Are you asking me for proof? I'd like to see some of the most successful software development teams from ancient times. Whether it's Facebook today, or the original NT team 30 years ago, many great products are actually from teams with no or very few testers.

2. Developers should test their own code. This may be nothing to say. And the truth behind it doesn't matter. This includes unit testing, full coverage of automated tests or manual or combination tests. If your developers are unable or unwilling or think that this "does not belong to me", then obviously you need a better programmer.

3. I have some politically incorrect words to say. Some large software development companies will choose testers from a number of programmers who are not qualified for development work. I've heard a lot of people in the process of interviewing developers who say, "he/she does not do development." Maybe you could do a test? " This led to a widely tacitly accepted, but rarely avowed, recognition: Doing tests is not as smart as doing development. It is because of this pervasive prejudice that a handful of people who are enthusiastic and gifted at quality and testing have been unfairly treated. I know them because I've worked with some of these people.

4. It is dangerous to pursue code test coverage. Because it is easy to measure, it often becomes a substitute for a real goal-to develop quality software. If your development team is using Kung fu to write stupid tests to cover every single code path that is rarely available--because the data will appear in some reports--you have a problem. Test coverage is just one of the many metrics we use, and you need to use it, but not because it is presented in natural numbers, it can overwhelm other metrics. It became a victim of Goodhart's law.

5. I've also seen some companies with independent testers who write very good test code. Unfortunately, this is a common sense, even when it is not needed at all.

6. Just as test coverage is overused, some quality metrics are overlooked. For example: how many technical support mails have been generated during the process? Do you really use your own products at all times and check the problems inside? Analyze the log files generated from the production environment and customer installation. All of these strategies are mentioned in the above Facebook post.

7. A common way for technical leaders to reduce the volume of test teams is to do automated testing. This is a huge mistake. If you have a product that is directly accessible to a user, you absolutely need to test it with a human eye. If you and the Microsoft Windows team sit down together and have coffee, you will hear them complaining that excessive reliance on automated testing results in a large number of Windows Vista bugs. The problem with this error is that you need a full-time tester to use your product.

The author of this article, Sriram Krishnan, is a programmer who has worked in Yahoo and Microsoft, developed many software, has been reported by the New York Times, wrote a book, this article is one of his blogs.

Original link: On testers and testing