1. Does your project team use source code management tools?
should be used. VSS, CVS, PVCS, ClearCase, CCC/Harvest, FireFly are all available. My choice is VSS.
2. Does your project team use a defect management system?
should be used. ClearQuest is too complicated, my recommendation is BugZilla.
3. Is your test group still writing test cases in Word?
Do not use Word to write test cases (Test Case). A special system should be used, which can be Test Manager or a small ASP.NET website developed by itself. The main purpose is Track and Browse.
4. Has your project team established a web portal?
Have a portal for Contact Info, Baselined Schedule, News, and more. Recommended Sharepoint Portal Server 2003 to achieve, 15 minutes to get. Can not afford SPS 2003 can use WSS (Windows Sharepoint Service).
5. Does your project team use the best tools you can buy?
It should be done with the best possible tools. For example, C# should be written in VS.NET rather than Notepad. Writing programs with Notepad is mostly just a show. But also consider the cost, so it is "the best you can buy".
6. Do your programmers work in a quiet environment?
Need a quiet environment. This is extremely important, and it is necessary to ensure that each person's space is larger than a certain area.
7. Does each of your employees have a phone?
One phone per person is required. And the phone is best with a message function. Of course, the cost of such a telephone system with voicemail is not small. But at least everyone should have a phone. Don't make people stand up and shout: "So-and-so phone". "Human Piece" strongly condemns this practice.
8. Does each of you know who to call if there is a problem?
should know. Any Feature should have at least one Owner, of course, Owner can continue to Dispatch to others.
9. Have you ever met someone who said "I thought..."?
To eliminate "I thought". Never assume anything.
10. Are all the people on your project team sitting together?
need. I oppose Virtual Team, and I also oppose the development method of Dev in the United States and Test in China. If you can sit together, it is better to sit together, and the benefits are enormous.
11. Does your schedule reflect the latest development progress?
should reflect. However, the schedule should be managed in the Baseline way: maintain a stable Schedule, and then maintain the latest changes. Baseline's methods should also be used for other Specs. Baseline is an important means of change management.
12. Is your workload first estimated by each individual?
It should be left to everyone to estimate for themselves. Estimate workload from the bottom up, rather than assign it from the top down. Unless there are other reasons, such as fixed duration of political tasks, etc.
13. Do your developers work overtime from the beginning of the project?
do not do that. Don't engage in fatigue battles in the first place. Working overtime from the very beginning of the project only shows that the progress of the project is unreasonable. Of course, some software outsourcing to Japan must work overtime every day, which belongs to the category of exploitation.
14. Is Buffer Time added to each small task in your project plan?
do not want. Buffer Time is added after each small task and is easily consumed. Buffer Time should be added in front of a Milestone or checkpoint in its entirety.
15. It’s worth spending some more time, going from 95% to 100% is worth it, very worthwhile.
Especially when people are tired in the later stage of the project, it is necessary to persevere. This will make a qualitative difference to the product.
16. When registering a new defect, are the reproduction steps written clearly?
want. This is a means of communication between Dev and Test. Face-to-face communication is required, and Repro Steps are also required to be filled in in detail.
17. Will known bugs be resolved before writing new code?
want. Everyone can't have more than 10 or 15 bugs, otherwise old bugs must be fixed before new code can be written.
18. Do you have a prior agreement on the priority of defects?
There must be a definition. Severity is divided into 1, 2, and 3. It is agreed that: Blue Screen and Data Lost are Sev 1, Function Error is Sev 2, and Sev 3 on the interface. However, this agreement can be appropriately adjusted according to the status quo of product quality.
19. Do you have a tripartite meeting on the pitfalls of disagreement?
must have. Have a clear decision-making process. This is similar to the CCB (Change Control Board) concept.
20. Are all defects finally closed by the person who registered?
The bug should be closed by Opener. Dev cannot close bugs without permission.
21. Do your programmers hate changing old code?
Disgust is normal. The solution is to organize Code Reviews and set aside time alone. XP is also a method.
22. Does your project team have Team Morale Activity?
I have to do it once a month, eat, sing, outing, play ball, go karting, etc. It must be there. Don't leave this money.
23. Does your project team have its own logo?
Have your own logo. At least it should have its own Codename.
24. Do your employees have T-Shirts printed with the company logo?
have. Can enhance a sense of belonging. Of course, the T-Shirt should be made to look better, and it is best to use 80-count cotton. Don't get tattered after wearing it a few times.
25. It is required for the general manager to participate in the project team meeting at least once a month.
Make team members feel that high-level attention is paying attention to this project.
26. Do you fork each Dev?
be opposed to. The management of Branch, as well as Merge, is too much work and prone to errors.
27. Has anyone not Check-In the code for a long time?
Can not. For most projects, Check-In should take at most two or three days.
28. Did you fill in the comments when checking the code?
To write, at least one or two sentences, such as "solved Bug No.225". If you pull up high, this also counts as part of a "configuration audit".
29. Is there a deadline for daily Check-In?
Yes, be clear about Check-In Deadline. Otherwise it will Build Break.
30. Can you compile all the source code into installation files at once?
need. This is the basis of the Daily Build. And it has to be able to be made automatic.
31. Does your project team do daily compilation?
Of course do. There are three things that are necessary for software project/product development: 1. bug management; 2. source control; 3. daily build.
32. Does your company maintain a list of project risks?
want. Risk Inventory. Otherwise, when the next project starts, you can only pat your head and analyze the Risk.
33. The simpler the design, the simpler the better.
One more word in design may bring endless troubles in the future. Should have cut bravely from the start. This is called scope management.
34. Try to use existing products, technologies, and codes, and don't code everything by yourself. BizTalk and Sharepoint are the best examples. With these two as a foundation, the starting point can be improved a lot. Or you can use the ready-made Control as much as possible. Or try to use XML instead of parsing a text file yourself; try to use RegExp instead of manipulating strings from scratch, and so on. This is the embodiment of "software reuse".
35. Do you stop to work on the code every once in a while?
want. Best once a month or so. Rumor has it that the Windows group stopped for a month at Stevb's order early last year to enhance security. Btw, the word "ram" is pronounced "hang", the first sound.
36. Does everyone in your project team write a Daily Report?
to write. Five minutes is enough. Write about 10 sentences and tell the people in your group what I did today. One is for communication, and the other is to spur myself (if I wander around for a day, I will be embarrassed to write it).
37. Will your project manager issue a Weekly Report?
want. Also for communication. The content includes the current progress, possible risks, quality status, progress of various work, etc.
38. Does your project team meet as a whole at least once a week?
want. Must have a meeting. Programmers hate meetings, but they should add up to at least 4 hours a week. Including team meeting, spec review meeting, bug triage meeting. Don't let everyone write code.
39. Are there records of the meetings and discussions of your project team?
Sending meeting requests and agendas before the meeting, someone during the meeting is responsible for hosting and recording, and someone is responsible for sending meeting minutes after the meeting. These are the main points of an effective meeting. Also, each meeting has to form agreements and action items.
40. Do other departments know what your project team is doing?
To send some Newsflash to the whole big organization. Show your team's value. Otherwise, when you sit in the elevator and people from other departments ask, "What are you doing?" and you answer "ABC Project", others don't know it at all, and it's not a good feeling.
41. All formal communication via Email
The advantage of Email is to avoid repudiation. But also to avoid overkill, the best way is to talk over the phone and in person first, then email to confirm.
42. Create multiple Mailing Groups for project groups
If it is in AD+Exchange, build a Distribution List. For example, I will build ABC Project Core Team, ABC Project Dev Team, ABC Project All Testers, ABC Project Extended Team, etc. In this way, it is convenient to initiate an Email, and it can make everyone who should receive the email receive it, and those who should not receive it will not be harassed.
43. Does everyone know where to find all the documentation?
Everyone should know. This is called Knowledge Management. The most convenient is to put documents in a centralized File Share, a better way is to use Sharepoint.
44. When you make decisions and make changes, do you tell everyone why?
To tell everyone why. One of the means of Empower team member is to provide adequate information, which is one of several principles that MSF started with. Indeed, it is human nature to tell me why, and only after telling me why can there be understanding. Chinese people like to restrict and restrict information. It seems that people who can see a certain document are people with identity. Big mistake. Authority and power do not depend on whether they can access information/data, but on whether they have access to resources.
45. Stay agile and expect change.
Requirements will definitely change, and the code that has been written will definitely be required to be modified. Be mentally prepared, don't resist change, but expect change.
46. Do you have full-time software testers?
Professional testing is required. If the manpower is not enough, you can peer test and exchange the test. Never test your own.
47. Does your test have a general plan for what to do and how to do it?
This is the Test Plan. Do you want to do a performance test? Do you want to do a Usability test? When to start testing performance? What are the criteria for passing the test? By what means, automatic or manual? These questions need to be answered with a Test Plan.
48. Do you write Test Case first and then test it?
It should be. It should be designed first, then programmed, and then tested with test cases. Of course, things are flexible. I sometimes add test cases while doing the first test. As for the first test case and then development, I don't like it, because I'm not used to it, it's too troublesome, as for other people's recommendations, it's okay to try it.
49. Do you create test cases for various input combinations?
Don't, don't engage in boundary condition combinations. Watch out for combo explosions. There are many test case tools that can automatically generate various combinations of boundary conditions - but think about whether you have the time to run that many test cases.
50. Can your programmers see test cases?
want. Let Dev see Test Case. We all came together for the same purpose: to improve quality.
51. Do you pick random people for usability testing?
to do so. Look at the program interface you wrote yourself, how you look at it is pleasing to the eye. This is called aesthetic fatigue - if you look at it for a long time, it will stop smelling, and if it is inconvenient forever, you will get used to it.
52. Are your expectations for automated testing correct?
Don't expect too much. In my opinion, in addition to performance testing, let's forget about "automatic testing" for now, forget about WinRunner and LoadRunner. For the current situation of domestic software testing, it can only be "overcorrection must be overcorrected".
53. Do your performance tests wait until all functions are developed?
not like this. Performance testing cannot be classified as a so-called "system testing" phase. Early detection and early correction, early death and early ascension.
54. Did you notice the pesticide effect in the test?
Bugs are resistant, and so do bugs. It is normal to find fewer and fewer new bugs. At this time, it is best for everyone to exchange the test area, or use other tools and methods to find some new bugs.
55. Can anyone on your project team say anything about the current overall quality of the product?
have. When the boss asks about the current quality of the product, the Test Lead/Manager should be responsible for answering.
56. Do you have unit tests?
Unit tests are required. However, it is not impossible without unit testing. I have done projects without unit testing, and I have done it successfully. It may be a fluke, or it may be that everyone is familiar with it. Again, software engineering is a very practical, very engineering, very flexible set of methods, some methods are better than others in some situations and vice versa.
57. Do your programmers throw the code over the wall after writing the code?
Taboo. After writing a program, even if you don't do unit testing, you should run it yourself. Although there are dedicated testers, those who do development cannot do no testing at all. Microsoft also said that Test Release Document, if the program is too bad, the test has the right to kick back.
58. Do all functions in your program have input checking?
do not want. Although input checking is the main point of writing secure code, don't do too much input checking. Some internal functions do not need to check the input for parameter transfer, which saves some effort. By the same token, it is not necessary to write comments to all functions. It is enough to write part of the main part.
59. Does the product have a unified error handling mechanism and error reporting interface?
have. It is best to have a unified error message, and then each error message has an error number. In this way, the user can go to the user manual according to the error number to see the specific description and possible causes of the error, just like the error of SQL Server. Similarly, ASP.NET also has a unified Exception handling. Can refer to the relevant Application Block.
60. Do you have a unified code writing specification?
have. There are many Code Conventions, just make a copy and send it to everyone. Of course, it would be better to have a tool like FxCop to inspect the code.
61. Does each of you understand the business sense of the project?
want. This is what Vision means. Don't think of projects as just work. Sometimes I think that I am a pioneer for the informatization of a certain industry in China, or tell team members from time to time that this project can save taxpayers’ money of millions of dollars every year for such and such a country. Motivated. Ordinary things can have lofty goals.
62. Are the interfaces and operating habits of each part of the product consistent?
To do so. Make the user feel that the entire program is written by one person.
63. Is there a Cool Feature that can be used as a promotional highlight?
want. This enhances team cohesion and confidence. Moreover, "one handsome covers a hundred ugliness", there are bright spots that can cover up some problems. In this way, customers will feel that the product is acceptable from a quality point of view. In other words, cool features or highlights can be used as an afterthought for quality problems.
64. This is done to minimize the start-up time of the product.
Software start-up time (Start-Up time) is the customer's first impression of performance.
65. Don't pay too much attention to the internal quality and ignore the external impression at first glance. Programmers are prone to make this mistake: they pay too much attention to performance, stability, and storage efficiency, but ignore the external feeling. On the other hand, senior managers and customers are the opposite. It is the PM's job to coordinate these two aspects.
66. Do you develop according to the detailed product function specification?
To do so. It is necessary to have design to develop. The design document should make it clear how the product will work and should take some kind of storytelling approach. When designing, don't drill into the details, don't drill into the database, code and other specific implementations, those are the things that follow, and you can't worry about it step by step.
67. Does everyone carefully review the functional design before starting development and testing?
to do. Function Spec review is used to unify ideas. Moreover, after the review, a consensus was formed. In the future, no one can say, "Look, I was against this design at the beginning, and now I'm suffering."
68. Does everyone always think about The Whole Image?
To do so. Although everyone in the project is only making a leaf, everyone should know what the tree where the leaf they are making looks like. I am opposed to software blue-collar workers, and I am opposed to taking software manufacturing as an assembly line or workshop. See Article 61.
69. Is the division of Dev work purely vertical or horizontal?
It cannot be divided simply according to functional modules, or simply according to the presentation layer, the middle layer, and the database layer. I recommend doing this: first divide it according to functional modules, and then each "layer" has an Owner to review everyone's design and code to ensure consistency.
70. Do your programmers write programming documentation?
want. But I heard that Microsoft programmers didn't write before 1999. Therefore, it is not absolute to write or not, and sometimes it is okay to be lazy. See Article 56.
71. Do you ask him to write a program during the interview?
need. I like having people do things like strings and linked lists the most. There are many loops, judgments, pointers, recursion, etc. in this kind of topic. It is neither too biased to test algorithms nor specific APIs.
72. Do you have any technical exchange lectures?
need. Have an internal Tech Talk or Chalk Talk every two weeks. Let the team members share their technical experience, and it is cost-effective to send the money to the outside for training.
73. Can your programmers focus on one thing?
Let the programmer focus on one thing. For example, say a department has two projects and 10 people, one method is to have 10 people participate in two projects at the same time, and each person spends 50% of their time on each project; another method is 5 people go to project A, 5 Individuals go to project B, and everyone is 100% on a certain project. I must choose the latter one. Many people understand this truth, but in practice, many leaders regard their subordinates as resources that can be divided at will.
74. Do your programmers exaggerate the time it takes to complete a job?
Yes, this is common, especially in the later stage of the project, it will exaggerate the time required to make a certain change, in order to resist the change. The solution is to sit down and grind slowly, grind away the programmer's rebellious psychology, analyze together, and reduce the granularity of the estimated time.
75. Try not to use Virtual Heads It is best not to use Virtual Heads.
Virtual heads mean that the resource is not secure, and the shared resource will reduce the work efficiency of the resource, which is easy to increase the chance of errors, and it will make the people who are single-minded do not have much time to review the spec and review the design. A dedicated person is better than two people who can only invest 50% of their time and energy. I have suffered a loss: 7 part-time testers, found bugs and work done, add up to two full-time ones. See Article 73. 73 are for programmers and 75 are for Resource Manager.
should be used. VSS, CVS, PVCS, ClearCase, CCC/Harvest, FireFly are all available. My choice is VSS.
2. Does your project team use a defect management system?
should be used. ClearQuest is too complicated, my recommendation is BugZilla.
3. Is your test group still writing test cases in Word?
Do not use Word to write test cases (Test Case). A special system should be used, which can be Test Manager or a small ASP.NET website developed by itself. The main purpose is Track and Browse.
4. Has your project team established a web portal?
Have a portal for Contact Info, Baselined Schedule, News, and more. Recommended Sharepoint Portal Server 2003 to achieve, 15 minutes to get. Can not afford SPS 2003 can use WSS (Windows Sharepoint Service).
5. Does your project team use the best tools you can buy?
It should be done with the best possible tools. For example, C# should be written in VS.NET rather than Notepad. Writing programs with Notepad is mostly just a show. But also consider the cost, so it is "the best you can buy".
6. Do your programmers work in a quiet environment?
Need a quiet environment. This is extremely important, and it is necessary to ensure that each person's space is larger than a certain area.
7. Does each of your employees have a phone?
One phone per person is required. And the phone is best with a message function. Of course, the cost of such a telephone system with voicemail is not small. But at least everyone should have a phone. Don't make people stand up and shout: "So-and-so phone". "Human Piece" strongly condemns this practice.
8. Does each of you know who to call if there is a problem?
should know. Any Feature should have at least one Owner, of course, Owner can continue to Dispatch to others.
9. Have you ever met someone who said "I thought..."?
To eliminate "I thought". Never assume anything.
10. Are all the people on your project team sitting together?
need. I oppose Virtual Team, and I also oppose the development method of Dev in the United States and Test in China. If you can sit together, it is better to sit together, and the benefits are enormous.
11. Does your schedule reflect the latest development progress?
should reflect. However, the schedule should be managed in the Baseline way: maintain a stable Schedule, and then maintain the latest changes. Baseline's methods should also be used for other Specs. Baseline is an important means of change management.
12. Is your workload first estimated by each individual?
It should be left to everyone to estimate for themselves. Estimate workload from the bottom up, rather than assign it from the top down. Unless there are other reasons, such as fixed duration of political tasks, etc.
13. Do your developers work overtime from the beginning of the project?
do not do that. Don't engage in fatigue battles in the first place. Working overtime from the very beginning of the project only shows that the progress of the project is unreasonable. Of course, some software outsourcing to Japan must work overtime every day, which belongs to the category of exploitation.
14. Is Buffer Time added to each small task in your project plan?
do not want. Buffer Time is added after each small task and is easily consumed. Buffer Time should be added in front of a Milestone or checkpoint in its entirety.
15. It’s worth spending some more time, going from 95% to 100% is worth it, very worthwhile.
Especially when people are tired in the later stage of the project, it is necessary to persevere. This will make a qualitative difference to the product.
16. When registering a new defect, are the reproduction steps written clearly?
want. This is a means of communication between Dev and Test. Face-to-face communication is required, and Repro Steps are also required to be filled in in detail.
17. Will known bugs be resolved before writing new code?
want. Everyone can't have more than 10 or 15 bugs, otherwise old bugs must be fixed before new code can be written.
18. Do you have a prior agreement on the priority of defects?
There must be a definition. Severity is divided into 1, 2, and 3. It is agreed that: Blue Screen and Data Lost are Sev 1, Function Error is Sev 2, and Sev 3 on the interface. However, this agreement can be appropriately adjusted according to the status quo of product quality.
19. Do you have a tripartite meeting on the pitfalls of disagreement?
must have. Have a clear decision-making process. This is similar to the CCB (Change Control Board) concept.
20. Are all defects finally closed by the person who registered?
The bug should be closed by Opener. Dev cannot close bugs without permission.
21. Do your programmers hate changing old code?
Disgust is normal. The solution is to organize Code Reviews and set aside time alone. XP is also a method.
22. Does your project team have Team Morale Activity?
I have to do it once a month, eat, sing, outing, play ball, go karting, etc. It must be there. Don't leave this money.
23. Does your project team have its own logo?
Have your own logo. At least it should have its own Codename.
24. Do your employees have T-Shirts printed with the company logo?
have. Can enhance a sense of belonging. Of course, the T-Shirt should be made to look better, and it is best to use 80-count cotton. Don't get tattered after wearing it a few times.
25. It is required for the general manager to participate in the project team meeting at least once a month.
Make team members feel that high-level attention is paying attention to this project.
26. Do you fork each Dev?
be opposed to. The management of Branch, as well as Merge, is too much work and prone to errors.
27. Has anyone not Check-In the code for a long time?
Can not. For most projects, Check-In should take at most two or three days.
28. Did you fill in the comments when checking the code?
To write, at least one or two sentences, such as "solved Bug No.225". If you pull up high, this also counts as part of a "configuration audit".
29. Is there a deadline for daily Check-In?
Yes, be clear about Check-In Deadline. Otherwise it will Build Break.
30. Can you compile all the source code into installation files at once?
need. This is the basis of the Daily Build. And it has to be able to be made automatic.
31. Does your project team do daily compilation?
Of course do. There are three things that are necessary for software project/product development: 1. bug management; 2. source control; 3. daily build.
32. Does your company maintain a list of project risks?
want. Risk Inventory. Otherwise, when the next project starts, you can only pat your head and analyze the Risk.
33. The simpler the design, the simpler the better.
One more word in design may bring endless troubles in the future. Should have cut bravely from the start. This is called scope management.
34. Try to use existing products, technologies, and codes, and don't code everything by yourself. BizTalk and Sharepoint are the best examples. With these two as a foundation, the starting point can be improved a lot. Or you can use the ready-made Control as much as possible. Or try to use XML instead of parsing a text file yourself; try to use RegExp instead of manipulating strings from scratch, and so on. This is the embodiment of "software reuse".
35. Do you stop to work on the code every once in a while?
want. Best once a month or so. Rumor has it that the Windows group stopped for a month at Stevb's order early last year to enhance security. Btw, the word "ram" is pronounced "hang", the first sound.
36. Does everyone in your project team write a Daily Report?
to write. Five minutes is enough. Write about 10 sentences and tell the people in your group what I did today. One is for communication, and the other is to spur myself (if I wander around for a day, I will be embarrassed to write it).
37. Will your project manager issue a Weekly Report?
want. Also for communication. The content includes the current progress, possible risks, quality status, progress of various work, etc.
38. Does your project team meet as a whole at least once a week?
want. Must have a meeting. Programmers hate meetings, but they should add up to at least 4 hours a week. Including team meeting, spec review meeting, bug triage meeting. Don't let everyone write code.
39. Are there records of the meetings and discussions of your project team?
Sending meeting requests and agendas before the meeting, someone during the meeting is responsible for hosting and recording, and someone is responsible for sending meeting minutes after the meeting. These are the main points of an effective meeting. Also, each meeting has to form agreements and action items.
40. Do other departments know what your project team is doing?
To send some Newsflash to the whole big organization. Show your team's value. Otherwise, when you sit in the elevator and people from other departments ask, "What are you doing?" and you answer "ABC Project", others don't know it at all, and it's not a good feeling.
41. All formal communication via Email
The advantage of Email is to avoid repudiation. But also to avoid overkill, the best way is to talk over the phone and in person first, then email to confirm.
42. Create multiple Mailing Groups for project groups
If it is in AD+Exchange, build a Distribution List. For example, I will build ABC Project Core Team, ABC Project Dev Team, ABC Project All Testers, ABC Project Extended Team, etc. In this way, it is convenient to initiate an Email, and it can make everyone who should receive the email receive it, and those who should not receive it will not be harassed.
43. Does everyone know where to find all the documentation?
Everyone should know. This is called Knowledge Management. The most convenient is to put documents in a centralized File Share, a better way is to use Sharepoint.
44. When you make decisions and make changes, do you tell everyone why?
To tell everyone why. One of the means of Empower team member is to provide adequate information, which is one of several principles that MSF started with. Indeed, it is human nature to tell me why, and only after telling me why can there be understanding. Chinese people like to restrict and restrict information. It seems that people who can see a certain document are people with identity. Big mistake. Authority and power do not depend on whether they can access information/data, but on whether they have access to resources.
45. Stay agile and expect change.
Requirements will definitely change, and the code that has been written will definitely be required to be modified. Be mentally prepared, don't resist change, but expect change.
46. Do you have full-time software testers?
Professional testing is required. If the manpower is not enough, you can peer test and exchange the test. Never test your own.
47. Does your test have a general plan for what to do and how to do it?
This is the Test Plan. Do you want to do a performance test? Do you want to do a Usability test? When to start testing performance? What are the criteria for passing the test? By what means, automatic or manual? These questions need to be answered with a Test Plan.
48. Do you write Test Case first and then test it?
It should be. It should be designed first, then programmed, and then tested with test cases. Of course, things are flexible. I sometimes add test cases while doing the first test. As for the first test case and then development, I don't like it, because I'm not used to it, it's too troublesome, as for other people's recommendations, it's okay to try it.
49. Do you create test cases for various input combinations?
Don't, don't engage in boundary condition combinations. Watch out for combo explosions. There are many test case tools that can automatically generate various combinations of boundary conditions - but think about whether you have the time to run that many test cases.
50. Can your programmers see test cases?
want. Let Dev see Test Case. We all came together for the same purpose: to improve quality.
51. Do you pick random people for usability testing?
to do so. Look at the program interface you wrote yourself, how you look at it is pleasing to the eye. This is called aesthetic fatigue - if you look at it for a long time, it will stop smelling, and if it is inconvenient forever, you will get used to it.
52. Are your expectations for automated testing correct?
Don't expect too much. In my opinion, in addition to performance testing, let's forget about "automatic testing" for now, forget about WinRunner and LoadRunner. For the current situation of domestic software testing, it can only be "overcorrection must be overcorrected".
53. Do your performance tests wait until all functions are developed?
not like this. Performance testing cannot be classified as a so-called "system testing" phase. Early detection and early correction, early death and early ascension.
54. Did you notice the pesticide effect in the test?
Bugs are resistant, and so do bugs. It is normal to find fewer and fewer new bugs. At this time, it is best for everyone to exchange the test area, or use other tools and methods to find some new bugs.
55. Can anyone on your project team say anything about the current overall quality of the product?
have. When the boss asks about the current quality of the product, the Test Lead/Manager should be responsible for answering.
56. Do you have unit tests?
Unit tests are required. However, it is not impossible without unit testing. I have done projects without unit testing, and I have done it successfully. It may be a fluke, or it may be that everyone is familiar with it. Again, software engineering is a very practical, very engineering, very flexible set of methods, some methods are better than others in some situations and vice versa.
57. Do your programmers throw the code over the wall after writing the code?
Taboo. After writing a program, even if you don't do unit testing, you should run it yourself. Although there are dedicated testers, those who do development cannot do no testing at all. Microsoft also said that Test Release Document, if the program is too bad, the test has the right to kick back.
58. Do all functions in your program have input checking?
do not want. Although input checking is the main point of writing secure code, don't do too much input checking. Some internal functions do not need to check the input for parameter transfer, which saves some effort. By the same token, it is not necessary to write comments to all functions. It is enough to write part of the main part.
59. Does the product have a unified error handling mechanism and error reporting interface?
have. It is best to have a unified error message, and then each error message has an error number. In this way, the user can go to the user manual according to the error number to see the specific description and possible causes of the error, just like the error of SQL Server. Similarly, ASP.NET also has a unified Exception handling. Can refer to the relevant Application Block.
60. Do you have a unified code writing specification?
have. There are many Code Conventions, just make a copy and send it to everyone. Of course, it would be better to have a tool like FxCop to inspect the code.
61. Does each of you understand the business sense of the project?
want. This is what Vision means. Don't think of projects as just work. Sometimes I think that I am a pioneer for the informatization of a certain industry in China, or tell team members from time to time that this project can save taxpayers’ money of millions of dollars every year for such and such a country. Motivated. Ordinary things can have lofty goals.
62. Are the interfaces and operating habits of each part of the product consistent?
To do so. Make the user feel that the entire program is written by one person.
63. Is there a Cool Feature that can be used as a promotional highlight?
want. This enhances team cohesion and confidence. Moreover, "one handsome covers a hundred ugliness", there are bright spots that can cover up some problems. In this way, customers will feel that the product is acceptable from a quality point of view. In other words, cool features or highlights can be used as an afterthought for quality problems.
64. This is done to minimize the start-up time of the product.
Software start-up time (Start-Up time) is the customer's first impression of performance.
65. Don't pay too much attention to the internal quality and ignore the external impression at first glance. Programmers are prone to make this mistake: they pay too much attention to performance, stability, and storage efficiency, but ignore the external feeling. On the other hand, senior managers and customers are the opposite. It is the PM's job to coordinate these two aspects.
66. Do you develop according to the detailed product function specification?
To do so. It is necessary to have design to develop. The design document should make it clear how the product will work and should take some kind of storytelling approach. When designing, don't drill into the details, don't drill into the database, code and other specific implementations, those are the things that follow, and you can't worry about it step by step.
67. Does everyone carefully review the functional design before starting development and testing?
to do. Function Spec review is used to unify ideas. Moreover, after the review, a consensus was formed. In the future, no one can say, "Look, I was against this design at the beginning, and now I'm suffering."
68. Does everyone always think about The Whole Image?
To do so. Although everyone in the project is only making a leaf, everyone should know what the tree where the leaf they are making looks like. I am opposed to software blue-collar workers, and I am opposed to taking software manufacturing as an assembly line or workshop. See Article 61.
69. Is the division of Dev work purely vertical or horizontal?
It cannot be divided simply according to functional modules, or simply according to the presentation layer, the middle layer, and the database layer. I recommend doing this: first divide it according to functional modules, and then each "layer" has an Owner to review everyone's design and code to ensure consistency.
70. Do your programmers write programming documentation?
want. But I heard that Microsoft programmers didn't write before 1999. Therefore, it is not absolute to write or not, and sometimes it is okay to be lazy. See Article 56.
71. Do you ask him to write a program during the interview?
need. I like having people do things like strings and linked lists the most. There are many loops, judgments, pointers, recursion, etc. in this kind of topic. It is neither too biased to test algorithms nor specific APIs.
72. Do you have any technical exchange lectures?
need. Have an internal Tech Talk or Chalk Talk every two weeks. Let the team members share their technical experience, and it is cost-effective to send the money to the outside for training.
73. Can your programmers focus on one thing?
Let the programmer focus on one thing. For example, say a department has two projects and 10 people, one method is to have 10 people participate in two projects at the same time, and each person spends 50% of their time on each project; another method is 5 people go to project A, 5 Individuals go to project B, and everyone is 100% on a certain project. I must choose the latter one. Many people understand this truth, but in practice, many leaders regard their subordinates as resources that can be divided at will.
74. Do your programmers exaggerate the time it takes to complete a job?
Yes, this is common, especially in the later stage of the project, it will exaggerate the time required to make a certain change, in order to resist the change. The solution is to sit down and grind slowly, grind away the programmer's rebellious psychology, analyze together, and reduce the granularity of the estimated time.
75. Try not to use Virtual Heads It is best not to use Virtual Heads.
Virtual heads mean that the resource is not secure, and the shared resource will reduce the work efficiency of the resource, which is easy to increase the chance of errors, and it will make the people who are single-minded do not have much time to review the spec and review the design. A dedicated person is better than two people who can only invest 50% of their time and energy. I have suffered a loss: 7 part-time testers, found bugs and work done, add up to two full-time ones. See Article 73. 73 are for programmers and 75 are for Resource Manager.