Systems Analysis & Testing
How I learned about Quality Assurance from the most unlikeliest of places
Systems Analysis in a nut shell
Wikipedia defines Systems Analysis as “a problem-solving technique that breaks down a system into its component pieces, and how well those parts work and interact to accomplish their purpose^.”
A system is basically any simple or complex thing that is composed of a subset of components. And those components are similarly composed of subcomponents .. and so on. A system can be anything from a microorganism, to a tree, to anything in the known universe.
At the heart of systems analysis is documentation. Lots and lots of charts, Unified Modeling Language diagrams, Use-case diagrams, Business Requirements Diagram (BRD), and Functional Requirements Diagram (FRD), to name a few. The input is a response to an action (ex. a feature enhancement, or new product). The process is thorough analysis(cost-benefit / feasibility, etc.) to produce a comprehensive suite of documents that helps articulate the most complex of features in a simple manner to arrive at an efficient and expedient solution.
In my experience, I have found the FRD and Use-Case documents super-helpful in formulating a comprehensive understanding of how the system under test should work. Mind maps help as well, but we’ll talk about that later.
A functional requirements diagram (FRD) leverages the information found in the business requirements and user requirements diagram to compose a set of expected functions for a system. I’ll discuss this further, but the list of expected behavior can be broken down to the following (non-exhaustive):
- Functionality
- Usability (UX/UI)
- Reliability
- Performance
- Scalability
- Accessibility
- Security
Think of the use-case diagram as a noun-verb illustration of an interaction between a user and the thing they are using. Example: customer creates account.
This type of document helps define the following, expressed in:
- Who the feature is for (actor). — the customer
- Interactions of the actor with the system (use-case) — creates account
- The outcome of that interaction — account created; unique identifier assigned to user; authenticated in system
The FRD breaks the Create Account action down into a series of steps the actor takes and the system’s response (expected result).
You can read more about use-case diagrams: https://www.geeksforgeeks.org/use-case-diagram/#1-what-is-a-use-case-diagram-in-uml
Systems Analysis + Testing = A winning combination
For the purposes of this discussion, we’ll consider a bicycle as a simple machine comprised of subsystems, each having their own purpose. These subsystems will most likely have components made up of smaller parts.
Let’s imagine a scenario where we, the Quality Assurance Analyst/Engineers, are tasked with testing a bicycle. Our scope is limited to riding the bicycle on the street, in the fall, with pristine road conditions (no potholes, slick surfaces, or other impediments). How shall we proceed with testing?
Let’s imagine our bicycle as a series of systems that will be improved separately:
- Transmission — how the user regulates speed
- Locomotive System — how the user rides the bicycle
- Braking System — how the user stops the bicycle while in motion
- Steering System — how the user steers the bicycle
We can deconstruct each of these systems down into their base components. Let’s take the locomotive system and break that down to it’s components based on user interactions:
- User steps on pedal
- Pedal turns the drive train
- The drive train spins on the axle
As it applies to testing, we can challenge the notion that when the user steps on the pedal, the pedal can sustain the weight applied and not break off by applying a battery of stressors. Test passes when the pedal remains intact and can tolerate up to a proposed weight limit (within reason).
We can sit on the bicycle and test that when I step on the pedal, the drive train turns and is not too stiff or too lose. It should engage the transmission and rotate, causing the gears on the rear wheel to turn, moving the rider forward. Test passes when a full rotation of the drive train is complete with nothing impeding forward progress.
We can apply this methodology to all other systems of the machine, in the case our bicycle, and derive a series of tests that address each of the expected behaviors as expressed in the FRD.
Which brings me to the greatest bit of knowledge I gained from systems analysis that I use to this day.
F.U.R.P.S. — The mnemonic I use consistently
I got my start in Quality Assurance with zero knowledge in any testing methodology, understanding oracles, or knowing browser behavior. What I did have is a foundational understanding in web development, project management, and security / compliance familiarity. What I also had was foundational knowledge gained from one of may favorite classes — Systems Analysis. Had I known about this class from the start of my computer courses, I would have made it the focus of my studies.
But I digress.
I leveraged the one major piece of information that was in the “quality” section of the course. The mnemonic is F-U-R-P-S (as outlined earlier). This mnemonic is how I derive all my testing scenarios. I use this structure to formulate the positive, negative, boundary, and exploratory test scenarios (to name a few). It helps put me in the user’s mindset as to what I should see happen, but also helps the tester side of me by formulating non-compliant behavior scenarios and tactics; do the thing the user wouldn’t do.
My on-the-job training consisted of taking the FRD, usually a story ticket in the project CMS, and understanding the “why” of the feature. Why are we adding the bit of functionality? What benefit is it serving? Understanding the why of the feature dictates the best approach (the how).
Using the example of the bicycle, namely the pedals, we get a story to test that states we’re upgrading the pedals to be wider, made of carbon-fiber, to address concerns regarding weight and tall people with larger feet.
We can imagine a scenario for upgrading the pedal on the bicycle with tests like:
- The pedal is of an adequate size to accommodate large feet (the happy path) but not too big to be cumbersome to the rider
- Given the choice of material, the pedal is esthetically pleasing; keeps to the theme of the bicycle
- Given the choice of material, the pedal is slip-resistant
- Given the choice of material, the pedal is weather-proof and will not rust
- Given the choice of material, the pedal is durable and will not break on impact with hard surfaces like concrete, rock, or metal
- The pedal remains weight-tolerant to within 500lbs.
The sky is the limit on what other tests can be considered.
Conclusion
My point to this whole thing is that the mnemonic is the scaffolding I have been using since my first day of QA to test the web and mobile apps I’ve been assigned to. It was the mnemonic I learned in my Systems Analysis class. A class that has served me well on numerous occasions to help break down the most complex ideas and features into their most basic components and subcomponents. Understanding the parts helped me understand the whole thing.
Testing each of the subcomponents (unit testing), and how they fit into each other (integration testing), as well as the totality of the whole system (system testing) is how I learned to really understand QA. I don’t always get it right, but I always get it done!
ciao for now
___
^System Analysis and Design for the Global Enterprise by Lonnie D. Bentley p.160 7th edition
