Quality Monitor - Increase Development Pleasure
Colleagues, good afternoon!
Today we will talk about the reasons prompting to create and implement methods and tools for quality assurance, look at the history of the problem, highlight known risks and try to “fix” the winning strategy of ensuring sufficient quality of web solutions in our minds. In conclusion, I will talk about the new instrument in the 11 version of the Bitrix platform - “Quality Monitor”.
Yes Yes. There is a method of ensuring a high quality web project, under which it will not fail, and Clients will not attack you with error messages on the forums and twitter.
')
For this you need only:
And then in the web project most likely there will be no errors and the system will be started in time! But the site, most likely, will become morally obsolete, will no longer be needed by the Users, and the Client will receive not what he wants, but what he wrote in the ToR :-)
Many nowadays, unfortunately, forget that a web project is a software system with rigid "Boolean" logic of applied mathematics and does not have a sense of beauty. This engineering design, like any other construction (bridge, house, plane) - should, in an amicable way, be designed up to the screw, be tested to the screw, and any change will require a revision of all project documentation. And so, thoroughly and scientifically, before and did software systems - Cascade approach (Waterfall) .
But intuition suggests that launching a website in this way is very expensive and probably very long. And to find high-class specialists in the team is not an easy task. I would like to find a way to “cheaply cheat”, not to do homework in math: how do they launch web projects quickly and with sufficient quality without multi-volume TK? :-)
People realized that it’s impossible to sit down with the Client and without leaving the negotiation to design a web solution in 2-3 days. And even locking system analysts in the office for a week does not solve the problem. It was understood that it is more effective to discuss and make the system in parts each time, analyze the results of the completed stage and take them into account when designing the next one. To go forward with small steps, not looking further into the future, for example, 3 months.
It is more convenient for many Clients to work this way - you see the result and correct the plan. For developers and testers this, of course, seriously adds hassle:
We see that, in an iterative approach, on the one hand, it became more convenient for the Client and, possibly, the project manager working with him, and on the other hand, the load on developers and quality specialists has increased, and the requirements for their qualification have increased.
A similar process can be organized both more formally ( RUP , etc.) and less formally . It all depends on the specific web project. Accordingly, you can use specialized software , but you can build everything “on your knees” (exelki, wiki, walls in leaves, etc.).
Currently, it is a rapidly growing website development process. The following is postulated:
It is obvious that such a “flooded” one needs self-organized people in a team, professionals in their field and a leader supporting this super creative atmosphere from attacks of despairing bureaucrats, pursuing personal selfish goals, etc. Otherwise, with any cotton, everyone will again run to the office desks and will start throwing letters and suffer with letter-eating.
This process is very convenient for a result-oriented client, since A web solution can be changed and developed all the time, not lagging behind the competitors - otherwise the Client becomes a hostage of the TK, as he wrote a year ago, we will do so. If the team is strong with predictable performance, then the Client gradually begins to effectively plan the next releases of the web solution.
On the other hand, the technical complexity of the solution increases very drastically, since supporting a constantly changing system in a state of “technical health” (when you know that you can confidently develop it further, and the cost of making changes will not begin to grow exponentially) - the task is not for the faint of heart and requires highly skilled developers.
For quality management of such a system (often without formal technical documentation), an arsenal of effective techniques is used:
Obviously, because such a development process balances on the verge of “controlled chaos”, and otherwise the market often does not allow the market, a significant role in ensuring order and predictability belongs to the maximum automation of testing, supplemented by checklists (checklists). The system should be able to check itself and quickly identify critical errors - and also we should know what and where we need to quickly check (if it is difficult to automate) at different stages of production: from layout to operation under load.
The healthy evolution of this process usually proceeds according to the following scenario:
Over time, the process of developing a web project stabilizes, making changes becomes “not so scary” - they are waited, the system is constantly updated, improved, relatively healthy, not only outside, but inside as well. There comes a phase of "effective world", which remains to be observed - because Any imbalance can reset production either into chaos, or stupid formalization and cost increases begin.
To consolidate success, reaching this level often introduces a cycle of continuous integration . To do this, you do not need to use specialized software , you can restrict yourself to a group of simple scripts and hot hearts of enthusiasts in the team.
We briefly repeated the evolution of web project development techniques (and not only the “web”) and saw that at present no one, as a rule, allocates enough time for the formal systematic development of systems (however, the waterfall and dependency matrices continue to be used in industries where the cost of a mistake is very high - when building houses, bridges, airplanes, when developing software for healthcare in the US, etc.), therefore, teams survive and fight fear using a limited set of highly efficient tools, one of which checklist.
Checklists are usually compiled by experienced staff, system and business analysts, functional managers. With the accumulation of intellectual baggage companies in knowledge bases, checklists are also developing and improving. The essence is simple - to save time and money by not allowing employees to involuntarily (and sometimes arbitrarily) step on the rake 2 or more times.
An example of an elementary checklist for a programmer:
Each item can be a link to the methodology in the wiki.
Nothing complicated, but how often many of these points are ignored.
And when it comes to checklists on preparing a web project for load testing or server maintenance ... There are so many important little things that are repeated from project to project. People often say that they remember them - in fact, experience shows that they do not remember, they miss important moments and are engaged in “stepping on a rake” from a project to a project, on the same thing, spending a lot of time. It’s not for nothing that experienced project managers close their stages / releases only if there are checklists-reports drawn up by responsible employees: from layout designers to system administrators.
When developing a web project on the box platform “1C-Bitrix: Site Management”, you can use any of the above processes. This reduces the following risks:
Nevertheless, even working in such close to perfect conditions, if you do not comply with the known requirements for integration, you can turn a web project into chaos, which is extremely difficult and expensive to maintain and develop. Moreover, the lack of order in the code and architecture greatly demotivates specialists, staff turnover begins - which further aggravates the situation with the development of a web solution.
To protect the development teams from the above risks, a Quality Monitor is built into the platform from version 11.
To launch a web project release, it is necessary to go through automated and manual control procedures at all stages of production: from layout to deployment on a hosting or cloud and load testing.
Each test can be in several states, some of the tests, especially routine ones, are automated:
The project manager or developer, in essence, must “tree” the test tree for the release / iteration - by completing all the tests and autotests:
When the release is delivered, it can be seen on the desktop and the list of testing reports:
Especially I want to highlight the checklist for "advanced" developers. These items will be especially in demand in Aglle / XP teams that pay serious attention to code quality and architecture:
Development teams can add their mandatory and optional checklist items and autotests, for example, customize CodeStyle validation, correctness of integration with the version control system, UnitTests code availability and coverage, and documentation in the style of PHPDocumentor :
The fact of modifying the kernel and the platform libraries is also checked automatically:
Development, as a creative process, should be fun. Then web projects will not be born dead and scary, and it will be easier and more interesting to support them :-)
Checklists covering the entire development process on the Bitrix platform, expandable by the internal checklists of the teams - we did. This will seriously reduce the risks associated with a lack of knowledge and understanding of the platform and generally “good practices” and will allow teams at retrospectives to improve the process by adding new items to the Quality Monitor.
Many interesting tasks, including transparent and efficient integration with distributed version control systems ( Mercurial , git ), support for phing build tools, support for multi-stage development environments (dev, testing, stage, production), support for continuous integration systems, support for efficient work geographically distributed teams are actively discussed.
I sincerely hope that the “Quality Monitor” will allow teams to unleash their inner potential, focus on the creative process of developing and improving the architecture, will become a kind of knowledge base gained from retrospectives.
Regarding “settling down” in the mind of a winning strategy of ensuring sufficient quality of the site ... I am convinced that in allocating time for detailed design and formalization when developing complex and large web solutions (or refactoring / rewriting such systems), you need to fight, otherwise you will not provide quality and in production chaos will begin. For medium-sized projects, in the presence of an “open modern” Client, Iterative methodology is well suited. For smaller projects, Flexible Methodologies have proven their worth. Do not be afraid to experiment and go ahead. Good luck!
Today we will talk about the reasons prompting to create and implement methods and tools for quality assurance, look at the history of the problem, highlight known risks and try to “fix” the winning strategy of ensuring sufficient quality of web solutions in our minds. In conclusion, I will talk about the new instrument in the 11 version of the Bitrix platform - “Quality Monitor”.
Ideal World - Waterfall
Yes Yes. There is a method of ensuring a high quality web project, under which it will not fail, and Clients will not attack you with error messages on the forums and twitter.
')
For this you need only:
- Find a programmer (s) certified for development in the PHP language, with experience of 5 years and a large portfolio of successful projects.
- Find a typesetter (s), in the intricacies of understanding the features of HTML / CSS in all popular browsers of the latest versions, hanging from morning to dinner on professional forums (I write, and tears appear in my eyes :-)). But this is not enough, because The typesetter should be able to program for javascript (and know the dialects of this language for all popular browsers), i.e. to be “concurrently” experienced programmer.
- Find a system administrator (s), well versed in at least one operating system and with experience of 10 years.
- Find a tester who can organize a system with 100% coverage of the generated web project code with unit tests and functional tests. This tester will have to understand in subtleties the subject area of ​​a web project, to know it better than the Client.
- And, of course, to find a Client who a) knows in detail that he wants better than any analyst in a given subject area, b) does not change his requirements before launching a web project into operation.
- As soon as the team is assembled, you start designing the website, draw, typeset and include in the statement of work the description of each web page, both in the admin panel and in the public section, with pixel accuracy and different versions of the page depending on the screen resolution of the User. The result is an illustrated TZ pages, 500, written for about six months.
- Then you need to evaluate each page in the TOR, make a detailed development plan for each day, set a date for entering the web project into operation.
- Of course, before launching, time is allocated for thoroughly testing the website made for compliance with the TK and design layouts, accurate to the pixel and the letter in the TK. We will have to test for a long time, in several approaches, but it is impossible to open the functionality with errors for Clients - most likely multi-phase testing will take 2-3 months, if not more.
And then in the web project most likely there will be no errors and the system will be started in time! But the site, most likely, will become morally obsolete, will no longer be needed by the Users, and the Client will receive not what he wants, but what he wrote in the ToR :-)
Many nowadays, unfortunately, forget that a web project is a software system with rigid "Boolean" logic of applied mathematics and does not have a sense of beauty. This engineering design, like any other construction (bridge, house, plane) - should, in an amicable way, be designed up to the screw, be tested to the screw, and any change will require a revision of all project documentation. And so, thoroughly and scientifically, before and did software systems - Cascade approach (Waterfall) .
But intuition suggests that launching a website in this way is very expensive and probably very long. And to find high-class specialists in the team is not an easy task. I would like to find a way to “cheaply cheat”, not to do homework in math: how do they launch web projects quickly and with sufficient quality without multi-volume TK? :-)
Combat reconnaissance - Iterative approach
People realized that it’s impossible to sit down with the Client and without leaving the negotiation to design a web solution in 2-3 days. And even locking system analysts in the office for a week does not solve the problem. It was understood that it is more effective to discuss and make the system in parts each time, analyze the results of the completed stage and take them into account when designing the next one. To go forward with small steps, not looking further into the future, for example, 3 months.
It is more convenient for many Clients to work this way - you see the result and correct the plan. For developers and testers this, of course, seriously adds hassle:
- It is impossible to keep up to date all the project documentation, screenshots, diagrams, TK - because after a short period of time, you will most likely need to make changes. Therefore, they go to the “trick” - they lead a less formal description of the system, for example in a wiki, without tracking dependencies between components , relying on the memory of colleagues :-)
- It is necessary to program / impose in such a way that making the expected changes is a simple, little risky process. And this means that a) you need to know and correctly use design patterns (and finding developers who know this area is not easy), b) you cannot succumb to the temptation and create a universal and expanding system in all places, since this will seriously increase the development time
- You need to be able to test this periodically changing system. Know where and what has changed, where it will manifest. Those. The load on testers increases - you need to describe changes, make changes to modular and integration tests, etc.
We see that, in an iterative approach, on the one hand, it became more convenient for the Client and, possibly, the project manager working with him, and on the other hand, the load on developers and quality specialists has increased, and the requirements for their qualification have increased.
A similar process can be organized both more formally ( RUP , etc.) and less formally . It all depends on the specific web project. Accordingly, you can use specialized software , but you can build everything “on your knees” (exelki, wiki, walls in leaves, etc.).
Aerobatics ... on the brink of chaos - Flexible process (Agile)
Currently, it is a rapidly growing website development process. The following is postulated:
- Requirements are constantly changing, because the market is changing, so writing, and even worse, changing and maintaining up to date detailed TK is a waste of time. Otherwise, you need a system analytics department, a design department and an architecture design department.
- Because requirements change, changes to the project will be made constantly, so you need to do everything so that it does not destroy the project and changes are made quickly and cheaply.
- The client or his representative should be constantly available and open for communication, answering questions of the project team.
- Developers and other participants in the project constantly communicate and exchange information, the bureaucracy is minimized, people are highly organized and act at the same time (no need to force them to work).
- A web project is released frequently, with iterations of 2-3 weeks. Visitors to the site take an active part in testing.
It is obvious that such a “flooded” one needs self-organized people in a team, professionals in their field and a leader supporting this super creative atmosphere from attacks of despairing bureaucrats, pursuing personal selfish goals, etc. Otherwise, with any cotton, everyone will again run to the office desks and will start throwing letters and suffer with letter-eating.
This process is very convenient for a result-oriented client, since A web solution can be changed and developed all the time, not lagging behind the competitors - otherwise the Client becomes a hostage of the TK, as he wrote a year ago, we will do so. If the team is strong with predictable performance, then the Client gradually begins to effectively plan the next releases of the web solution.
On the other hand, the technical complexity of the solution increases very drastically, since supporting a constantly changing system in a state of “technical health” (when you know that you can confidently develop it further, and the cost of making changes will not begin to grow exponentially) - the task is not for the faint of heart and requires highly skilled developers.
For quality management of such a system (often without formal technical documentation), an arsenal of effective techniques is used:
- Automated unit tests . Programmers create code that tests their code.
- Functional tests or automated acceptance tests - tested features and processes are tested.
- The release of the web project is quickly put into operation. Visitors quickly test the solution and in a short time it goes from beta to an adequate state.
- At all stages of production used checklists . The point is simple - there is no time to write and read multi-page manuals, in order to “survive”, you need to complete these points without asking unnecessary questions. Direct analogy with the combat regulations .
Obviously, because such a development process balances on the verge of “controlled chaos”, and otherwise the market often does not allow the market, a significant role in ensuring order and predictability belongs to the maximum automation of testing, supplemented by checklists (checklists). The system should be able to check itself and quickly identify critical errors - and also we should know what and where we need to quickly check (if it is difficult to automate) at different stages of production: from layout to operation under load.
The healthy evolution of this process usually proceeds according to the following scenario:
- In 2-3 weeks a new release of a web solution is designed and released.
- The experience of iteration (s) is analyzed and improvements are made to checklists at different stages of production.
- Part of the crutches set in the previous iterations - corresponded
- New modules of the system are covered by a grid of modular and functional tests.
Over time, the process of developing a web project stabilizes, making changes becomes “not so scary” - they are waited, the system is constantly updated, improved, relatively healthy, not only outside, but inside as well. There comes a phase of "effective world", which remains to be observed - because Any imbalance can reset production either into chaos, or stupid formalization and cost increases begin.
To consolidate success, reaching this level often introduces a cycle of continuous integration . To do this, you do not need to use specialized software , you can restrict yourself to a group of simple scripts and hot hearts of enthusiasts in the team.
More about checklists
We briefly repeated the evolution of web project development techniques (and not only the “web”) and saw that at present no one, as a rule, allocates enough time for the formal systematic development of systems (however, the waterfall and dependency matrices continue to be used in industries where the cost of a mistake is very high - when building houses, bridges, airplanes, when developing software for healthcare in the US, etc.), therefore, teams survive and fight fear using a limited set of highly efficient tools, one of which checklist.
Checklists are usually compiled by experienced staff, system and business analysts, functional managers. With the accumulation of intellectual baggage companies in knowledge bases, checklists are also developing and improving. The essence is simple - to save time and money by not allowing employees to involuntarily (and sometimes arbitrarily) step on the rake 2 or more times.
An example of an elementary checklist for a programmer:
- Understand what you need to implement. If questions remain, shake the analyst / manager / client to the finish.
- Think how to implement it. Do not rush to encode. Make a logical data model, a couple of three UML diagrams - reflecting both the logic and the behavior of the system.
- Check with the lead developer.
- Design database tables. Discuss with colleague / head of department.
- Think about how you will test the system.
- Remember the design patterns, maybe something of them is useful to you.
- Encode the functional, before or immediately while you remember to write unit tests.
- Unit tests must be run before adding code to the main repository.
- Describe the logic in the wiki.
Each item can be a link to the methodology in the wiki.
Nothing complicated, but how often many of these points are ignored.
And when it comes to checklists on preparing a web project for load testing or server maintenance ... There are so many important little things that are repeated from project to project. People often say that they remember them - in fact, experience shows that they do not remember, they miss important moments and are engaged in “stepping on a rake” from a project to a project, on the same thing, spending a lot of time. It’s not for nothing that experienced project managers close their stages / releases only if there are checklists-reports drawn up by responsible employees: from layout designers to system administrators.
Quality Monitor - in the Bitrix version 11
When developing a web project on the box platform “1C-Bitrix: Site Management”, you can use any of the above processes. This reduces the following risks:
- Developers do not need to have the “highest degree of dedication”: the ZCE certificate has a detailed understanding of the OOP and design patterns . All the most difficult is in the core of the platform, developed and tested within the company of Bitrix. A PHP programmer and layout designer need only have basic skills, minimal experience and complete training courses (you can get by in a few days).
- There is no need to update the system documentation, since The platform is described in great detail in the official documentation for both clients and developers. It is only necessary to describe the improvements / changes in functionality made with the integration of a web project.
- Testers do not need to test the entire web solution. The platform is thoroughly tested within the company. It is only necessary to test improvements / changes in functionality. This significantly reduces the time and risk.
Nevertheless, even working in such close to perfect conditions, if you do not comply with the known requirements for integration, you can turn a web project into chaos, which is extremely difficult and expensive to maintain and develop. Moreover, the lack of order in the code and architecture greatly demotivates specialists, staff turnover begins - which further aggravates the situation with the development of a web solution.
To protect the development teams from the above risks, a Quality Monitor is built into the platform from version 11.
To launch a web project release, it is necessary to go through automated and manual control procedures at all stages of production: from layout to deployment on a hosting or cloud and load testing.
Each test can be in several states, some of the tests, especially routine ones, are automated:
The project manager or developer, in essence, must “tree” the test tree for the release / iteration - by completing all the tests and autotests:
When the release is delivered, it can be seen on the desktop and the list of testing reports:
Especially I want to highlight the checklist for "advanced" developers. These items will be especially in demand in Aglle / XP teams that pay serious attention to code quality and architecture:
Development teams can add their mandatory and optional checklist items and autotests, for example, customize CodeStyle validation, correctness of integration with the version control system, UnitTests code availability and coverage, and documentation in the style of PHPDocumentor :
The fact of modifying the kernel and the platform libraries is also checked automatically:
Ideas for the future
Development, as a creative process, should be fun. Then web projects will not be born dead and scary, and it will be easier and more interesting to support them :-)
Checklists covering the entire development process on the Bitrix platform, expandable by the internal checklists of the teams - we did. This will seriously reduce the risks associated with a lack of knowledge and understanding of the platform and generally “good practices” and will allow teams at retrospectives to improve the process by adding new items to the Quality Monitor.
Many interesting tasks, including transparent and efficient integration with distributed version control systems ( Mercurial , git ), support for phing build tools, support for multi-stage development environments (dev, testing, stage, production), support for continuous integration systems, support for efficient work geographically distributed teams are actively discussed.
I sincerely hope that the “Quality Monitor” will allow teams to unleash their inner potential, focus on the creative process of developing and improving the architecture, will become a kind of knowledge base gained from retrospectives.
Regarding “settling down” in the mind of a winning strategy of ensuring sufficient quality of the site ... I am convinced that in allocating time for detailed design and formalization when developing complex and large web solutions (or refactoring / rewriting such systems), you need to fight, otherwise you will not provide quality and in production chaos will begin. For medium-sized projects, in the presence of an “open modern” Client, Iterative methodology is well suited. For smaller projects, Flexible Methodologies have proven their worth. Do not be afraid to experiment and go ahead. Good luck!
Source: https://habr.com/ru/post/132798/
All Articles