The One Best Practice of Testing
The Brooklyn Bridge

The One Best Practice of Testing

So this article is about the one best practice in the test realm. This practice is so strong that it will guarantee you defect free software. A practice so strong that you will have time for extra scope or you could release early. It scales to large and small projects, complexity is irrelevant, and safety and reliability are built into the process. This method is truly agnostic to all of this. It is called tUTM.

tUTM will actively provide Continuous Integration and Continuous Deployment at its third level, ensuring that you can deploy any batch of code to your customers on demand. Devops becomes automatic, without work or thought, and drives an inherent understanding of the customer’s needs — without the difficulty of translational conversations.

tUTM will drive down complexity to such a degree that it becomes irrelevant. And, because complexity is so dramatically diminished, interoperability becomes as simple as ‘plug and play’.

Architectural and technical debt are easily resolved, once identified the debt is dramatically reduced with each build. If you have a need to move from On-Prem to The Cloud it is as simple as making the commitment and checking a box.

Having difficulty catching errors in the code? This practice will auto-write your unit tests in multiple languages. Suggesting which tests would be the most impactful and relevant. And, each unit test will scale all the way through function testing, feature testing, system testing, systems integration testing, and system of systems testing — without additional cost.

Since quality is defined as fitness to use and purpose, if you feed a new purpose or use into the front end of this method it will automatically compensate for either the new use or purpose.

How do you know when you are ready to release? That problem goes out the window because you are always ready to release. Need to reduce your support costs — tUTM is your answer, there is no more need for support. 

Need to reduce the cost of ownership? Your clients no longer need to test how your solution will work in their environment — they simply click the ‘Accept Upgrade’ button and everything is done for them. No more Installation, Operational, Production, or Safety Qualifications, they are all built into the release.

I was amazed at the effectiveness of this new test method. 

the Unicorn Test Method is the best practice in software development today.

Then, I woke up from my dream, and the wisps of a best practice faded away.

There are no best practices, there are good practices and bad practices, with everything in between. There are general practices that are not going to help you, and practices that mature organizations use because it is a day that ends in a Y. But, there are no best practices.

Agile can help solve some problems, as can Continuous Integration and Continuous Deployment. DevOps will help you determine what is being used, what is working, and what isn’t. Automation can help your regression effort. Causality analysis can help you be better. Lean Six Sigma can help you with better processes. Customer involvement can help you build the right use cases and stories. 

Complexity is real, technical debt is real, interoperating with another solution requires real work and planning. Ignoring these realities will lead to failure. Oh, and failing is only acceptable if you learn from it — hell it is only acceptable if you can recognize that you did fail.

They truly can help, but if your problems were that cookie cutter that they are easily resolved by all of those ‘best’ practices then anyone would be able to solve your problems. 

This note is short and sweet. All I wanted to say here is that when someone is trying to sell you a unicorn, or the Brooklyn Bridge, maybe you should point a skeptical eye in that direction. Practices work, or do not work, based on an understanding of the problem. If you are having trouble merging code branches then there are several techniques you can try — but if your trying to merge branches across multiple products then don’t expect a single source merge solution to work. 

Identify the problem you need to solve, try a solution, keep it if it works, and toss it if it doesn’t. Do not be dogmatic in a process or practice — to paraphrase a Pirates of the Caribbean quote — ‘they are more like guideline than actual best practices’

要查看或添加评论,请登录

Brody Brodock的更多文章

社区洞察

其他会员也浏览了