004 The approach
https://bona-iqiniso.atlassian.net/wiki/spaces/BON/pages/59375639/004+The+approach
youtu.be
Slide 1
Welcome to the video that will explain the pragmatic approach of Bona Iqiniso.
Slide 2
Bona Iqiniso is a methodology and therefore a theoretical approach to software testing. It means that we needed a pragmatic approach to implement the Bona Iqiniso methodology in a project.
Slide 3
What can be more pragmatic than to take a software testing practice that starts with the business domain, the test basis and ends with the automatic execution and reporting of the tests. I’m talking about test automation. Anything we look at in the pragmatic approach will be suited for TDD or test driven development approach.
Test automation, however, is not the only testing practice in Bona Iqiniso and therefore it needs to be said that not all testing practices are equally important. This can have several reasons: no two projects are the same, personal preference, compliance to legal and corporate rules and many more.
It means you will have to prioritize, not only what to test how and when, but also which software testing practices to use and when.
Let me give you an example. One of the approaches that is my personal favourite is to combine risk based testing with which software testing techniques to use and how many test data to use. If you have a test item, which is a part of the product that is testable, and you consider it to be low risk. Why would you spend a lot of time testing this part and why would you spend a lot of time finding test data to test this part? If you make sure every branch in the code is tested with one set of data, that could cover a low risk test item. It is a completely different story if the test item would be high risk. In that case, you would want to cover as much functionality as possible and perhaps execute each test with 5 sets of test data.
Next to test automation and prioritization, Bona Iqiniso’s pragmatic approach is based on pre-defined workflows.
If you know what to do and when, you don’t loose time figuring out what to do? That, for Bona Iqiniso, is the definition of a workflow. A second thing you benefit from using workflows, is that you can start small and simple and gradually do more and more complex things when your team start to grow its capability and maturity.
For the record, capability is about being able to execute an activity or task to perfection, while maturity is about knowing when to do which activities and if necessary adapt these activities to the situation you are in.
Let’s dive deeper into the Bona Iqiniso approach.
Slide 4
Why did we choose test automation to build our pragmatic approach?
At first you could think that ‘doing’ test automation is more expensive than manual testing and you would be right. You need more formalism and structure and you need time to create automation scripts while you still will execute the tests at least one time manually.
Bad choice? NO!
All modern software development approaches use an iterative incremental approach, which is a fancy expression to say we deliver smaller parts, but each delivery adds to the previous delivery.
Such an approach means that you have to start regression testing, or like the french like to call it non-regression testing, much earlier and you will have to execute these tests in every delivery. This leads to an exponential growth of the time you spend on test execution.
Creating automated tests also means you will use a number of testing techniques to figure out the tests to implement. Your test coverage will improve and detection of defects will not be postponed to the moment your product is in an operational environment. Defects not only get detected earlier, they are also solved cheaper and showing your customers both defect reports and execution reports will grow their confidence. Note that psychologically, automated tests look more professional.
Although at first, test automation needs an initial investment, it takes more time than manual tetsing, there are a number of things that help us to keep this under control.
To start with, there are world-wide benchmarks on where the most common defects occur. GUI, webservice, server method, typos, boundary values, etc.
Secondly, we can use risk based testing to put focus on those test items that need testing the most.
And finally, we have a number of testing techniques that help us to translate business requirements into test cases and test data.
Slide 5
The beauty of test automation is also that it can be used on several levels of testing. It can be used to test code, but it also can be used to help business representative accept the final product.
Although highly suited for regression testing to test what was build in previous deliveries, it also can be used for confirmation testing, to test what is being build in the current delivery cycle.
Every type of testing that needs repeated execution of test cases, benfits from test automation.
Bona Iqiniso is based on test automation. Bona Iqiniso wants to be the engine and the fuel for software development. Hence, test automation is the fuel and engine for software development.
This is embodied by TDD, or test driven development, BDD, or behavior drive development and ATDD, or Acceptance test driven development.
Slide 6
In software testing there are 2 parts that play a role. Verification and Validation.
Verification is all about verifying that the product being built is according to the specifications, or requirements.
An approach in test automation is to apply a number of testing techniques on these requirements and from there define the automated tests and test data. Implementing these automated tests and executing them will make all tests fail at the beginning. Developers will take these tests as the basis for their code, making sure that all tests pass, hence the term test driven development.
Validation is all about validating that the product built is what the business representative intended the product to be.
Business analysts work towards this by describing certain behavior according to the input of the business representatives. They will define a number of examples describing the intended behavior. These examples can be translated into test scripts. Where the TDD scripts are low level and go for the details, the BDD scripts tend to be a bit higher level, perhaps not yet end-to-end, but certainly touching a number of the functionality covered by the TDD scripts. Where TDD aims to cover the smallest unit of functionality almost 100%, BDD only covers a small portion of it. So, why define BDD scripts? Because it integrates a number of smallest unit of functionality into a test flow. Focusing on integration.
Unfortunately, BDD scripts are often not end-to-end and tend to be NOT enough to support acceptance of the product under test. For this we need to go back to the business processes. End-to-end workflows that mymic what a user would do.
There are 2 ways to approach user acceptance. The first way is to create end-to-end test scripts that cover the business process. A business representative can validate these tests. Executing these tests and making them pass then stands for ‘acceptance’.
A second way is to let a business representative execute tests manually, register the actions he does and from there create automation scripts.
The manual testing than will lead to acceptance, but the automated scripts at least can be used in all the next delivery cycles to regression test what is already validated and thus ensuring the acceptance testing is limited to the content of the current delivery.
Slide 7
This 3-step approach corresponds with the Agile testing quadrants.
For verification we try to automate as much as possible based on smallest units of functionality and examples describing the workflows in the product.
Acceptance testing will be more about manual testing, but automating these scripts leads to a good way to describe regression tests.
Validation is also about compliance to a number of non-functional requirements. Also there test automation can help.
Slide 8
Verification, the left side of the testing quadrant is tested by automated test scripts for the majority. Most of the automation is done for the smallest units of functionality and most of the manual testing will be on the level of GUI testing.
Therefore the Bona Iqiniso approach is to test the smallest units of functionality as much as possible with automated tests and the end-to-end tests, the GUI tests, with manual testing, but use the manual scripts to automate them to build a regression pack. In any case, you will use test automation techniques to describe test, because in the end you will automate all testing.
Slide 9
Combining the above together we have what we call the testing board of Bona Iqiniso.
Note, that even if you use a waterfall model for your software development, the agile testing quadrants still have value. Only difference could be that test automation for regression testing, could be omitted, because of the big bang delivery model of the waterfall development methodology.
Slide 10
The testing board is one of the four pillars on which Bona Iqiniso is built. But how do the other pillars fit in?
The business domain is everything related to the business vision, needs, requirements, business rules and so on. That is what is used by some the testing techniques, that will translate the view of the business into test cases and test data.
Another way to translate the view of the business is to map it to the application board. Mapping the business view to test cases and test data will almost certain lead to mapping the application board, features and stories, to test cases and test data.
Whether we deliver waterfall or in an agile way, each delivery, sprint or release, is mapped to the roadmap
Mapping the business view and the application breakdown to a roadmap, will also map test cases and test data to the same roadmap.
That’s how all four pillars in Bona Iqiniso work together.
Slide 11
Although the name ‘business domain’ suggests that this must come from the business, Bona Iqiniso doesn’t stop there. For Bona Iqiniso, the business domain is the result of the process transforming the business view into verifiable, validatable, testable chunks. This can go from the business vision to fragments of code.
In the first steps of that process we will transform the business view into test cases that form the basis of the user acceptance. Under normal circumstances, the business analyst must finalize the acceptance criteria. He, or she, also needs to jump-start BDD and TDD.
More technical people, will elaborate on the examples defined by the business analyst and finalize the BDD test case and test data.
For the TDD, it will be the developers that finalize the test cases and test data for TDD.
Slide 12
A similar approach is followed for the application board. Business representatives and business analysts will define the epics, features and user stories, covering all of the functional requirements and some of the non-functional requirements. More technical people will translate these requirements into a solution, based on the chosen architecture. They will figure out which functionality is specific, one time use, or common, multi-use.
Final step are the developers creating the basic methods, functions, services, etc.
Slide 13
Bona Iqiniso is about software testing and in software testing it is important to know what to test, how, when and where.
Test coverage is a term that represents how well you tested an application (application board) by measuring the coverage of the business requirements (business domain) by the executed test cases and test data (testing board).
Slide 14
That is the workflow of Bona Iqiniso.
- Define the application the application board
- Create a test basis based on the business domain.
- Use testing techniques to transform application board and business domain into the testing board.
- Apply a roadmap to deliver the application in an incremental iterative way.
- Report the test coverage putting emphasys on the functional coverage of the application.
Slide 15: Summary
The pragmatic approach of Bona iqiniso is based on:
- Test automation
- Prioritization
- Workflows
Test automation is categorized in:
- ATDD: acceptance test driven development
- BDD: behavior driven development
- TDD: test driven development
The Bona Iqiniso workflow is:
- Define the application board with epics, features and stories.
- The business domain forms the test basis.
- Testing techniques transform application board and business domain into the testing board.
- Apply a roadmap to deliver the application in an incremental iterative way.
- Report the test coverage putting emphasys on the functional coverage of the application.
In the next video we will learn more about the application board. join me for 005 – The application board
Recent Comments