The basic premise:
Computers answer questions by applying a set of logical rules to an input and calculating the appropriate output or result based on the rule set as currently defined in the software. Often the software takes into consideration the 'state' of the object or the 'state' of the system and bases some of its rules upon this state. Software applications run on top of an operating system which runs on top of hardware and talks to the hardware with a basic input and output system or BIOS.
Our nation runs on Laws. There are laws that constitute our government's basic structure (national and state constitution) which I view as our operating system.
The people of our nation are the hardware. The operating system uses the hardware to determine an output (a jury, a judge, a legislature, etc.) and communicates ideas through them by following the basic operations rules defined within the system. Roberts rules is one example of a BIOS level description of operations allowed within the system. When someone is accused of a crime (a violation of some rule within the system) the information is processed by using a judge and jury to temporarily store the facts of the case in memory and determine an output based on the rule set and the state of the person and the system and to take these operations by following the pre-defined procedures of the courtroom which are based on Robert's rules of order.
If you agree with the above analogy then keep reading.
In software development companies there are various stages of maturity.
A new company may have only a developer as a sole proprietor. The developer's invention or prototype may solve a single problem very well and most of the time is focused on solving a small number of related problems. Often the software starts with a goal or a problem statement in mind and the developer writes code to satisfy the goal or solve the problem. Once they verified that the "happy path" is solved, the software has met its goal and the software is presented to its market.
As software and companies mature they are often asked to solve more and more problems often related tangentially to the original set of problems. As the system gains "weight" or "inertia" they may discover that the solution to one set of problems negatively impacts another prior solution and has unintended consequences. It is at this stage that adolescent software organizations seek to employ "testers" or "software QA engineers".
(readers note: I am a software QA guy so this is where my perspective is applied to our nations laws and our system for creating them etc.)
If you are a software tester and understand the SQA lifecycle you can skip this next section where I define it for those not in our profession:
A software tester (or QA engineer, sometimes also called an analyst) is someone who analyzes and measures a system by conducting experiments, similar to how a scientist conducts experiments and collects data to either prove or disprove a theory. The theory(ies) that the tester is trying to validate stem from the requirements of the system which at some point are based on a goal or problem statement of the system's customer. The system under test is a solution that was created with the goal in mind (the code presented by the developer). If the code passes all of the tests designed by the tester (or if it doesn't pass, but the team determines that the items which failed are an acceptable risk) then the team signs off on the software solution and it is released to its customers as a "new version" of the software.
Most times when a new version software is released, it contains additional features or modifications to the previous version's features. If the tester was involved in previous releases of the software, it is likely that their test plan for the next version will include what we refer to as "regression tests". Regression tests are designed to ensure that any changes to the software don't have a negative impact on previous goals or solutions; that the software doesn't appear to "go backwards" in functionality or "regress" to a less-optimal state; that it doesn't re-introduce problems that the team thought were already solved in previous versions. Any tester worth their salt (and given enough time) will conduct extensive regression tests to verify that future versions of the software don't "piss off" a large group of the software's current user base due to previously solved problems creeping back in, every version of software they release.
Testing takes time. Time is a cost. Not testing has a risk.
Developers are incredibly smart (usually). They have good intentions (usually).
The more solutions contained in a single program, the more likely it is that the program's rules are complex. The better a program handles edge cases (outliers), the more "customized" it's rule set, and the more lines of code exist.
Keeping the rules of a program in your head while writing new rules for the program is difficult, and when the program is sufficiently large, keeping all the existing rules in mind while creating new ones becomes impossible for even the most brilliant humans (perhaps an autistic developer could do this but I've never met one).
Developers don't (usually) intend to create bugs (defects) in software. They are human. When young organizations are bitten for the first time (not just nibbled), is when they start to consider evolving and employing the skills of a tester to help them exercise the existing rules with various scenarios to ensure that:
1. The proposed solution actually solves the problem as intended (the goal is met)
2. Any related pre-existing rules still function and handle things in a manner that is still intended.
3. Nothing "bad" happens (or if it does, it's not so horrendous that users would switch to another product)
If a tester finds a defect - an unintended consequence to a series of events - they usually inform the team by way of a defect report as to the actions taken, the result expected, and the result that actually occurred. The team triages and decides the severity and prioritizes the defect against the other tasks remaining to be completed.
Testing and defect discovery can happen early (while the ideas of solving the problem are still being discussed and formulated) or late (after a solution has already been created).
If defects are found early, all that is required is for the team to change the way they think about the problem and create a better solution.
If the defect is found late (after code is written) it is more costly to fix. Developers have spent time creating code, if that code is thrown away and replaced, all of that time is lost. If the defect is deep, then any logical structures that were based on the underlying structure of rules found to be defective may also require changes. Therefore, the later in a product's lifetime that the defect is found, the more likely that other structures have been created which depend upon the defective structure, and the more likely that "fixing" THAT defect means "fixing" many defects (and subsequent regression testing of more features).
Now for the analogy:
The Constitution is our operating system.
Robert's Rules is our BIOS.
The people are our hardware.
The legislatures (state and national) "congress" are our developers.
The laws they create are the software product (or application) which runs within the operating system by using the hardware.
The executive branch (including police) are the error trapping system, the "Catch" part of a "Try Catch block".
The Judicial system is the "exception handler" and the test team.
- More thoughts on this soon, I need to get some work done -
No comments:
Post a Comment