Testing Software Series: Integration/Smoke Tests

Tests in general, are overhead. A waste. Extra code to create. Extra code to maintain. Extra code to extend. They are only valuable to a business if they can be cost justified.

So the question begins, what tests can be cost justified?

This entry is dedicated to Smoke Tests/Integration Tests.

Smoke tests/integration tests ensure that your product is doing what it’s supposed to do, more from a customer standpoint or high level API (like a RESTful interface). If you added a new library/dependency to your project, they’ll ensure your product still works. If you upgraded a dependency, same thing.

These tests ensure you REMAIN productive, whether you’re first starting to build your product/API or trying to extend an existing.

IMHO, these are the most valuable tests you should have, they should be the most extensive, and hopefully, they are the first tests you write. Nothing says Test Driven Development (TDD) better than writing some high level tests on what you want to accomplish before you start. Before you start wiring up databases, before you break up your architecture into “Micro Services” or whatever the new hype will be. These tests make sure your SYSTEM works so it’s USABLE by the customer.

Now, back to the cost justification. Yes, they are a waste, but without them, your risk is much higher for shipping software that doesn’t work. So first, they act as an insurance policy, limiting some of the heavy downside/asymmetric risk to failed software in the field.

Justification number two. After some initial time to set up, they will actually speed up development. This is possible because 1) they keep you from having to manually test use cases again as you continue to extend/refactor the underlying code, and 2) they provide UP-TO-DATE documentation on how to use the code at a high level, so it you are splitting up work/separation of concerns, or have been away from the code for some time, the party adding onto the API can look at the tests, and know how to call the API/wire it up.

Justification number three. They remove the need for manually testing, and re-testing by a designated tester, or at least minimizes this workload. Trading a day or two of creating scaffolding/setup that can be re-used for other API’s/test suites, for a day or two of manually testing, is practically an immediate payback!

Overall, from a cost perspective, point one on insurance policy is probably somewhere between a few months to a year or two payback tops. Somewhere in that time frame, these tests are going to save you from the much added expense of handling large failure(s) that happen to customers, that then take tech support, engineering support (unscheduled, on-demand support), and customer frustration until the issues are fixed. Point two on speeding up development, the breakeven from this point alone is most likely a few days. A return of thousands of percent a year. Where can you normally make that from an investment? And the last point on removing need for manual testing. Immediate payback. Infinite return.

End of the day, I see no reason to NOT have these tests. These integration/smoke tests should be the first thing your setting up BEFORE YOU START creating a new API, as to maximize your return from the onset.

Testing Software Series: Overview

Software tests mean absolutely nothing to a customer. Software that works means something to a customer. Tests in general, are overhead. A waste. Extra code to create. Extra code to maintain. Extra code to extend. They are only valuable to a business if they can be cost justified. Do they enable quicker development? If yes, then they’d certainly justify. Do they help in extending software? Do they reduce risk, like purchasing insurance?

As with most things in life, there’s no clear cut answer, but rather a fuzzy ‘It Depends’, with many trade-offs.

Stay tuned to this upcoming ‘Testing Software Series’ for RTCritical’s stand on tests. How we plan to use, or not use tests, to help drive business value and control and manage our productive, low cost, sustainable software development.

Abandoned Ship

Made a large decision a week ago. I decided to abandon my 2 1/2 week excursion creating a Single Page Application. For those that aren’t familiar with a single page application, think Gmail on a web browser. Once you open the Gmail web page, you’re on it and you don’t leave it. It feels and behaves like a normal application running on your computer. When you click to open an email, it doesn’t reload the entire page. You can work on an email or two at the same time, while seeing new emails come in. Overall, typically provides a good user experience.

Single Page Applications (SPA) have been around for many years now. They’re probably considered to be the ‘latest hype’ when it comes to web development. In the end, I fell for it. I decided to create an SPA for RTCritical. Figured the worst that could happen is I abandon ship after gaining some additional experience with them using the newer React framework (actually using Re-Frame, a clojurescript framework that wraps the React framework). As it turns out, the max downside is exactly what happened. After a couple weeks, I stopped to reflect. Looked at my progress, analyzed the code I had developed (and I’m pretty meticulous about Clean Code). Realized that while I solved many of the hard issues up front, I still had MANY more features to add to the product, it was breaking browser history and navigation (still had to figure out how to get this working), and the code was so decoupled, thanks to Javascript and event processing, that it was hard to debug, hard to reason with, and unpredictable what would be executed next. And more, it was hard to maintain, and getting harder to extend. And that’s with me usually keeping things clean and well organized.

So after analysis, I decided to go back to the old school route of a Regular Web Application. Each tab you click refreshes the page. Each form you need to use, opens a new page. Certainly not the latest hype. Thought I’d give it a day or two, and see what progress I’d make this route, and then decide whether I should continue on with the SPA, or this new route.

Turned out, it was so much easier to develop the Regular Web App. It was just so simple, I thought I was going back to the basics. When it comes to a complicated world…simplicity has it’s merits!

Took around a day to re-arrange my code base. Created a new project specifically for the web app, where it will be decoupled from the Core backend server. Then, the next day, got in the zone and a full day of programming, had the main tabs/navigation for the site in place, and a data table in place for each tab that was pulling data from the Core Server through it’s API. Thought to myself…man…this was So Much Easier, and Faster! The code was clean. I could easily debug. Life is good. So I continued on this path, thinking the SPA is Out of Here! Trucked for 5 more days, and authentication is hooked up, forms built, additional changes to the backend Core Server’s API was made for more complex queries necessary for the Web App, and I have a half complete web app. Another 5 days on just the UI, and the web app will most likely be complete. The more features I add, the more I refactor commonality out of the code (into my own library/utilities), the simpler my code gets. Reflecting on performance, it’s outstanding! I love working with Lisp and macros for html generation. It gets compiled down, so at runtime, it simply concatenates a bunch of strings, with data from the database in between. Without database queries, from start to finish, it’s something like 3 to 5 milliseconds for page generation, on a Complex Page, with the JVM in debug mode. And that’s mostly all overhead of the server itself, and NOT my custom code creating the pages. So much better IMHO than using templates, then having to have caching systems for performance, etc. This route equates to very low memory usage, with very high performance. More with less. I love it!

Regarding user experience, the web application will NOT rely on a the user’s computer or iphone for computation. It will not have to download MEGA Bytes of data for this SPA to finally display. Instead, depending on the size of the environment for the database queries, I suspect an average of 200-500 millisecond response times with very large databases, perhaps up to a second. This is quick enough to where I simply don’t see it being an issue. In fact, when the browser reloads and the majority of the background stays the same, you only notice the part of the page that is changing, just like an SPA (at least that’s been my observation).

When necessary, I’m adding minimal javascript for additional functionality towards a Rich Internet Application on very narrow focused components. Like the data tables that need to be refreshed. You can simply choose from a dropdown how often you’ll want it the data to be refreshed, and after that amount of time, the browser will automatically refresh the page. Simple works. At least for now, at this stage of the start up! The future may hold something different, but our customers may just want other features prioritized instead!

RTCritical introduces new blog ‘Trials & Tribulations…’

Released a press release today, found here. Contents of the press release are below:

The new Software-as-a-Service company RTCritical, introduced a new blog on its website. The blog is titled ‘Trials & Tribulations of a Frugal, Country Boy Tech Entrepreneur’, and is located at http://www.rtcritical.com/intro-to-trials-tribulations-frugal-country-boy-tech-entrepreneur/.

It’s intention is to keep a log of the trials and tribulations as RTCritical journeys from the initial start-up stage, on through product release and past, allowing interested parties to experience the ups and downs of the startup, and what it will take to succeed.

The blog will be mobile friendly along with the rest of their website, providing for a great experience in or out of the office.

About RTCritical:

RTCritical is a Software-as-a-Service company founded in 2019, focused on helping clients manage their business critical systems. RTCritical is their initial and main product, that will provide Real Time, Cloud Based Monitoring & Alerting for their clients job schedulers and servers. Initially supported job schedulers will include Linux/Unix Cron, and Windows Task Scheduler. Supported Servers will include Linux/Unix and Windows Servers. Their product is currently in development. More details can be found at their website http://www.rtcritical.com.

Why a Software Business?

Out of the different industries, the software industry is one that fascinates me the most, due to the very quick scalability/growth potential.

A hard set rule is that a business can only grow to the extent it adds MORE VALUE to MORE CUSTOMERS. With most other industries, most things have to scale as you do this. For example, for a dental business to grow, it will have to scale it’s teeth cleaning specialists, and if enough customers, more dentists. More employees, more administrators, more office space, etc. The operations/overhead scales almost proportionally to the number of customers.

With a software company however, unlike most other industries, you can typically add more value to more people with very little additional resources.

The majority of the expenses are the initial development, ongoing development and maintenance, and sales/marketing. For a Software as a Service (SaaS) business, you just have to plug in more servers (if your software was designed to scale). This may equate to very little cost to scale besides purchasing another server, or paying someone else for their server, i.e. Amazon Web Services. Depending on your overall business strategy, the cost of server resources can be so small as to be considered negligible in comparison to the other costs of the business.

Then, if you focus on making sure your initial and ongoing maintenance costs are low by choosing the right software and people/strategy, your overall costs of the production/operations (ongoing development & maintenance) will remain low. That leaves you hopefully with much operating cash flow to spend with sales/marketing to drive growth, at levels that are for the most part unheard of in any other industry. Exciting, isn’t it!

Intro to Trials & Tribulations of a Frugal, Country Boy Tech Entrepreneur

Entrepreneurship is HARD.

Today’s world focuses on specialization. Specialization in health care..radiologist, or your nose and throat doctor for example.

Entrepreneurship tends to be the opposite of specialization.

Instead of honing in on a single discipline, you instead need a variety of skills to be successful. Financial, Marketing and Sales, Operations, Leadership, Strategy. Plus, probably the one discipline or idea that has you motivated enough that you’re willing to put significant resources into it (time and/or money), and for what. The dream. The dream of perhaps working your own hours, being your own boss, making significantly more money than you would by ‘working for the man’, retiring early. Whatever the dream, it comes at a high initial cost compared to a normal job.. The cost of diving into the unknown…

Life is a journey.

Entrepreneurship is a journey to the extreme..

Join me on my path, through the trials and tribulations of starting up RTCritical, a world class tech company specializing in helping clients manage their business critical systems.

Video Log #1 – 10-25-29 – Intro

First Video Log for RTCritical. This video log is meant to keep interested parties up-to-date with what’s being worked on at RTCritical, the life of an entrepreneur for a startup Cloud Based software company in the middle of nowhere Idaho. It’ll never be perfect, or even close to. Simply ad-hoc videos for interested parties. Feel free to comment. What you like. What you want to hear more about.

RTCritical introduces a new RSS Feed

Released a press release today, found here. Contents of the press release are below:

The new Software-as-a-Service company RTCritical, now includes a new RSS Web Feed on its website. Using standard RSS feed readers, interested parties can subscribe and receive updates from RTCritical’s recently added ‘Latest News’ blog. The feed’s URL is located at http://www.rtcritical.com/feed/. Their latest news web feed/blog will include status on new or upcoming major releases, when new features are beginning development, tested, and released into the software, important updates around bugs and bug fixes, and more.

About RTCritical:
RTCritical is a Software-as-a-Service company founded in 2019, focused on helping clients manage their business critical systems. RTCritical is their initial and main product, that will provide Real Time, Cloud Based Monitoring & Alerting for their clients job schedulers and servers. Initially supported job schedulers will include Linux/Unix Cron, and Windows Task Scheduler. Supported Servers will include Linux/Unix and Windows Servers. Their product is currently in development. More details can be found at their website http://www.rtcritical.com.

RTCritical introduces a new blog on their website

Released a press release today, found here. Contents of the press release are below:

The new Software-as-a-Service company RTCritical, now includes a new blog on its website. The blog is located at http://www.rtcritical.com/latest-news, and is to keep it’s clients up-to-date with its latest news. This will include status on new or upcoming major releases, when new features are beginning development, tested, and released into the software, important updates around bugs and bug fixes, and more. The blog will be mobile friendly along with the rest of their website, providing for a great experience in or out of the office.

About RTCritical:
RTCritical is a Software-as-a-Service company founded in 2019, focused on helping clients manage their business critical systems. RTCritical is their initial and main product, that will provide Real Time, Cloud Based Monitoring & Alerting for their clients job schedulers and servers. Initially supported job schedulers will include Linux/Unix Cron, and Windows Task Scheduler. Supported Servers will include Linux/Unix and Windows Servers. Their product is currently in development. More details can be found at their website http://www.rtcritical.com.

New Cloud Based Company RTCritical is On-The-Web

Released a press release today, found here. Contents of the press release below:

The new Software-as-a-Service company RTCritical, brought it’s initial website online today. They will provide Real Time, Cloud Based Monitoring & Alerting for their clients Business Critical Systems. Their website http://www.rtcritical.com will feature a unique web page dedicated to each system they’ll support. Navigation will be via many internal links, and nested menus that will provide for efficient navigation. Mobile friendly atop to lead to a great overall user experience, in or out of the office.

About RTCritical:
RTCritical is a Software-as-a-Service company founded in 2019, focused on helping clients manage their business critical systems. RTCritical is their initial and main product, that will provide Real Time, Cloud Based Monitoring & Alerting for their clients job schedulers and servers. Initially supported job schedulers will include Linux/Unix Cron, and Windows Task Scheduler. Supported Servers will include Linux/Unix and Windows Servers. Their product is currently in development. More details can be found at their website http://www.rtcritical.com.

RSS
Facebook
YouTube
LinkedIn