Lean Quality – High Quality, Low Price
Quality – What is it really, and how does it affect my organization?
To reach your quality goals you are going to need
- Excellent, rapid and fast feedback
- Superb, detailed discipline
Easy you think? Well it is a lot more that hides behind these two bullets.
A lot of people use the word quality daily, but very few stop and think about what quality really means. Everybody is striving for better quality these days, but very few have realized what they are actually trying to achieve. Quality is a measure of how well you fulfill the requirements and how well you fulfill the needs of the customer. The first part is easily measureable, but the second is very hard to measure. The reason being that wishes and needs differ from person to person and is not quantifiable. Do you have to trust your gut feeling to come up with a high quality product? No, you just have to deploy early verification and early validation (feedback from the customer). If you can do that you can at a very early stage have an indication if your product is meeting requirements and at the same time meeting the customer needs. To do this you might have to look at the product from a different perspective to enable several incremental deliveries. You cannot deliver something that is incomplete. By dividing the deliveries into increments you can plan deliveries of partial functionality of the complete system. This is called feature driven development where one or several features are delivered at the end of each increment. You need to consider at least value, risk and knowledge when deciding the order in which you are to release the features.
Requirements are often a problematic area for both development and test. Often the handover is poor or non-existing in traditional projects. Working in a cross-functional team enables you to get rid of this this knowledge barrier. Ask yourself why you write requirements! Is it to translate the wishes and needs of the end user so that you later can write tests? If that is the case you should think about getting rid of the requirements completely and start focusing on writing tests directly, which represents the needs and wishes of the end user.
Incremental development puts a lot of requirements on the architecture. You need to design a divisible systems architecture, which allows teams to work concurrently and independently on sub-systems that deliver critical feature sets. The architecture will probably change during the development as new knowledge is being built, which in turn requires refactoring of the code. This also implies that your test software has to comply with such requirements as well.
Before any software is deployed it has to have been tested. This is where you measure (verify) the quality of your software towards the requirements and evaluate it (validate) towards the needs and wishes of the end users. Be aware: The results from testing are related to how good you are at testing; the test quality. If you have a poor test quality, you are poor at finding bugs; you will only find a low number of bugs regardless of if the quality of the product is high or low. This holds true for any project regardless of how the work is conducted. In Lean development you have to be very quick at developing (testing included) and releasing features. To enable an even, high test quality you have to automate the testing to a very high degree.
What is important is to notice that testing in itself can never increase the quality itself. If you find a lot of incidents when testing, it means that you are finding incidents too late. Quality should be built in to the product directly from the start! Quality can only be increased by development, you can not test quality into a system. Building quality into the system takes discipline.
Different tools are available for supporting discipline. The Fine S’s is one such tool including the following steps:
- Sort (Reduce the code base)
- Systematize (Organize the projects and packages)
- Shine (Clean up)
- Standardize (Keep things clean)
- Sustain (Use and follow up standard procedures)
By implementing the 5 S’s new incidents and defects will be exposed.
If you want to move fast everyone has to know exactly what is expected of them and when. This also will have the effects that the quality will be even. It is important to make sure that the standards used are actually used in real life. They should also be challenged as there always is a better way to do things.
Mistake proofing is a way to make sure that things cannot go wrong. Every time a defect is found, find the root cause and devise to prevent similar defects from being introduced in the future. One way of mistake-proof development is to automate routine tasks. Automation helps you avoid doing things wrong. If something can go wrong, it eventually will go wrong. By automation you can get rid of this risk. Examples of automation are builds, releases, branching, installation…
Testing can be deployed to prevent defects! This is really the reason for testing. You can introduce test-driven development to enable this. If developers are involved in writing tests before starting to code this will enable them to write defect free code! Having developers and testers involved with writing the specifications in the form of executable tests to begin with will enable you to mistake-proof the translation process between specification and test. You can also (done right) get automatic traceability between specification and code.
Configuration management is another area that is key to succeeding with your lean initiative. You have to consider:
- Work in parallel
- Releases are small and frequent
- Release and development of feature sets can be parallel
- Refactoring is constant
Finally you are going to have to have continuous integration in place to enable fast feedback and prevent defects from being introduced.
Interesting article.
What hooked me most was the sentence:
“Ask yourself why you write requirements! Is it to translate the wishes and needs of the end user so that you later can write tests? If that is the case you should think about getting rid of the requirements completely and start focusing on writing tests directly, which represents the needs and wishes of the end user.”
This sounds wonderful and is possible to accomplish. What must be considered however is the readability of the requirements (in this case, the tests) in the long term. If you write the requirements directly as tests there is a risk the next time you look at them, say 6 months later, you will not understand what customer need these tests where all about.
What you could do is to write a short text what the user wish (the requirement) is about, then write examples to clarify the text. These examples can then be used as the actual tests.
I agree that this is a problem if you use old tradiotional tools. However tooldevelopment has recently enabled us with tools that make life easier. There are tools worth experimenting with too see if they suite you puposes. One practice you can try out is to use either of the tools Fit/Fitness or Robot Framework (open source). They support adding clarifying text and images to your test. These are actually stored with the test! Cucumber is another tool worth experimenting with. Cucumber uses “behaviour-driven development” style of specification: Given A when B then C. These Cucumber tests are actually readable tests and can be more suitable for your needs. Worth trying out. If you already have a testenvironement in place, you might want to investigate the possiblity of creating a wrapper to enable this type of syntax.
Currently these types of tools are used for Acceptance TestDriven Development (A-TTD). These types of tests are focusing on customer facing tests. It is very convinient if people with limited understanding of the scritping/programming language can make understand the tests (like product owners and users) as well as getting rid of the requirement specifications.