Periodically, throughout my work in the area of testing, I, like many of us tried to find as much information in their field, in order to facilitate and streamline the process of finding defects. It so happens that part of the testing of economic programs, in particular, 1C Company, the information I have, alas, is not found, no matter how hard they tried. Now, to get a certain experience, I want to share their experience and impressions. It’s about testing system based on 1C Enterprise 8.1, however, rigid adherence to the manufacturer there. For example, as far as I’m concerned, the Microsoft Dynamix AX many similar moments. I will say no more about the basic configuration, and the development of a configuration from scratch for a certain company’s personal requirements.
I have neither the desire nor the purpose of throw you the terms and schedules, so that I would try to explain the maximum available, assuming that the reader knows the basics of testing and has some experience in projects
Most importantly, in my opinion, it is to remember at least 2 things:
And not have to know a little, methodologists and analysts, too, do not get money for nothing and blindly believe in your holy intentions to optimize their offspring, aka TK, will not. In general, basic knowledge of pow. Accounting and the PLO you obviously do not interfere. Further discuss this further.
a) The selected base for testing.
If the development is on the basis of every developer has its own database, and 1C a working base (user) at all, that is a good chance to beg a place under its base, say TesterBase. Which will not be connected to shared storage configurations, it is we do not have to. If there is sufficient experience of the system, the base can be (and even desirable) to make clean, to create necessary to test the remains, documents, etc.
The overall essence of the idea is as follows. Developer after the implementation takes off you configure your database (*. cf file) with all the work done. This procedure takes 10 seconds and does not constitute a special complexity. After that, the configuration is loaded into TesterBase planned and carried out verification work.
What are the advantages of such an approach yields:
In general, plus the weight. There certainly may be some difficulty in the form of passive programmers, space for the database, additional time for the entire process, etc. But it’s worth it.
b) Automation. Indentation in the white box.
In fact, test automation 1C – a very dubious concept. Very different tasks, too rapidly changing, and 90% of cases require manual intervention. But something is still possible if you do not automate, or at least optimize programmatically.
Generally speaking, programming 1C seemed fairly simple task, it is easy to find information, a Russian font, in addition, it is always easier and more pleasant to learn, something to work with, and support next sitting.
Sometimes you have to interface to select something, something to count, which can not afford full-time and even tried and tested means. It was then, and opens space for creativity.
For example, according to TK, implemented treatment, which removes a certain kind of deal, say with the prefix "art". How much you have these transactions in the system? How many are marked for deletion? How much spent? What if more than 300000? Functionality to export to Excel does not, and could not contain it so much. Is not always possible to get answers to all questions, using only standard tools. Such problems are solved by writing a small treatments with a query or report. It is interesting, and useful, and gives some guarantees for this is the test.
Speaking of requests. 1C query syntax is almost identical to the usual demands of SQL, so that, having mastered them, you can be with certainty say that you own SQL, which will not be superfluous in your resume.
It is also quite possible to automate the creation of documents, handbooks. Very good goal is to automate reconciliation of balances.
In general, even a superficial knowledge of programming 1C certainly come in handy at work. See dimension of the field, check out the removal of any measurements of objects and many other tasks impossible, unless you are targeting in the configurator.
Study of other languages is at your discretion. If you have a lot to work with reports and documents (the OS), it can help the knowledge of scripting languages like Ruby or Python. I had practiced the Visual C + +, but realized that such a low level in my problems no longer needed. But it’s all up to you.
By the way, this year 1C released a software tool called Scenario 1C testing 8. True for those who 1C delivered in a base configuration and can not access the support site, it costs money. Therefore, to test it for me so far failed, but the described functionality is impressive. So, if there is a possibility, I advise you to look at this product.
c) Preparation of personal knowledge base.
Depending on the severity and complexity of the project often have to keep in mind the binding user interface for the technical component. The fact that the interface is called primitive "date", the implementation may be XRealPaymentDate, which is calculated on a tricky formula of various components, and a couple of months with hardly anyone remembers why such a formula. Quite often the name of that one logic can not explain, for example the field "Period" in the configurator called XActualDate and the same name is used in the TOR. In general, sometimes what is obvious now that becomes a big problem in the future.
Such things are best not to keep in mind, and write in a specially designated meste.Primerno in this format: Document Transaction Number field (the rest of papers *) typical in the configurator докCделка.ХКоличествоБумНом (sprSpravochniki.XAssetsID * Xdnom)
It is also useful to consider the order of different landings / downloads and other details, depending on the objectives and implementation.
Once again I want to emphasize the necessity of knowing the internal logic of the system. I am deeply convinced that a good tester should be at the level of the analyst on this indicator. Most problems can not be checked without going into the essence of the problem, no questions asked: "Why do they want?", "Is it possible to optimize something, or else implement it?", Etc.
In my opinion, this is not the best approach to business, thus we are harming ourselves and the project and personally.
For me personally, in the testing process, there are at least two joys: a defect detection and successful promotion of their ideas on the possible realization of the problem.
As for the first joy, then all is more or less clear. Although it is generally accepted that the performance tester is evaluated by the number of missed defects in the final product, I leave the assessment of leadership, and every bug found in my work is personal self-gratification and encouragement for further work. However I am not an evangelist in the area of testing, so that their faith will not pay anyone.
Proceed to the second, which is more relevant to the topic. In the process of development can be a lot of nuances. Sometimes the problem that began under the strict supervision of analysts, methodologists as time grows comments, lost relevance of some items of TK, etc., in short, the task falls out of sight of the powerful and left at the mercy of programmers and testers. In such circumstances, a tester, who has spent over finalizing the problem for many hours, sometimes in the course of affairs to a greater extent than the methodology in which the head is crowded with other things and tasks. And our sacred duty, in such cases to send them to the right path. Typical errors I would attribute: the discrepancy / contradiction previously promulgated problems, comments, inability to perform tasks in mind the peculiarities of the current implementation, etc. Someone may say, they say analysts and for what? But as I said earlier, the situation in the project are different, but for quality, virtually all cases, we answer – testers. And another reason to declare itself not hurt, but many, like me this is fun.
But all is not well and rosy as we would like for all of this is very desirable to have a number of specific skills, so we are taken seriously, or at least understand what we want. Actually, that’s part of what in this case we can not prevent:
Typically a bug report or feature report will consist of two conventional parts – the theoretical and technical component. Let me just say that plenty of references to TK (our main argument), and a detailed description of the source (database, version, document number, date, build options) to help avoid unnecessary proceedings and claims against us.
Each of us is working with some objectives, plans for the future. Perhaps someone is testing the rate of increase in the programmer or analyst, or to move towards quality, but in another area. In any case, I wish to advise or just less lazy, if you are currently doing is not "business of their dreams," or, if you like, then dig a little deeper and more involved in the life of the project.
I am convinced that in most cases, it will not go unnoticed and be justified in a larger size.
For example, this paper is a blueprint and my vision of the optimal organization of the testing process 1C, to which I continue to aspire, and what you suggest.