Freedom to the tests

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, there are, of course, various licenses in open source projects and some moves of closed products to spread their parts into open sources (hello, 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 inside it, you can evaluate it and decide whether to communicate or not. If you want to purchase proprietary software, then all that remains is to believe sales managers who sell the nightingales, just like everything inside them is cool, reliable, fast and modern. Well, you probably were at any such conference or presentation, where a man in a suit came out and rubbed an hour about how everything got better in version 18.1.1 of their product and why you should buy it right now. It is also often possible to drive a limited trial mode for a week, which will answer exactly one question: “How does the limited trial mode work during the week?”. The buyer always remains one-on-one with the decision to "take and risk" or "not to get involved." Objective data for decision making are few. At the same time, it would seem that there will be no more of them - the manufacturer of a closed product will not post the source code, since it is they who 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 in open access tests on his software? All that is - unit, integration, performance, others. In this case, the manufacturer and the potential buyer receive a number of advantages.

1. The manufacturer shows that he has tests. Not that it automatically said that the product is good, but if there are no tests at all, it is already with a full guarantee that the product is bad. Those. from the assessment of "but the devil knows how to test it there" we turn to the assessment of "so, it seems, people tried to test something."

2. The manufacturer does not open the source code of its product. Yes, tests can tell 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 assess 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 the style, quality of the code, naming entities, with the same care. If the buyer does not have the skills to assess the quality of the code, you can hire a third-party consultant to audit.

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

5. Tests may be able to expand for their needs. For example, there is a test that checks the preservation of 1000 documents in the database. And we need to guarantee the successful preservation of 100,000 documents. If you ask a question to the software vendor, you will hear or “yes, of course everything will work!” (If you get the sales assistant) or “I don't know, didn't check for such quantities” (if you get the engineer). Both answers are useless. If you have a ready test for 1000 documents, you can easily change its dimension and, having started, you will find out the answer to your question.

6. Tests can serve as product documentation. This is especially true for software that provides an SDK for developers. It's one thing to read boring documentation and quite another to take the ready code, run it, start editing.

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

8. The acuteness of opensource collisions and proprietary software will become less bloody. From the “partially open” software, the witness of the GNU sect will have a little less blood on his eyes. Here, of course, a lot depends on interpretation and public relations, but still a step towards it is better than current direct conflicts.

9. There will be something to talk with users. Many marketing and PR teams are struggling to get adequate feedback from users, drawing them into a conversation, trying to sell additional modules and technical support. Unfortunately, it is often necessary to begin such conversations from a bare foundation, the conversation does not stick. And another thing is completely different when the conversation begins in detail - from a loaded test, from a request to add a feature, from a question about why such parameters are transmitted here and here, but not such “but where is this case checked at all? »Etc ... When talking to technical specialists will lead to the localization of a problem or the need to develop a new feature - this will already be a good foundation for discussing a future deal.

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