Software Development Well, always going to go to repair a variety of bug. Not just rely on a good software code they can engage in farming out, design, testing and other small partners' work is also essential. For example, in previous work assigned to only care about their own bug, fix on the matter, nor how considering why such a process. The company added just a minute class, think of these sum up today. Because some projects have been in the past for a long time, I can only rely on my memories, so there may be local irregularities or errors. Tell me what you or a better program also hope the wing.
Development Process
At present, I had handled the project is such a fundamental process. On a good boss and clients, according to the actual needs of clients to help them design a concept of a complete application. This time the design team of small partners will be involved, put these ideas to make a formal Design, usually in the form of PPT, showing the entire application UI design, with text descriptions to introduce certain specific functions. After designing small partners do, leadership and development teams will be confirmed, according to Gouzi observation, and here is the main front-end team to confirm whether there are some design to achieve good, the need for change. This time the team will work on this software to estimate, how many people probably need days to complete. Then according to the company's holiday schedule, determine a specific delivery date. Generally the decomposition function of specific items, such as one where the data to be inserted, this is a separate feature points. The thus separated out large and small feature points assigned to the specific development. Then each person to follow up its own Task estimate about how long it takes to finish. Here I thought when he first entered the company always worried about doing good, for others a bad impression, it is always the estimated time as little as possible. Fortunately, leaders take care of me, every time I estimate will be time to fight back - do you done this thing? Haha, I think quite Coke. Impression leadership seems to have said, you would normal working hours to estimate, then calculate the total time multiplied by a 1.5 came out, because they do not know where the card may be the Lord. Now think about it, really is the case.
In the design draft audit firm will be delivered to the customer after review by the general customers will need to make some local changes. For places need to be amended to repeat the above process for determining the design small partners will begin to prepare a series of things specific design, wireframes, cutting plans and the like. At the same time, a small group of partners will be developed according to the needs, to proceed to build a basic framework to study some special needs. The test of small partners will begin to prepare test cases.
Into the formal stage of development, so I probably experienced three modes.
- Customers no longer cared type. This is a project and Thai companies, and for them to make use of a mobile terminal. May be too large leadership can "blow", the other trust in our company, only agreed to the date and time to view the progress of the delivery center. Although it is not standard, but as a developer for this is still very interesting, usually the basic need to work overtime, before delivery you may only need to add the class for a while.
- "Agile development." Here I make a quotation mark is not sure this count as a real agile development, after all, the major technical forums beheld such a paper "is not used xxx, even agile development", and to record my memories, it is inevitable some inaccuracies. And then the boss will have the opportunity to talk with me, I would have another update here. Nonsense little pull, this mode is, the entire contents do as StoryBoard, then the function feature specific division need to specify a specific person assigned to it. Several specific Sprint separated at this StoryBoard, each of which comprises a sprint function is determined. Each Sprint is about 1 to 2 weeks. Each thing Sprint needs to be done about these:
- The completion of his body Feature / Task.
- Some higher priority Bug Fix on one of Sprint
- This test will help Sprint functional verification test
- Code review (code review)
- Package deployment may involve code freeze
- Hard work overtime type. This from the name you can see, the type most hard to force. Specific case like this, the customer is many years of cooperation and old customers. Due to local government policies, and their full money into a business you need digitized at a certain time, otherwise it is not allowed to conduct business. Customers will naturally put this task thrown us here, as the company two Gouzi the bottom of the soldier, nothing approach, overtime chanting. Row four weeks work plan six weeks, that's who Can Go ah this. Haha
The company has opened a traditional daily morning meeting is basically to report that the work yesterday, today, and what part do intend to work. The above three modes, I personally think that is only the second full use of the earlier meeting. Because everyone has a clear goal, which function even when done are defined very clearly. Will participate in the morning and you are dealing with and code, speak very logical. What do yesterday described 1,2,3, what problems encountered, the need for technical support. And today the contents of which part of the plan to do, whether before, back-end support, probably a few more. Clearly, the meeting is a pleasure. In addition to some special meetings, we usually standing meeting, it turns out, the less people will stand a lot of nonsense, ha ha.
When the entire project development nearing completion, generally small partners will test specific to each function points are detailed over several times. It is guaranteed not to affect some experience, or some very prominent bug. Of course, the reason this project is the end of overtime, after all, such a thing bug Well, we know everything. The period of time for testing and development partners will prepare a small documentation corresponding to the requirements of the deployment environment, to provide the source code, and so on. Think of it across the table Gangster reminds us: "The curse customer comments are deleted ah!", But also very interesting.
After delivery to the customer, usually have two to three weeks time used for UAT, user acceptance testing. The test period will be hard some of the small partners, and customers to communicate often, to see where the customers think that needs to be improved, or customers find what bug, recorded and assigned to the corresponding repair development. Development of small partners revel in this period of time is more, sometimes bug can not touch the fish of the day, sometimes more serious because the customer discovered the bug, overnight repair is possible.
Formally launched after the client side, our development team will be support, time is 1 to 2 months. After this time, for some long-term projects, the code will be transferred to the Support teams, their main job is to some maintenance, and cleaning up the data and so on.
Generally is such a process, of course, this is just a development perspective I can see, if there are omissions or where you can improve, and ask you to come. So it seems a bit summed up a new experience, and they will be a lot of attention to co-workers, but also very interesting is not it.
Come to talk about specific Bug tracking.
Currently experienced trac system probably just a few, trac, the company's own maintenance gitlab, mantis. mantis in fact be a source framework project draws on other people, did not really apply to work in the regression test bug, put aside the.
Trac
This trac system's quite old, but the functionality it very powerful. A bug's life cycle something like this, the test measured a small partner does not meet the design requirements of the problem. Specific description of the bug, comprising the step of reproducing, expected results, actual results, priority and the like. This division general priorities:
- Extreme impact testing or experience, denoted P0, such as mobile phone application crashes flash back.
- The full impact of the test through the whole application process, referred to as P1, such as the page jump to fail.
- Error untreated or branched route error, referred to as P2.
- And it does not match the design, but customers can accept, as some gestures behavior marked as P3 or not to repair.
It is then typically Assign to the corresponding development leader, he should be assigned to a specific development.
In a real project currently experiencing two such specific mode, in which the difference recorded for your reference. Test recorded as QA, development referred to as Dev, the same below.
- QA report Bug ==> Dev will fix Bug marked as Resolved ==> Dev repackage / deployment environment ==> Dev will fix Bug Assign to QA ==> QA verification Bug
- QA report Bug ==> Dev will fix Bug marked as Resolved ==> Dev repackage / deployment environment ==> QA view from his newspaper in which the bug has been marked as Resolved ==> QA verification Bug
Not looking likely no different. The main difference is actually after Dev bug fix or not to re-assign to QA. Here are two ways I think is good and their shortcomings. First of all to decide which approach to use depending on the type of project development process.
Under the first approach (we are desperately used in this way under overtime mode), the benefits are QA can clearly know which bug is Dev has been repaired, which has been repaired and is deployed to the test environment can be authenticated . Since the actual work, we know, bug repaired but also redeployed to qa qa environment there can really see the change, if only to submit the code, QA is still no change. However, this approach also has a drawback, as the team Leader, because after each Dev fix bug bug Assign all again gave QA, cause this bug owner changes on trac, we can not know exactly what everyone repaired bug, what are some statistical information in terms of who's who like bug.
Under the second approach, Dev just fix the Bug is marked as Resolved. Because the development process more standardized, so the time to update the test environment is relatively fixed, assuming that the content is updated every day before work. If a bug is repaired and the day is marked as Resolve, then it must be included in the new environment in the day before leaving work. Such tests can be used the next day to find their own screening Reporter bug, then take a look at what is already a good mark, for verification. In this way the leadership of the development team can clearly see who is who in what bug, fix the number, how serious. This way if the matching specific development model, in fact, great. Just some crazy overtime, one day may be updated several times environment, leading qa does not know his hand is not the code has been updated, or is not already included those changes are modified bug good, to their work causing distress.
GitLab
I vaguely remember Gitlab can associate a specific Bug and submit them to facilitate Dev viewing. And so on Monday I will find time I'll add it in detail, first slipped from work friends ha ha.