003 The methodology
https://bona-iqiniso.atlassian.net/wiki/spaces/BON/pages/59244635/003+The+methodology
Slide 1
Welcome to the Bona Iqiniso video tutorial on the Bona Iqiniso Methodology!
Slide 2
From the beginning when we started working on Bona Iqiniso, our intention was to describe a software testing methodology that could easily be integrated in any way of doing software development.
We also understood from the beginning that a new methodology (although there are no software testing methodologies), would need a strong guidance to lower the threshold to start following our methodology.
Because we took the decision to include a cognitive behavior approach, even before we started with the methodology, we also wanted the methodology to be incremental iterative, or based on continuous improvement cycles where every new cycle would build on the previous cycle, adding new practices.
Slide 3
To “hit a hole in one”, we knew that we had to have a great foundation for our Bona Iqiniso methodology. We knew we had to base our methodology on existing frameworks and methodologies, while emphasising the practices that we considered as important.
That’s why we used certain ISO standards and a lean, agile, scaled agile development framework as the basis for Bona Iqiniso, because these frameworks already have proven their benefit and therefore would lower the barrier to start using Bona Iqiniso.
Because we also chose for continuous improvement, we came to an approach based on capability and maturity.
Capability stands for knowing how to execute a practice, where maturity stands for knowing which, when and how to use a practice under certain circumstances.
Slide 4
Although using cognitive behavior as a starting point, will give a natural feel to the practices we suggest and also will support a way of learning these practices via continuous improvement, we do need to know the rules that makes from a bunch of practices, a methodology.
Based on the definition of methodology from the dictionary by Merriam-Webster, a methodology is a theoretical approach to a bunch of practices within a specific field of study.
Our field of study is software testing and our practices all are there for the benefit of software testing.
Next to the methods, there are principles. Associated to the field of cognitive behavior psychology, we have:
- Natural feel,
- Continuous improvement,
- Working task based by following a workflow based on context, concept, implementation, verification & validation.
Associated to lean software development, we have:
- People centricity. Putting the development team & customer front and center,
- Reduce any form of waste as described in Lean,
- Answer w-h questions,
- Quality based where we focus on people, product, process, project and productivity.
These are the 7 principles of Bona Iqiniso.
Slide 5
The qualitative and quantitative techniques are the subject of all the videos that follow and the complete set of video tutorials, examples, the tool, etc. creates the paradigm.
Slide 6
Because of the continuous improvement character of both Bona Iqiniso and the software development approaches we built Bona Iqiniso on, there is a cyclic life cycle with 5 phases: context, concept, implementation, verification & validation.
These 5 phases can also be found in the Kaizen improvement life cycle associated with Lean software development. It is also called the 5S improvement lifecycle, where the 5S stands for:
- Self Asses: determine the context of what you are doing
- Sort: determine the concept, or what a possible solution could be
- Sweep: based on the roadmap, the project planning, determine what functionality needs to be implemented and tested.
- Standardize: verification (test driven development) to implement the functionality
-
Sustain: validation (behavior driven, and acceptance driven development) to maintain there is no regression going into the next cycle.
-
- *
Slide 7
In the following slides I will show you the theoretical model of Bona Iqiniso. But before we start with that, just a moment of reflection. The definition of the word methodology in fact says nothing about the tools that can be used to support a methodology.
But, it is unthinkable that for a software development or testing methodology there would not be any tools. Reality teaches us that in a software development project there are between 3 and 7 tools that will be used for a variety of support. Project planning, defect management, configuration management, code repositories, etc.
This is a source of
- Over production: same information goes to different tools,
- Moving: data needs synchronisation between tools,
- Defects: copying data between tools is an error prone process.
These are forms of waste as defined in Lean and for now it is enough to know that waste kills efficiency. Since efficiency is part of productivity, it is counterproductive to what we want to achieve. Hence the reason to want a single tool to support Bona Iqiniso. Although not mandatory, it is strongly recommended to keep the number of tools to a strict minimum.
Slide 8
The theoretical model of Bona Iqiniso is there to explain why we do what we do. The theoretical model assembles all the above together.
The Bona Iqiniso methodology is characterised by a cyclic life cycle, where during each cycle a bunch of practices are executed. Because of their nature, these practices can be seen as processes.
A typical definition of a process contains the input and output products of the process, as well as an indication on who is the supplier for the process and who is the recipient or client of the process. This is, in a nutshell, the meta-model of Bona Iqiniso.
Does it cover all? No, not at all, but it should explain why we took the approach described in the next slides.
Slide 9
I mentioned before that we based Bona Iqiniso on existing standards and frameworks. Some of these standards, are ISO & IEEE standards handling life cycle processes (practices) for software and systems. The ISO standard 12207 and 15288.
ISO regularly reviews these standards and the last time they did this was in 2017. Bona Iqiniso uses the version from 2008 and although the 2017 has less core processes, there is no real difference between the 2 versions. Some of the processes are integrated in other processes and this to reflect the current popular ways of doing software development.
But, to explain the theoretical model of Bona Iqiniso and where it comes from, we must use the 2008 version. It is possible that later in the tutorials we will refer to these processes again and perhaps at that point we will be using the 2017 version. For Bona Iqiniso, both versions are interchangeable.
Even more, because we are not using all processes in Bona Iqiniso. Remember that we are describing a software testing methodology and not a software development methodology.
Slide 10
For Bona Iqiniso, there are 2 groups of processes that are important. Processes part of software testing and those processes that support the software testing processes.
To be honest, the process names used in the ISO standard 12207 of 2008 are a bit confusing or at least don’t cover the content of the process.
We could go deeper into each of these processes, but I think it is more important to just explain how we got to the theoretical model of Bona Iqiniso. We anyhow will be regrouping and renaming the processes to fit a software testing methodology.
A first step is to re-arrange the processes.
Slide 11
This way it becomes clearer what the workflow will be in the software testing process.
The 7 processes that form the core of software testing are related to topics like vertical and horizontal traceability, reviewing, acceptance criteria, preparing for verification and executing verification and validation.
The 3 supporting processes cover process assurance, problem solving and configuration management.
This, by no means, means that other processes are not important and not necessary. It just means that for Bona Iqiniso to be a software testing methodology, these processes are enough. Later on, discussing the practices in more details we will be showing the links to other processes.
At the top we have the software quality assurance process that we tagged with the words ‘vertical traceability’. purpose of the Software Quality Assurance Process is to provide assurance that work products and processes comply with predefined provisions and plans. This process is necessary to establish traceability between requirements and delivery planning (release/sprint planning), often referred to as “Vertical Traceability”. This also means that this process holds the description of the product being build. Some will call that a product backlog, but in Bona Iqiniso we call it the application board.
The system qualification process ensures that the implementation of each system requirement is tested for compliance and that the system is ready for delivery. This process is necessary to accomplish traceability between requirements and tests, often referred to as “Horizontal Traceability”.
The review process maintains a common understanding with the stakeholders of the product build. This process is necessary for software testing to determine the test basis, to clarify contradictions in the requirements, to fill in the gaps, to explain assumptions, etc.
The system qualification process together with the review process form the business domain pillar in Bona Iqiniso. Although horizontal traceability also covers the more technical part, we still consider it the business domain for the simple reason that the hook for these 2 processes is the business domain and what they need and want to be satisfied.
The software acceptance process assists the acquirer, the customer of the software to achieve confidence that the product meets his requirements. This process is necessary to accomplish “user Acceptance”. User Acceptance testing is often prepared and even executed by software test engineers. In the Agile methodology, users have the product owner as key stakeholder in the acceptance process.
The Software qualification process confirms that the integrated software product meets its defined requirements. This process is necessary to accomplish verification of the integrated product and verification of the integration of the product with other products. In software testing this is often referred to as system testing and system integration testing.
The software verification process confirms that each software work product and/or service of a process or project properly reflects the specified requirements. This process is necessary to accomplish test coverage. This process covers the test execution, the logging of defects and test reporting.
The software validation process confirms that the requirements for a specific intended use of the software work product are fulfilled. This process is necessary to testify the validity of the product as developed is suitable for its intended use.
Software acceptance, software qualification, verification & validation form the testing board in Bona Iqiniso.
The configuration management establishes and maintains the integrity of all identified outputs of a project or process and makes them available to concerned parties. With configuration management you also define each and every baseline for each sprint and/or release. Bona Iqiniso has a cyclic lifecycle and each cycle corresponds to a sprint and/or release, the baseline in the configuration management will form the roadmap.
Slide 12
In the previous video we discussed the basis of Bona Iqiniso and the fact that we have 4 pillars in Bona Iqiniso:
- Business domain
- Application board
- Roadmap
- Testing board.
In the previous slide we explained how we came to these 4 pillars, but …
To start with, configuration management is not a software testing process and yet it forms one of the pillars of Bona Iqiniso. That’s because we need to fit Bona Iqiniso into the software development lifecycle and the roadmap is the way to do this.
In contemporary software development methods all products are build iterative incremental. This roadmap uses the application board, business domain and testing board in a perfect symbiosis. It feeds on them, receives products form these processes, but also provides the glue between them.
Where there is testing, there are defects. Every product has defects. That’s the reason why we also need a supporting process for problem solving. These problems or defects should always be related to the business domain and may trigger a revision to be done by the business.
Last, but not least, the audit process assures that we covered our bases. Following a workflow or a process should build confidence in the way the product is made.
Slide 13
As mentioned, the processes just described are used in the Bona Iqiniso lifecycle and therefore in the software development life cycle.
The Bona Iqiniso principle that we have to work task-based, leads to all these processes defining a bunch of activities and tasks that led to the creation of the Bona Iqiniso Wheel.
Slide 14
In the next videos we will go into more detail, but for now remember that the theoretical model of Bona Iqiniso is based on 4 pillars.
There are activities supporting software testing and software development and there are activities that enable the testing and development of the product.
Slide 15
That’s how we derived the theoretical model of Bona Iqiniso from ISO standards.
Slide 16: Summary
Bona Iqiniso is a methodology for software testing. It has a cyclic lifecycle with 5 phases:
- Self-assess – context
- Sort – concept
- Sweep – implement
- Standardize – verification
- Sustain – validation.
The practices and/or methods of Bona Iqiniso find their origin in ISO standard 12207 and there we marked 10 processes as important for Bona Iqiniso.
The 7 processes that are needed in software testing:
- Software quality assurance, or vertical traceability, or application board
- System qualification, or horizontal traceability plus
- Software review, or static testing, forming the business domain
- Software acceptance, or user acceptance criteria
- Software qualification, or system testing
- Software verification, or test coverage and
- Software validation, or user acceptance. The last 4 form the testingboard.
The 3 processes that support software testing:
- Configuration management, or baselines that form a roadmap
- Software problem resolution, or defect management
- Software audit, or process quality.
In the next videos I will be discussing the 4 pillars of Bona Iqiniso in more detail. Please join me for 004 – The approach
Recent Comments