As we all know, technology can be quite overwhelming. Tiers, layers, models, architecture, structure, scope, process and on and on and on… However, the fundamental building blocks that comprise the end product – like in science, nature, and physics – are quite simple in design.
It’s simply 1’s and 0’s folks. That’s it.
The complexity in any software solution is the architecture and technology that transforms the simple into the dynamic. In the end creating diverse, robust applications that can process an almost incomprehensible amount of information in seconds or fractions thereof. The creation of these solutions requires input and ingenuity from various BI analysts, developers and technologists.
Testing these large solutions relies heavily on automated testing. Unit tests & integration tests reside in the code itself and these test suites can be set to run on predetermined schedules such as during the daily build process. Automated GUI testing tools are used to drive the applications through use-case scenarios and can provide great coverage on the end product.
But how do we test as we go?
Unit tests are a product of the Test Driven Development methodology, where the developer writes tests against requirements before he begins working on coding for the feature. However, these tests are written by the developer to test his own work. It doesn’t allow for a second opinion or scrutiny from someone with a skillset outside of development (perhaps the person who wrote the requirements).
We adhere to standards and conventions throughout the Software Development Life Cycle (SDLC). Whether it’s requirements, development or testing, we strive to do things logically and consistently. The aim is to keep things organized, transparent and efficient, and to stay away from knowledge silos that have historically plagued the I.T. industry. These standards are available to everyone. They consist of visual aids and document templates but fundamentally they are simply checklists.
The checklist might be the oldest and simplest form of ensuring quality. The caveman who forgot his spear when he went out to fight the sabre-tooth tiger didn’t come back. Conversely, the caveman who checked to make sure he had his spear, that the stone was sharp and properly fastened, checked that he had a sharp knife-like stone in case the tiger ate his spear, etc. came back with supper, a new tiger skin jacket and was a hero until the ripe old age of 25. Checklists have been around forever, writing them down is just the latest evolution.