Shulou(Shulou.com)06/03 Report--

15.3.1 some successful people or companies do not think that independent testing roles (Test) are needed. What do you think?

I guess it's similar to playing football for the same reasons:

People are too awesome: unborn geniuses, such as Gartner, found that typesetting software was not easy to use when he wrote a book, so he wrote one himself. I haven't heard of any independent testers he hired for this software project. By the way, he doesn't read Email and has a secretary to help him with these things-this is also a kind of division of labor!

Some software engineers delve into and develop difficult algorithms in the background, or do some background processing work, which is more difficult, and the testing is mainly done through tools. If you have to find a tester, the level of the tester must be quite high. If the level is so high, it would be better to participate in the development together.

It's too small: "I wrote a small class library and tested it all by myself." of course it's good.

But if we start from this argument, vigorously push the boat along the river and extend it to all situations, it is obviously inappropriate to come to the conclusion that programmers should test on their own and full-time testing is not needed.

There are not enough people: it's good to do more things by yourself. As mentioned earlier, one person can play multiple roles.

Ignorance: it's hard to say.

15.3.2 Why do some successful companies not use testers to trigger online discussion two articles are here:

The Chinese translation of http://sriramk.com/blog/2012/01/testing.html is http://www.aqee.net/on-testers-and-testing/.

Http://www.quora.com/Is-it-true-that-Facebook-has-no-testers

The highest-rated answer came from a former employee (Evan Priestley), who summed up why Facebook doesn't seem to have full-time testers:

A) people throughout the company often use their own software products! If the software you develop is a space flight control module, how can you use it often? )

B) use log to analyze where the problem might go. Some of our programmers write programs without log, so what are you looking at? )

C) use user feedback and real-time status analysis (compare data from the past hour and the same time last week to determine if there is a bug. )

D) the application developer reported bug to Facebook. Developers are actually quite upset, but FB sometimes modifies API without warning. What else can you do except to report to bug quickly? )

E) many people volunteered to report bug to Facebook, who claimed to report 13000 questions to his former employer every month. (yes, 13,000 a month! )

F) finally, the former employee added: another reason is that Facebook generally does not need to produce high-level software.

When your company can also have a) to e) such culture, processes, developers and powerful former employees, and your software is "generally not too high quality", you really don't need any full-time testers!

15.3.3 how does Microsoft do it? As stated in the MSF principle, there is a division of labor and cooperation. Microsoft development testing has three main roles [I]:

SDE:Software Design Engineer, abbreviated as dev.

SDE/T:Software Design Engineer in Test, also writes code, but focuses on testing.

STE:Software Test Engineer .

Many Microsoft teams have done a lot of exploration on how to develop Internet applications more effectively. Microsoft didn't have many dedicated testers at the beginning, and in 1984, the developer-to-test ratio was 20:1. Later, as the product line changed, some projects had almost as many testers as developers. Recently, some teams, which are related to the Internet business, have tried to integrate SDE and SDE/T. Everyone is responsible for the whole process of development / testing / release. According to my observation, this approach has both advantages and additional costs.

15.3.4 how should the team arrange QA and testing work testing, quality assurance, the quality of software engineering, and what should teams and individuals do? I think,

In the initial stage (the new project, the team enters a new field, the person has just entered a project), each team member should try his or her best to get through all the links, be more responsible, understand everything and cultivate generalists.

When the project / industry develops to a certain stage (when entering positional warfare), we should vigorously promote division of labor and cooperation and train professionals. At the same time, it is necessary to integrate good tools and processes, from daily construction to the automation of basic functions as soon as possible.

Do a good job in the structure and process of your own project, so that everyone can work on QA more easily, so that the "software engineering quality" of the team will be improved.

Cultivate a culture that "everyone should do QA, someone is responsible for quantifying Test, and there are conditions to do more test automation".

Understand the characteristics of your own project and avoid copying the practices of others. Don't hear about the development / test ratio of so-and-so's great project, so cry for the same ratio.

If a team is serious about doing software, they must consider how to ensure the quality of the program / the quality of software engineering, and how much it will cost to achieve that quality.

15.3.5 career development of testers

After the division of labor, each person is responsible for a small piece of things, how can we reflect the unique and great value of the individual? For example, if you have just arrived at a publishing house and your leader has asked you to do the job of "second instance", or if you have just joined a software company and the leader has asked you to do the job of "testing", how can you show your unique value?

Please find several software testing engineers (for example, brothers and sisters who graduated from the testing major of the Software Institute a few years ago, active users in the testing forum, testers from software companies), and understand and discuss the testing major with them.

15.4 how to measure the quality of software engineering

At the beginning of the book, we talked about how to prove that we are good at software engineering:

Develop software that meets the needs of users

Release "good enough" software within the expected time through a certain software process.

And through data and other means to show that the developed software can be maintained and continue to develop.

Can we quantify these points mentioned above? The students in the group can come up with some indicators, can also look up the academic discussion from the literature, and can also be summarized through practice.

Here are some commonly used quantitative metrics, the number of bug found after the software release

Number of DCR after software CC

Good / bad reviews from users (e. G. AppStore's 5-star rating)

Number of bug found after CC

Completeness and accuracy of the document (expressed as a percentage)

Average time it takes to repair bug

The number of significant bug per unit of development (person * month)

Coverage of test cases

Complexity of the module (detected by tools and quantified)

Number of lines of code

The number and complexity of documents

How much code has been reused?

Average number of build failures per day

How many function points have been realized by the software?

How long can the software run, average first error time (mean time to failure), mean time between failure (mean time between failure).

The team can select seven metrics (including those they have come up with), then calculate them in the project and track them.

[I] this book tells many stories about Microsoft's various characters: How To Move Mount Fuji, author: William Poundstone, ISBN 0316778494

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.