Test freedom

The modern world of software is very black and white divided into two camps: either you are an open source application or a closed proprietary one. No, of course, there are various licenses in open source projects and some kind of progress of closed products to put their parts in the open source (hi, Google, Facebook, Microsoft). But all this does not change the essence of the matter in principle - if you take an open product, then you see everything that is inside it, you can evaluate it and decide whether it is worth contacting or not. If you want to purchase proprietary software, then all that remains is to believe the sellers of the manufacturer who are pouring with nightingales, how everything inside is cool, reliable, fast and modern. Well, you probably were at some such conference or presentation, where a man in a suit went out and rubbed an hour about how things got better in version 18.1. 1 of their product and why you need to buy it right now. Often you can run a limited trial mode for a week, which will answer exactly 1 question: “how does a limited trial mode work for a week?”. The buyer always remains one-on-one with the decision to take and take risks or not to get involved. There is little objective data to make a decision. At the same time, it would seem that there will be no more of them - the manufacturer of the closed product will not post the source, since it is they that are of commercial value.

It would seem - a dead end? And let's consider the following thought - what if we demand we offer the manufacturer to put tests on its software openly? All that is - unit, integration, performance, others. At the same time, the manufacturer and the potential buyer receive a number of advantages.

1. The manufacturer shows that he has tests. It’s not that it said automatically that the product is good, but if there are no tests at all, it already with full guarantee says that the product is bad. Those. from the assessment “but the devil knows how who tested it there”, we proceed to the assessment “so that people seemed to be trying to test.”

2.The manufacturer does not open the source code of its product. Yes, tests can tell you something about the structure of individual modules and their interaction, but let's face it - the debugger and disassembler will tell no less.

3. A potential buyer can evaluate the quality of the test code. Yes, this is not the code of the product itself, but tests are usually written by the same people, in the same style, with the same attitude to style, quality of code, naming of entities, with the same thoroughness. If the buyer does not have the skills to evaluate the quality of the code, you can hire a third-party consultant for audit.

4.Tests may even be able to run. This, of course, will require some additional work from the manufacturer - removal of the code into separate isolated components, creation of additional moks. But tell me what's wrong with that? This approach encourages you to write good product code, which means it benefits everyone. Moreover, if the tests can be run on a real product - they can be used to diagnose errors, technical support correspondence.

5.Tests can possibly be expanded to fit your needs. For example, there is a test that checks the storage of 1000 documents in a database. And we need to guarantee the successful preservation of 100,000 documents. If you ask a question to the software manufacturer, you will hear or “yes, of course everything will work!” (if you get to the seller) or "I don’t know, they didn’t check on such quantities" (if you get to the engineer). Both answers are useless. If you have a ready-made test for 1000 documents, you can easily change its dimension and, having launched it, you will find out the answer to your question.

6. Tests may serve as product documentation. This is especially true for software that provides SDKs for developers. It is one thing to read boring documentation and quite another to take ready-made code, run it, start edit it.

7.The manufacturer can finally in the license agreement instead of the shameful wording “nothing is guaranteed to anyone at all” to write at least “passing the tests attached to the product is guaranteed”. This, you see, is much better than the cats in the bags that we are offered today.

8. The severity of collisions between opensource and closed source software will become less bloody. From the “partially open” software, the witness of the GNU sect will already have slightly less blood. Here, of course, a lot depends on interpretation and PR, but still a step towards it is better than current direct conflicts.

9.There will be something to talk about with users. Many marketing and PR teams are struggling to get an adequate feedback from users, pulling them into a conversation, trying to sell additional modules and technical support. Unfortunately, it is often necessary to start such conversations from a bare foundation, the conversation is not glued. And it’s a completely different matter when the conversation starts already substantively - with a failed test, with a request to add features, with a question about why here and here such parameters are passed to the test, and not such, “but where is this case checked? " etc ... When the conversation of technical experts leads to the localization of the problem or the need to develop a new feature - this will already be a good foundation for discussing the further deal.

Your opinion on the possibility of opening test code for proprietary software is very interesting.