Modern software engineering Chapter 1 [Quality Assurance] exercises and discussions

14.1 What do some successful people or companies think they do not need independent test roles?

Just like a lot of things, we cannot say everything too absolutely. For example, most software development is conducted in the form of groups, each person has assigned a module. If everyone tests his or her own modules, you do not need an independent test role in this case, the programming process is constantly troubleshooting and testing the program. However, all the modules are integrated into a large system. In this way, if the programmer only tests the module, it must not meet the requirements. At this time, an independent test role is required to test the scale of the entire system, test the system without knowing the internal code status, and report it to the programmer, finally, make a complete system that meets your needs.

14.2 why some successful companies do not need testers

After reading some documents, I also spoke a lot about my views. I don't know much about these materials. However, I read a piece of the documents that I still agree with: Sriram Krishnan: "developers should test their own code. There is nothing to say. The truth behind this is not important. This includes unit testing, full-coverage automated testing, manual testing, or combined testing. If your developers cannot/do not want or think that this is "not my responsibility", you need a better programmer ."

14.3 Career development of testers

When I saw this problem, I found some comments on the Internet, and I also felt something.

1. Continuously improving test strategies, improving test efficiency, and improving quality test strategies must master development technologies. However, technology is only a necessary condition and more important capability. It is a matter of systematic planning, analyze the problems at work, select the most effective solution, and ultimately achieve a common improvement goal with everyone. The following aspects are generally taken into account to improve the testing strategy: unit testing (white box and gray box), automated testing, performance testing, security testing, usability testing, and so on. Of course, the specific improvement goals should be selected based on different businesses.

2. Be able to "Eat" the business and control the testing quality of the business. After a tester eats a business, the test work can be completely handed over to another tester, and the quality of the test can also be guaranteed. To achieve this goal, the key lies in the document. We need to improve the test cases, business precipitation, test design, test scripts, and other documents based on the business. More importantly, organize these scattered documents into a systematic document system.

If you may be engaged in testing in the future, you may have a better understanding of this.

14.4 how to measure the quality of software engineering

In addition to what the instructor said, I think there are the following:

A) critical bug severity-a serious bug will make Users unable to use the software, let alone accept the product.

B) Test Case density: The Case density directly affects the number and severity of bugs.

C) customer feedback defects, that is, missed tests

Modern software engineering Chapter 1 [Quality Assurance] exercises and discussions