In the process of project testing, most testing tasks involve the cooperation of multi end development. Common cooperation ends include client, front-end, server, kernel, etc. This kind of multi end cooperation is especially reflected in some complex requirements and tasks, and even involves cross platform development cooperation. In the recent project test, I have accumulated some methods (pitfalls) in this regard, and I would like to share them here.
In the actual project, when it comes to multi terminal and multi platform development cooperation, the problems encountered by Xiaobian mainly include the following:
1. Multi end development meets the requirements. One end fails to test before the overall joint commissioning is successful, which affects the test progress and the overall project progress;
2. The requirements for multi platform and multi terminal development cooperation are not unified in the early interface agreement, which is exposed in the later test execution, affecting the test progress and project quality;
3. Multi platform and multi terminal development cooperates with the requirements, and the requirements change and confirmation information are not synchronized, which affects the platform project testing involved later;
4. Multi end development meets the needs, and the communication cost of bug forms increases;
5. Multi end development meets the requirements, and there is a lack of unified development progress controller;
……
How to solve these problems? First of all, we can analyze that the key points of the above issues mainly focus on the internal cooperation and external output of each end development at each stage node of the project, as well as the cooperation between development and testing.
The following editor will share solutions to relevant problems based on his own project.
After communication and discussion, the project team carried out corresponding analysis and coordination for each problem, and finally abstracted the following optimized process specifications.
In the requirement review phase, it is necessary to ensure that all involved development partners participate in the review of the rationality of the requirement scheme. On the one hand, this can effectively ensure the synchronization of information, on the other hand, it can better expose the feasibility and rationality of the demand scheme in advance.
The advantage of all end development students participating in the communication is that they can fully communicate the scheme specification of the docking interface in advance to prevent subsequent repeated adjustments and changes; In particular, it is more suitable for multiple platforms to jointly realize a certain demand task. This can effectively prevent later exposure of inconsistent interfaces while ensuring information synchronization.
A demand test task recently participated by Xiao Bian needs to be implemented on both Android and iOS platforms, but in the actual project, due to various reasons, the rhythm of the two platform projects is different, and the iOS platform takes the lead. During the test, it was found that due to the lack of participation in the development of the Android client in the early communication technical scheme, the calling method of a common interface between the Android and iOS client and the front end was inconsistent, which made it impossible to give good consideration to the two platforms when the front end and the client cooperated to modify problems in the later stage.
According to the agreement with the development team, if it involves multi end coordination requirements, the development scheduling of each end should first clearly mark the associated development end; Secondly, the test time should be the final overall real testable time point, which requires cooperation with the end development team to communicate clearly with each other about the time point of multi-party joint debugging when making scheduling.
In the format of the development scheduling email, it can be clearly marked whether it is necessary to support joint debugging at all ends and the time of joint debugging.
In addition, if each end is associated with requirements and the development scheduling and testing time of each end is inconsistent, the testing can be scheduled based on the last testing time point.
In the testing phase, the development progress of the entire requirement should be controlled by the students at the main development end of the requirement;
In terms of requirement update and maintenance, if multiple platforms jointly implement the same requirement, and one platform takes the lead, in order to ensure the synchronization of platform requirement update information later, the update record details of requirement interaction documents can be maintained at the beginning of requirement implementation.
In terms of bug submission and follow-up, for bugs that cannot be judged on specific ends, test students can uniformly submit them to the direct upstream of the test - client development students, who will follow up and distribute them internally.
The above is the normative scheme based on the problems encountered in the project of the small staff.
In fact, each project team will be more or less different. I believe that there is no optimal process specification, and the process specification that is most suitable for your project is the best. Therefore, compared with the reference conclusion of process specification, the way and means of problem solving are more important.
How to solve such problems in actual projects
What about ？
In this article, I give some useful ways and means in my own projects for reference.
During project implementation, if there is any impact
The coordination between progress and quality can be solved by three synchronized parties at the first time. The effective synchronized promotion methods are:
term Morning meeting of the project team;
Daily project progress report email;
Offline communication group for project progress;
……
After the completion of the project, problems can be collected in a centralized way, and the project team's review meeting can be organized to promote the implementation of solutions in subsequent projects.
Testing is a downstream team. In the actual project, we often encounter some cooperation problems with the upstream team. In order to better improve the energy efficiency of testing, we need to throw out these cooperation problems in time, and promote the implementation of solutions through some methods, so that everyone can optimize the progress, and the whole project will make better progress.
Sogou test WeChat signal: Qa_xiaoming
Sogou test QQ fan group: 459645679
This article is shared from the WeChat official account Sogou QA.
In case of infringement, please contact support@oschina.cn Delete.
Participation in this article“ OSC Source Innovation Plan ”, welcome you to join us and share with us.
