There are roughly three software development processes I have experienced, which are:
1. DEV-QA-PM 2
For details, see http://lijingshou.iteye.com/blog/902249
This process is said to be learned from Microsoft. The three roles are known as the troika. In an ideal situation, PM will not modify frequently after the requirements document is set, and development will complete tasks as planned... QA will naturally also Successfully complete the use case review. Execute. Test
2. Agile iterative development
For details, see http://lijingshou.iteye.com/blog/920031
I would like to say that for large and long-term development projects, iterative development is undoubtedly very suitable. Because there are many iteration cycles, detours can be avoided, and errors can be corrected in time, even if found after an iteration problem, can also be fixed in the next iteration
3. Business people-driven development
Business personnel are often at a lower level in the company and lack professional skills in computers, but they are also the deciders of demand and progress. In this kind of organization,
- There are often no very formal requirements documents, and the release date of the product is relatively fixed, but there may be new requirements at any time.
- These requirements are small changes in the eyes of business people, but for development and testing, they often involve many functions. A lot of regression testing needs to be done, because new requirements proposed in a hurry often make us make some ill-considered decisions.
- Due to the lack of understanding of the system architecture by business personnel, the requirements often put forward are also unreasonable or inappropriate. Especially in the case of rapid repairs
In my opinion, it's the most important thing to tell the development and test teams as early as possible what exactly you need (requirements documentation), otherwise it may bog down the team and fail to deliver a qualified product.
For testers, in this case, the most effective prevention method can only be:
- Do as many stable automated regression tests as possible to effectively reduce regression testing time. For development, do as many unit tests as possible
- Try to dig out the impact points in the new requirements as much as possible, that is, the impact of the new requirements on the original system, and try to let everyone know all the risks brought about by the changes.
This article is from " lijingshou " blog, please keep this source for reprinting http://lijingshou.iteye.com/blog/2017195
There are roughly three software development processes I have experienced, which are:
1. DEV-QA-PM 2
For details, see http://lijingshou.iteye.com/blog/902249
This process is said to be learned from Microsoft. The three roles are known as the troika. In an ideal situation, PM will not modify frequently after the requirements document is set, and development will complete tasks as planned... QA will naturally also Successfully complete the use case review. Execute. Test
2. Agile iterative development
For details, see http://lijingshou.iteye.com/blog/920031
I would like to say that for large and long-term development projects, iterative development is undoubtedly very suitable. Because there are many iteration cycles, detours can be avoided, and errors can be corrected in time, even if found after an iteration problem, can also be fixed in the next iteration
3. Business people-driven development
Business personnel are often at a lower level in the company and lack professional skills in computers, but they are also the deciders of demand and progress. In this kind of organization,
- There are often no very formal requirements documents, and the release date of the product is relatively fixed, but there may be new requirements at any time.
- These requirements are small changes in the eyes of business people, but for development and testing, they often involve many functions. A lot of regression testing needs to be done, because new requirements proposed in a hurry often make us make some ill-considered decisions.
- Due to the lack of understanding of the system architecture by business personnel, the requirements often put forward are also unreasonable or inappropriate. Especially in the case of rapid repairs
In my opinion, it's the most important thing to tell the development and test teams as early as possible what exactly you need (requirements documentation), otherwise it may bog down the team and fail to deliver a qualified product.
For testers, in this case, the most effective prevention method can only be:
- 做尽可能多稳定的自动化回归测试,有效减少回归测试时间.对开发来说也要尽可能多得做单元测试
- 尽可能地挖掘出新需求中的影响点,也就是新需求对原有系统的影响,尽量让大家都知道改变所带来的所有风险
本文出自"lijingshou"博客，转载请务必保留此出处http://lijingshou.iteye.com/blog/2017195