What does QA apply to in the IBM i world? Everything.
One of the most interesting areas of quality assurance and software testing is understanding the differences between the two. The foundations of QA are applicable to any type of information technology application. Software testing is informed by the core of QA knowledge and is designed to be specific to the type of system, program, and need.
Another way to think if it is that quality assurance is the strategy behind the tactical practice of testing.
The concepts and principles in QA apply to any type of development or infrastructure. Starting with the system itself and testing hardware and the OS running it, we can start applying standards that will flow through the organization. As application development layers onto the environment, accompanied by all the nuances of languages and software lifecycles, specific testing becomes more crucial in day-to-day activities.
However, as different as these two areas are – administration and application development – the same QA principles apply to both. Static versus dynamic processes and analysis, specification-based (black box) and structure-based (white box) techniques, experience-based exploratory evaluations all feed into the testing protocols which ensure information technology infrastructure is healthy. Therefore the organization, planning, reporting practices embraced by ISTQB and the QA community support any type of testing initiative.
All this relates to the natural curiosity about specialties. While there are always professionals who get into more specific areas, someone who understands the foundations of QA can test just about anything.
Some of the areas getting attention recently are quite diverse. Security testing, especially “pen” (penetration) testing aka hacking, is getting a lot of focus. Upgrading to a new OS release or a new Power System is always going to be of interest because system of systems testing is complicated and can be intimidating. Implementing third party software, new development, maintenance testing, all need proper quality assurance. The foundations apply to everything and knowing which processes to apply when and to what degree is what makes being a “tester” challenging.
Now, all of this said, the real reason most people want to talk to me about testing is because it saves companies money. An excellent paper is “Software Defect Origins and Removal Methods,” by Capers Jones (Vice-President and Chief Technology Officer Namcook Analytics LLC). He talks about the role of QA and testing at every stage in the environment and why it’s necessary to have the right testing comprehensively implemented throughout the organization. The main premise is, “A synergistic combination of defect prevention, pre-test defect removal, and formal testing by certified personnel can top 99% in defect removal efficiency while simultaneously lowering costs and shortening schedules.”
What this means is that the need for QA is everywhere! And when it is done properly everything works better, cheaper, and more efficiently.
So many environments keep testing in its own little box and don’t try to see where quality assurance can have a symbiotic relationship with all the stages of the software development lifecycle. This can especially be true in agile environments where the focus is on limiting scope and exposure. However test automation and usability testing that should be developed in conjunction with each other – and it is very hard to design proper usably testing without understanding the organization. While working with the business process owners many QA specialists see concepts that will enhance their testing, and ways of helping add safety checks, or verification points into everyday tasks. One of the seven principles of testing is that exhaustive testing is impossible this is an excellent way of empowering the organization to become “test infected” and have their work product and efforts impact quality.
The reality is that everyone in the organization benefits from higher quality testing in information technology because companies are so dependent upon IT and data. It doesn’t make sense to keep thinking of quality assurance as any less of an imperative than any other technical specialty.
So look around your environment and think what you would like to know how to test more effectively. Or areas you wish were better tested before getting to your involvement.