This article is a set of brilliant ideas curated from four articles with the first suggesting ten ways to build high quality into software,
Continue readingWhat does it take to Build In Quality?
Automation in isolation is more of a problem!
Automating test execution in isolation ends up being more of a problem than a solution. Any automation solution either to enhance quality and to improve test cycles should encompass the tasks across test discipline. Automation should be considered a lever to meet the business objectives and not an objective itself.
Continue readingDesign for Testability – An overview
T Ashok @ash_thiru
Summary
This outlines what testability, the background of testability from hardware, the economic value of DFT, why is testability important, design principles to enable testability and guidelines to ease testability of codebase. This draws upon five interesting articles on DFT and presents a quick overview of DFT.
Introduction
Software testability is the degree to which a software artefact (i.e. a software system, software module, requirements or design document) supports testing in a given test context. If the testability of the software artefact is high, then finding faults in the system (if it has any) by means of testing is easier.
The correlation of ‘testability’ to good design can be observed by seeing that code that has weak cohesion, tight coupling, redundancy and lack of encapsulation is difficult to test. A lower degree of testability results in increased test effort. In extreme cases a lack of testability may hinder testing parts of the software or software requirements at all.
(From [1] “Software testability” )
Testability is a product of effective communication between development, product, and testing teams. The more the ability to test is considered when creating the feature and the more other team members ask for the input of testers in this phase, the more effective testing will be.
(From [2] “Knowledge is Power When It Comes to Software Testability” )
Background
Design for Testability (DFT) is not a new concept. It has been used with electronic hardware design for over 50 years. if you want to be able to test an integrated circuit both during the design stage and later in production, you have to design it so that it can be tested. You have to put the hooks” in when you design it. You can’t simply add testability later, as the circuit is already in silicon; you can’t change it now.
DFT is a critical non-functional requirement that affects most every aspect of electronic hardware design. Similarly, complex agile software systems require testing both during design and production, and the same principles apply. You have to design your software for testability, else you won’t be able to test it when it’s done.
(From [3] “Design for Testability: A Vital Aspect of the System Architect Role in SAFe” )
The Economic Value of DFT
Agile testing covers two specific business perspectives: (1) enabling critiquing the product, minimising the impact of defects’ being delivered to the user. and (2) supporting iterative development by providing quick feedback within a continuous integration process.
These are hard to achieve if the system does not allow for simple system/component/unit-level testing. This implies that Agile programs, that sustain testability through every design decision, will enable the enterprise to achieve shorter runway for business and architectural epics. DFT helps reduce the impact of large system scope, and affords agile teams the luxury of working with something that is more manageable reducing the cost of delay in development by assuring assets developed are of high quality and needn’t be revisited.
(From [3] “Design for Testability: A Vital Aspect of the System Architect Role in SAFe“)
Why is testability important?
Testability impacts deliverability. When it’s easier for testers to locate issues, it gets debugged more quickly, and application gets to the user faster and without hidden glitches. By having higher testability, product/dev teams will benefit from faster feedback, enabling frequent fixes and iterations.
Shift-Left – Rather than waiting until test, having a whole-team approach to testability means giving your application thoughtful consideration during planning, design, and development, as well. This includes emphasising multiple facets such as documentation, logging, and requirements. The more knowledge a tester has of the product or feature, its purpose, and it’s expected behavior, the more valuable their testing and test results will be.
(From [2] “Knowledge is Power When It Comes to Software Testability” )
Exhaustive Testing
Exhaustive testing is practically better and easily achievable if applied in isolation for every component on all possible measures, this adds to its quality instead of trying to test the finished product with use-cases that tries to address all components. This raises another question, “Are all components testable” ? The answer is “build components highly testable as much as possible”.
However in addition to all these isolated tests an optimal system level test also should be carried out to ensure the End-To-End completeness.
Exhaustive testing is placing right set of tests at right levels i.e., more isolated tests and optimal system tests.
VGP
(From [4] “Designing the Software Testability” ]
“SOLID” design principles
Here are some principles and guidelines to can help you write easily-testable code, which is not only easier to test but also more flexible and maintainable, due to its better modularity.
(1) Single Responsibility Principle (SRP) – Each software module should only have one reason to change.
(2) Open/Closed Principle (OCP) – Classes should be open for extension but closed to modifications.
(3) Liskov Substitution Principle (LSP) – Objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.
(4) Interface Segregation Principle (ISP)- No client should be forced to depend on methods it does not use
(5) Dependency Inversion Principle (DIP) – High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details. Details should depend upon abstractions.
[SOLID = SRP+OCP+LSP+ISP+DSP]
(From [5] “Writing Testable Code” )
Law of Demeter (LoD)
Another “law” which is useful for keeping the code decoupled and testable is the Law of Demeter. This principle states the following: Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Each unit should only talk to its friends; don’t talk to strangers. Only talk to your immediate friends.
(From [5] “Writing Testable Code” )
Guidelines to ease testability of codebase
(1) Make sure your code has seams – A seam is a place where you can alter behaviour in your program without editing that place.
(2) Don’t mix object creation with application logicHave two types of classes: application classes and factories. Application classes are those that do real work and have all the business logic while factories are used to create objects and respective dependencies.
(3) Use dependency injection
A class should not be responsible for fetching its dependencies, either by creating them, using global state (e.g. Singletons) or getting dependencies through other dependencies (breaking the Law of Demeter). Preferably, dependencies should be provided to the class through its constructor.
(4) Don’t use global state
Global state makes code more difficult to understand, as the user of those classes might not be aware of which variables need to be instantiated. It also makes tests more difficult to write due to the same reason and due to tests being able to influence each other, which is a potential source of flakiness.
(5) Avoid static methods
Static methods are procedural code and should be avoided in an object-oriented paradigm, as they don’t provide the seams required for unit testing.
(6) Favour composition over inheritance
Composition allows your code to better follow the Single Responsibility Principle, making code easy to test avoiding class number explosion. Composition provides more flexibility as the behaviour of the system is modelled by different interfaces that collaborate instead of creating a class hierarchy that distributes behaviour among business-domain classes via inheritance.
(From [5] “Writing Testable Code” )
References
[1] Software testability at https://en.wikipedia.org/wiki/Software_testability
[2] “Knowledge is Power When It Comes to Software Testability” https://smartbear.com/blog/test-and-monitor/knowledge-is-power-when-it-comes-to-software-testa/
[3] “Design for Testability: A Vital Aspect of the System Architect Role in SAFe” at https://www.scaledagileframework.com/design-for-testability-a-vital-aspect-of-the-system-architect-role-in-safe © Scaled Agile, Inc.
[4] “Designing the Software Testability” at https://medium.com/testengineering/designing-the-software-testability-2ef03c983955
[5] “Writing Testable Code at ” https://medium.com/feedzaitech/writing-testable-code-b3201d4538eb
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.
Dissecting the human/machine test conundrum
In this article I dissect these the way we test as human and using machine and outline an interesting way how the role of human power and leverage of machines to do testing smartly, rapidly and super efficiently.
Continue readingThe Power of Geometry
A good running form, a great cycling geometry becomes essential to delivering higher performance with no increase in power output in running and cycling respectively. Applying this to the context of QA, it is not just the content of test artifacts like scenarios/cases, plan that matters, it is how they are structured/organized that is key to accomplishing more with the same or less.
This article outlines how structure(or organization) of elements plays a key to doing more with less. In the subsequent two articles on this theme, we examine in detail, the arrangement of product elements and test artifacts and how these aid in clear thinking to deliver high performance.
Click here to read the full article published in Medium
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.
Do brilliantly ‘right’ after taking a ‘left’!
T Ashok @ash_thiru
Summary
A logical ‘left brain’ thinking complemented with a creative ‘right-brained thinking’ results in brilliant testing. This is an amalgamation of forward, backward, approximate, visual, contextual and social thinking styles aided by techniques/principles using process, experience and great habits.
Testing is about perturbing a system intelligently and creatively shaking out issues that may be present. How do we know that all the issues have been shaken out is indeed a challenge. A logical thinking approach to identify good and erroneous situations is seen as necessary to justify the act of completeness of validation. It is also seen as necessary to be creative and use the context to perturb the system. Finally, injecting a dose of randomness to perturbation is seen as the final straw to being complete.
Testing is a funny business where one has to be clairvoyant to see the unknown, to perceive what is missing and also assess comprehensively what is present ‘guaranteeing’ that nothing is amiss.
Left brained thinking
‘Left-brained thinking’ can be seen as collection of forward, backward and approximate thinking styles using methods that can be well formed techniques or high order principles based on an approach of disciplined process, good habits and learning from experiences. Read in detail at Left brain thinking to building great code.
Right brained thinking
A logical ‘left brain’ thinking is essential to good testing. Right brained creative thinking comes in handy to go beyond the left, to enable us to vary the paths, discover new paths and improving outcomes. Thinking creatively is about thinking visually, thinking contextually and thinking socially, using pictures to think spatially, using application context to react, experiment and question and then morphing into an end user respectively. Read in detail at “It takes right brain thinking to go beyond the left”.
The right brain creative thinking comes handy, to go beyond the left. To enable us to vary the paths, discover new paths and improving outcomes. This is not to be misconstrued as random or ad-hoc, though randomness does help. It is great to start with a logical/organised thinking, add a dose of creative thinking and finish it off with random meanderings.
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.
Thinking Visually
nanoLearning on “Thinking Visually” using Sketchnotes from Anuj Magazine, Citrix.
The video of this smartbits is available here.
Ashok : As an avid visual thinker who uses Sketchnotes to communicate, please tell us the importance of visual thinking and how it can help us understand/think better and influence people?
Anuj : I think, one of the ways Visual thinking has helped me is to find a way to better stay in the moment and what I mean by that is when we are in the moment, we will be able to appreciate life even more than what it is. So, staying in the moment in one of the big benefits. While I don’t claim to be a big one, every artist seeks inspiration from life happening around them and the quest of seeking that inspiration itself is one that lets you live that moment better than in a condition without that, so that is one.
The second way visual thinking I believe has helped me is – One of my online friends is Tanmay Vora, a very good Sketchnote artist. One of the blogs that he wrote and that stayed with me, talks about one of the principles he follows – to consume less and create more. In essence, what he means by that is, people with all the revolution which has happened around smart phones are always consuming content. We can blame apps for it – in a way they have been designed to create that stickiness, but we are always in the consumption mode. What happens if we start eating lot of food? It shows up on our body. Ironically, consuming lot of content does not show up as visibly in our minds. We can feel our minds getting bloated up, getting overwhelmed with lot of stuff, but you got to catch those signals. So, in order to balance it out, one of the principles of consuming less and creating more comes into picture. How it helps the visual thinker in me is that if I read stuff, I try to restrict myself to reading good stuff, and whatever I read I have a kind of pact with myself that I will create something out of that, be it a blog, a sketch or some other consumable form. That really creates balance because you are not holding up information for too long and getting it to stale in your mind without it being put to the right kind of use.
Third way visual thinking has helped me is – I will tell you an instance where I had organised one of the sessions on quantum computing. As complex a subject as that is in today’s times, it was equally important for people to figure out how to explain it simple. So, one of the things that I had set myself to do in that session was to Sketchnote the session live. Eventually, it turned out to be a good summary and in doing so, I realised that Sketchnoting is helping me actively listen to the speaker. What I mean by active listening is that again I am not consuming the content for the sake of consuming the content. I am creating something out of it and also actively removing the noise out of the whole experience of listening. You can’t write each and every word in a Sketchnote, but you can write the key points and summarise it. I did present it to the speaker after the event. So, bringing in the ‘intention’ in the listening is one of the key traits that I learnt.
Overall, the main areas where visual thinking has helped me, is to be more aware, be more present in situations and listen intently and balancing that continuum of creation and consumption which is important.
Ashok: So what you are saying is it does help you certainly be more mindful, absorb better and obviously assimilate it and keep up with the most important things so to speak and do it very continually along with the person who is doing his job.
Anuj: I would like to add how will it help QA professionals.More often QA professionals find themselves in a situation where the bug reports, unfortunately still are considered as the key output. In absence of any innovation happening in creating new bug reports, they are again thought of as one of the predictable outputs from the profession. What if you create a Sketchnote out of a bug report? I think that might help people look into your bug with more interest and getting more motivated to fix them.
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.
CIO views on Quality
Summary
This article is about views on quality from CIOs curated from a list of interesting articles. It is felt that solution quality is one of the Top-3 challenge doing DevOps adoption with reducing technical debt as a key focus area for 2019. Some of the interesting views from CIOs are “there’s no way you can satisfy the demands of digital transformation without DevOps, Continuous Testing”, “address testing and ensure it advances your digital transformation initiatives rather than holds them back”, “can’t risk disrupting frequent deployment, this is where Continuous Testing comes in.”
Quality of solutions is a challenge during DevOps adoption
Based on Gartner’s 2019 DevOps Survey, ensuring the quality of solutions is among the top 3 challenges encountered during the adoption of DevOps. According to them,application leaders guiding a digital transformation initiative must make continuous quality the technical, organizational and cultural foundation of their strategy.
Many organizations are on a journey with DevOps, practicing continuous development and continuous deployment, yet a continuous approach to quality is often missing. Basic functional quality goals, is not sufficient to satisfy the quality expectations of the users, the business or the market. The growing pervasiveness of mobile, web, cloud and social computing scenarios has raised end users’ expectations for application quality. The notion of what constitutes superior quality has become much broader and includes overall user experience, quality of service (QoS), availability and performance, as well as security and privacy. It is no longer sufficient that the application just works. It must provide an optimised experience that leaves the user wanting to engage more and interact again.
Reducing technical debt needs increasing focus
When CIO.com asked CIOs “What are your top priorities for 2019?”, reducing Tech debt was 2nd most popular response. CIOs say reducing technical debt needs increasing focus. It isn’t wasting money. It’s about replacing brittle, monolithic systems with more secure, fluid, customizable systems. CIOs stress there is ROI in less maintenance labor, fewer incursions, and easier change. (Ref: https://www.cio.com/article/3329741/top-priorities-for-cios-in-2019.html)
CIO’s views on Digital Transformation
Here are some views from CIO on Digital Transformation, consumer expectations, and hence the changing expectations from testing.
Rajeev Ravindran, SVP & CIO, Ryder System, Inc.
“Oftentimes, when people talk about digital transformation, they are really talking about technology. For me, taking the company “digital” is both about technology and a mindset shift. As a part of this mindset shift, we are moving from an applications-focused environment to a product-focused environment. In our new model, we look at every application as a product that has a life cycle determined by a product owner, who is typically in a business function other than IT.”
“In IT, we are moving from a linear thinking perspective to design thinking, and we are moving from waterfall to iterative. The goal of these changes is to create a customer-centric culture, whether those customers are internal or external to Ryder. The customer centric culture along with a product mindset will help with operational efficiency and revenue growth.” (Ref: https://www.idgconnect.com/interviews/1502117/cio-spotlight-rajeev-ravindran-ryder)
Andy Walter (Procter and Gamble)
“I think Continuous Testing is going to be core to companies being able to dynamically evolve their structures, their M and A, joint ventures, all these types of areas. While we were doing the Cody divestiture, we started a covert project of “how are companies going to be structured in the future?” And there’s no way you can satisfy the demands of digital transformation without DevOps, Continuous Testing, and the speed and agility they enable.”
(Ref: https://www.itproportal.com/features/cios-share-why-software-testing-matters/)
Jennifer Sepull (USAA, Kimberly Clark, American Honda)
“I think the beauty of creating a DevOps model is that you have a powerful team that is empowered to really connect with the consumer. When those teams come together in that powerful way, and they own the entire end-to-end process, there’s opportunities for innovation. Application development and testing are absolutely critical to making sure that those innovations, or that connection with the consumer, can happen.” This means that you have to address testing and ensure it advances your digital transformation initiatives rather than holds them back.”
(Ref: https://www.itproportal.com/features/cios-share-why-software-testing-matters/)
Robert Webb (Etihad)
“.. I know that software testers can make the CIO’s survival rate higher—but they can make the company more profitable, make it safer, and help it grow faster. If they make your testing faster and get your new apps out there, you can be more competitive. And if they can do that while lowering costs, that’s remarkable..” “..Transforming testing is pivotal for accelerating how software is digitising the business.”
(Ref: https://www.itproportal.com/features/cios-share-why-software-testing-matters/)
Vittorio Cretella (Mars)
“We have to really understand how the user is reacting and how to achieve this optimal customer experience..” “.. To accomplish this, we need constant deployment. But we also have to ensure that deploying functionality daily or hourly always improves the user experience. We can’t risk disrupting it—so this is where Continuous Testing comes in.”
(Ref: https://www.itproportal.com/features/cios-share-why-software-testing-matters/)
Andreas Kranabitl (SPAR ICS)
“..I believe that the most important element in digital transformation is people. We cannot have people spending their time on software testing tasks that can and should be automated. There is much higher-level work to do. We need future-oriented staff, and we can’t afford to make them suffer by asking them to do needless manual testing.”
(Ref: https://www.itproportal.com/features/cios-share-why-software-testing-matters/)
Robert Webb ( Etihad Aviation Group)
“..Can you make my testing faster and get my new apps out there so I can be more competitive? Can you do that in a way that makes testing more automated and safer, and can you do that while you’re lowering costs? This is something that is very, very unique, and I think we all have a wonderful opportunity to be part of this revolution..” (Ref: https://www.tricentis.com/blog/digital-imperative-software-transformation-cio/)
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.
It takes right brain thinking to go beyond the left
Right brained creative thinking comes in handy to go beyond the left, to enable us to vary the paths, discover new paths and improving outcomes. Thinking creatively is about thinking visually, thinking contextually and thinking socially, using pictures to think spatially, using application context to react, experiment and question and then morphing into an end-user respectively.
Click here to read the full article published in Medium
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.
Left brain thinking to building great code
A logical ‘left brain’ thinking is essential to good testing. Testing is not just an act, but an intellectual examination of what may be incorrect and how to perturb them effectively and efficiently. This can be seen as a collection of thinking styles of forward, backward and approximate using methods that can be well-formed techniques or high order principles that is based on an approach of disciplined process, good habits and learning from experiences.
Click here to read the full article published in Medium
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.