(In this SmartBits, Anuj Magazine outlines “ On Career Growth “. The video is at the end of this blog)
Career growth can be divided into two
buckets. One is the nonlinearity aspect
of the career, and the other uni-dimensionality. One of the things found common
in most reasonably sized organisation is that each and every organization has
career paths and the way the career paths tend to get designed are that there
is an entry role that one gets into post college and then there is a role at
the top.
The role which is essentially at the
top of these ladders are of a VP or a Department Head. Looking at these career paths, the highest
designation in the organization is that of a CEO, if we associate these two
logically, we will tend to think why organizations do not give a path till the
CEO role in the organisation. This led to the question on the linear approach
of following the career paths, that are
designed in the organisation.
Mark Templeton CEO of Citrix for
around 20 years and quite respected in his field said that career paths up to
the top in the organisation rarely tend to be linear, they always zigzag. One
needs to figure out where the next dot is, to move forward. This questions the
rationale behind the linear careers. There is nothing wrong having a
predictable career path. It does help to solve a problem in the organisation.
For instance HR wants predictable processes, even employees want them too, and
there is nothing wrong with that, as not everyone wants to be a CEO. But there
are other merits to following a nonlinear path.
The second part is on the uni
dimensionality, let us take example of startups, .When the startup is new and
the product market fit is not achieved, people play different roles being in
one designation such as marketing, coding, testing or they may be hustling
around and doing sales. In early stage organizations, one can afford to be a
specialist in the interest of moving the organisation forward, but when it
comes to scale, the uni- dimensionality, the specialisation matter, of having a deep knowledge of one subject or
maybe a related set of technology help scales the organisation and go to the
next level.
Should I be a generalist or a
specialist? If you want to be a specialist, choose a field that is going to be
relevant in the time to come.The people who chose artificial intelligence and
machine learning fifteen years back are reaping the rewards of that. In IPL we
see around 200 odd cricketers from India in that competition, which is hardly
around two to three percent of the cricket playing population or even less and
these are like hyper specialised individuals who specialise in their areas.For
choosing a specialised field it is better to have the conviction to be in the
top ten or twenty percent so that one can reap the rewards in the time to come.
Generalists are people who are more adaptable, who can learn a new skill in a shorter time and deliver value and it is more akin to the gig economy. Pick up the rules for some time and then move on to something else. There is nothing wrong in both of them. Both have its merits and demerits. Hyper specialisation is going to be the thing in the future.
The QA profession has been under pressure from external forces, as decision makers in organization want to see more value. It comes to more of an economics decision, that we always called as cost of quality, we never use the term profit of quality. We need people who can represent QA in a boardroom where value can be showcased, and that is lacking at the moment.
(In this SmartBits, Tathagat Varma outlines “What is Agile?“. The video is at the end of this blog)
Software is a problem-solving process, where we are trying to take a shot at how we should be solving the problem. What is the best way of solving the problem? Looking at the philosophical element, a software is a way in which we are encoding a problem, solving from a given point of view. A designer would think of a particular way to solve the problem and encoding that in a medium. Software is only a medium. It could have been any other medium for example , in which a problem could be solved.
What is the right way for us to solve the problem? Should we have a world view which is based on ‘we-the-designer’ or should we have a world view based on you as a ‘we-the-consumer’. If you are the customer who is the real consumer of that? This needs to be understood.
Philosophically the first most important thing is to understand we are not building software for ourselves or for people like us. We are building software for a given audience and we need to be mindful and respectful of how they solve the problem. The philosophical element is really about, whom are we building for and are we mindful of the fact that this is how people solve the problem.
The mindset is the way, where we take the next step forward, where we say that now that we have understood the world view from how people look at it, how do we really solve the problem. Should we wait for a fully baked way of doing it. The basic idea is we cannot solve the problem in a single pass.
Every complex problem is best solved in a very iterative manner in a very collaborative way in which do not treat our consumers as just passive consumers i.e whatever we dish out to them, they will accept it. Even without the software they are solving the problem day in and day out which means they have some wisdom about how a good solution should work out. If I partner with them and treat them as a co-creator rather than a passive consumer then I can actually create a better solution. Mindset is all about stating that they are not passive consumers, they are co-creators, they are our team, so we start teaming up with them.
The Agile mindset very simply is something that we keep borrowing from the work from a Stanford professor Carol Dweck. She wrote this book on mindset where she talked about fixed mindset vs growth mindset, where the whole idea is that some people have a fixed mindset- this is the only way this should be done and have a very strong point of view. They are not willing to budge from that opinion. Then, there are people who think maybe there is a better way of doing it, maybe there are other ways in which we can grow, we may not succeed in that but in the process of doing it, will stumble upon the truth and that will help us eventually get to the right solution.
Having that kind of a mindset where we are open to experimentation, open to learning, willing to take some meaningful risk, not scared of failure, willing to keep iterating over is the need of the hour. We need to have a culture that really supports these kinds of mindsets. This is the third aspect here. In organisations where making mistakes is a considered sin, where an individual gets reprimanded for failing, Agile thinking will not work. Agile demands tolerance for intelligent failures. We need to have an appetite where we can say this person made a mistake. let us have a small party, let us learn from that person. If it is a great mistake we make a big deal out of that.
That Agile mindset will not fit into a very conventional kind of a culture where people say do not make any mistake, do everything right the first time, everything has to be Six Sigma. A very nice quote by a management professor Gary Hamel, where he said thank God for the biological screw-ups, if not for that we would still be slime, because in a Six Sigma world, evolution would not have happened, if animals did not genetically recombine with each other in novel ways.
If we are really looking at very creative ways of doing things and are looking for finding some novel solutions to that, one has to have a tolerance for bringing the Agile mindset into the workplace. Agile mindset is like the seed that requires an Agile culture as a fertile ground, otherwise it will not sprout. Tools, methods and processes are the fourth and the fifth-order extensions, because in order for us to do the job properly we need the tools. Unfortunately people get it totally wrong, they ignore the holistic part of why we are doing it, the whole philosophical element, the mindset and culture, they straight away jump onto tools and methods bandwagon, because that’s the easiest thing to sell. The tools, methods and processes are the fourth and fifth order functions of the core thing but the whole idea is if we don’t start on some of these basics, we will never get to the point. If we start only with the tools, it might give a short-term win but then it’s not sustainable and definitely not be scalable in the long run.
(In this SmartBits, Girish Elchuri outlines “Build in quality“. The video is at the end of this blog)
One of the important things we have to remember is that we can not add quality. Adding quality is not similar to painting a wall. It has to be built in and for that, we should have all the processes in place, starting from architecture, design and development and so on.
An example in this context would be the way a German car company makes cars. They build the car, do extensive testing, fix it and then only release it to the customers so that they get an excellent product. Looking at another company in Japan that makes high end luxury cars, when this company finds a problem in one of the cars before it is shipped off, they stop the assembly line. Then, they find out where the defect has been introduced, fix the process and throw away all the cars that are manufactured with that defective process, and start manufacturing again. The result is that Japanese car with the same quality and luxury of German car is build at one-third the cost. It is a classic living example we have.
Building quality through absolute processes is more beneficial, important and efficient than trying to add quality or stating that quality can always be added later. When a pizza gets burnt then can the quality assurance team make it proper? Certainly not, because it is a one-way process. It is important to realize that we can’t add quality.
We have to only build quality into a product as part of our architecture, design and development. It has to be the attitude of the organization. It has to come from top- down. Organizations, people and processes should have the attitude of building quality in and not adding it later.
(In this SmartBits, Zulfikar Deen outlines “System deployment architecture and testing“. The video is at the end of this blog)
it’s extremely important to understand system deployment architecture. Let’s say we are delivering the same system and as an organization we decide to deploy it in the cloud. It requires a completely different way of testing and we need to show whatever was appropriate works correctly.
If we decide to do a hybrid for various reasons, the solution remains the same, but as an internal decision-making, we may have to make a decision based on compliance. In India, we could take the data into the cloud without much of an issue, especially when the data centres are hosted here, but the same may not be the case in other countries. The same solution deployed differently in a different country implies testing has to be different. If it is a hybrid we are trying to work with the two different system fidelities, where part of the system sits on-premise, some of them on cloud. We need to be sure that the data flows through properly and it is secured.
We may not worry about system security between two systems if the entire system is deployed at one place, whereas if it goes through public and private clouds then testing has to be slightly different. If it is completely on-premise then deployment and testing differs.
If we decide to use a part of it even in the cloud and using only infrastructure as a service the testing would be different. Again if we use a part of a service, say using a data factory from Azure, the testing has to be different because we are using a service provided by the cloud in a different way. We need to make sure it works, if we decide to use advanced services. If we were to use it as part of a whole system, it can’t be tested on-premise. Definitely we need to understand the deployment architecture, how we are planning to deploy and the testing therefore has to be appropriately done for that.
(In this SmartBits, Yuvaraj Thanikachalam outlines “ What is Blockchain? “. The video is at the end of this blog)
The way we move files from one system to another system via copy and paste “Ctrl-C & Ctrl-V” is very popular with every computer savvy professional. On similar lines can we Ctrl-C and Ctrl-V the money? Why can’t we move the value in a digital format? A gentleman by name Satoshi Nakamoto wrote a white paper on Bitcoin. He was trying to decentralize the internet, by creating a mechanism in the digital world to move the value from one pocket to the other without any central authority in place. To do this, he took this problem and solved it by using peer-to-peer technology, encryption technology, and database technology. Bringing all this together he created a solution called Bitcoin which everybody referred to as a Blockchain. Bitcoin is one of the applications of Blockchain, it is not the Blockchain. Underlying technology which powers the innovation of moving money like a copy of a file from one pocket to another pocket solving the double-spending issue was revolutionary.
In this smartbits video “Design for Testability& Automation” Girish Elchuri outlines how design for testability aids in test automation. The transcript of this video is outlined below.
There
are three aspects to be looked at when we talk about test automation. The first
one is running the test cases, the second, invoking the functionality that
needs to be tested and the third, asserting the outcome tests as success or
failure. We can talk about test automation only if we can automate all these
three functions.
Test execution Most of the time, running the test cases is perceived as automation, but ideally it has to invoke the other two as well. With reference to running the test cases, there are enough tools that can be used and invoked, but in case of invoking the functionality, a developer can make a big difference.
Backdoor invocation Normally when a product is being developed, the product functionality is accessible only through GUI. Developers should also provide a backdoor to reach the functionality so that one can actually test the entire product functionality in a much more efficient way without having to invoke the GUI. This is how developers can help in terms of test automation.
Test outcome assessment In the third aspect of asserting the outcome as success or failure, sometimes it is not clear whether it has succeeded or failed because of some small state changes that we do not know how to check. So a suggested way is to have extensive logs, these are also called as the structured logs. While logging we put debug messages, information messages and error messages. There is another category that needs to be added, these are called test messages. In a structured log with test messages, it becomes easy for us to go and check the log and ascertain whether a particular test case has passed or failed.
These are ways how a developer can help testability in test automation – by facilitating invocation and assistance in assertion of outcomes of test result.
(In this SmartBits, Shivaji Raju outlines “ Digital test automation“. The video is at the end of this blog)
There is greater focus on services testing with lot of applications being built with service based architecture, that is one of the things that is changing significantly. From a framework standpoint, there are approaches like BDD and some custom Java-based solutions that people are trending to use when compared to the traditional keyword driven approaches that we were using in the past. The scale at which we test on different types of devices has also increased vis-a-vis when we used to test only on one browser, like IE. Now, the expectation is that we test the product on the web, on native, on different types of devices, the combinations increases.
The other change is in terms of using testing platforms. We don’t want to host mobile devices on premise. We test on Sauce Labs, Perfecto, or LambdaTest, these are some custom solutions that are available which can be used to scale up testing. Even lot of projects have moved from waterfall to Agile based implementations.
The other big thing is the DevOps. In context of testing, continuous testing is something that needs to be automated. So, other than we automate our execution aspects where we automate smoke,regression or different types of tests, whether it is UI services; we need to also ensure that the infrastructure and the test data elements are also automated. When we say Infrastructure, can we automate the deployment of builds into test servers or can we provision the instances on the fly instead of having some manual dependencies to ensure we get an end-to-end continuous pipeline.
(In this SmartBits, Shivaji Raju outlines ” Key trends in automation “. The video is at the end of this blog)
Key trends in automation are significant focus on services testing with the architecture changes coming in. With service-first approach and microservices , there is a lot of emphasis on testing the services. The other aspect is that traditionally we had a lot of test cases or automation scripts on the UI. That seems to be changing. We are trying to bring in quite a balance between different layers of testing rather than just focusing on UI.
The other trend is on the tools. We were predominantly using tools like HP UFT, Rational tools, or Selenium to some extent. The trend now is shifting towards script-less solutions like Tosca, Functionize, Mabl which has ability to build scripts faster. Some trends have been noticed on the framework front too. We traditionally had QA-driven approaches which were quite heavy. Now the shift is to use lightweight approaches or frameworks, especially in the Agile context and frameworks that integrate to the toolsets as part of the DevOps pipeline itself. The need is to ensure that the framework integrates with different build tools like Maven, JIRA or Artifactory. Those are some of the expectations when building a solution for the framework.
Again, DevOps is a significant trend now, so the expectation is to see how we could automate the continuous testing pipeline, considering that it’s not just about automating the execution piece, automate even test data or probably automate the infrastructure piece. So for provisioning infrastructure from the clouds, there are certain tools to do that and then there are trends around virtualizing services, even virtualizing databases also to ensure that some automation is brought into the data and the services layer and that is how we would achieve an end to end CI or CT automation.
Summary The confluence of extreme speed of business, rapid new technology adoption, cloudification & platform-ising of apps, finicky end users has created serious inflexion points, threatening the QA practice. How do we test smartly to survive & continue to grow?
Smart testing is about doing less and accomplishing more, and rapidly with razor sharp focus on business outcomes and end user experience. It is about doing what it takes to ensure great end user experience all the way, ‘extreme ownership’ as my friend called it! It is not just in the act of assessment/evaluation, it is across the entire of lifecycle of dev/test of smartly using the process, technology and tools.Technology, business, process models are evolving rapidly and disrupting the way we do things and testing too is disrupted.To survive and accomplish more in these interesting times, ‘Test smartly. Accomplish more’.
In a discussion with Sudhir Patnaik, I asked him as what the key disruptors to our discipline of testing are. His single phrase answer was “Extreme Ownership”. That it is, not just owning the act of validation, but the ownership of entire customer experience.And this he said, changes the team structure , the way we perform test, and the skills required.
Watch the full video of my discussion with Sudhir Patnaik on the theme “The changing facet of our discipline/industry”.
The ownership mindset requires a two faced tester, one adept with technology and development on one side and the other to test well. Code when required, dig deeper to understand better, shift left tests, automate as much as possible and test intelligently.
The confluence of extreme speed that business demands today, the rapid adoption of new technologies, the cloud-ification and platform-ising of applications and the finicky end users have created serious inflexion points. It is threatening the test/QA practice, what do we do now? The demands that we have on how we need to complement dev, expand our base of skills, deal with far more imprecise information and embrace technology to get work done implies a far greater reliance on our intellect. To survive this QA disruption, ‘Smart testing’ is very necessary. So, what we do ‘smartly’ across the lifecycle of dev/test?
Smart understanding Being able to appreciate the intended customer experience implies a smarter approach to understanding the larger context, figuring out what is expected rather that ‘what is there’ to be validated. It is about figuring out how the sum total of various entities of a system contribute to the wholesome end user experience, beyond the typical piece meal validation of an entity. ‘Smart Understanding’ is an essential ingredient here. Understanding that is multidimensional, of business, end users, environment, context of usage, architecture and deployment, the technology stack and its nuances.
Smart strategy/plan How much do we test? How much do we test earlier (Shift Left)? How much can be done statically using software tools on SmartChecklists? How much testing can be avoided? How and what do we need to do to maximally automate? How to set up a continuous health check? How much can we test under the hood? What are the ‘-ilities’ that we need to test? What is the impact of changes done? Coming up with answers to these at start and continuously refining them enables us to setup a continuous test flow that is rapid, optimal and effective.It is the sensitivity and refinement of what, how much, how early, how to test minimally, employing maximal automation. It is making appropriate choices to deliver a great customer experience continually, that demands ’Smart strategy and planning’, so that we may be continuous, responsive and effective.
Smart Design and Execution How do you ensure that you have “potent” test scenarios/cases? That is, test scenarios/cases that are powerful enough to explore all nooks and crannies of the software to uncover issues. It is not just optimising execution via automation but using intellect and technology to ensure the net is cast wide enough and this can be done quick enough. Never underestimate that all scenarios can be designed a-priori; it is about being sensitive to the context and execution, and refine continuously. ‘Smart design’ is about being logical and use design techniques to model better, whilst at the same time be highly observant , curious and creative to come with really interesting and meaningful scenarios.
As much as good design matters, it only translates into great reality when its executed, statically or dynamically. Well as much as it sounds great to use this earlier via shift-left, it would be smarter to be sensitive and prevent. Static execution does make great sense and these can be done using software tools or thinking tools expressed as a ‘Smart Checklist’.In the case of dynamic execution to evaluate software, we have various choices : (a) under the hood automation via API (b) Front based automation of short feature thread or long business flows (c) execution by an intelligent human. Making appropriate choices using available information at the earliest and refining would be ‘Smart execution’.
Smart Documentation Why do we document? For posterity, for future support, right? Nah, that would be old school thinking! In today’s world, documentation is to enhance one’s understanding, with the side effect of making these understanding, choices and actions available to others. Note that first reason is ‘improving one’s understanding’, to think better. So ‘Smart documentation’ is about being to-the-point (terse), staying uncluttered i.e crisp, visual as applicable with meaningful notes, and appropriate elaboration that is strictly on need basis. Given that testing today is done in short sessions, the act of documentation should never disrupt the flow of thinking, in fact it should catalyse smart thinking.
Smart Automation Smartness is not only in doing the work oneself, it is smartly exploiting tools and technology to get this done. Automation is not limited to execution of tests to assess correctness, it is also about doing all other work in the larger context of assessment.
This could encompass test design, environment setup, data generation, problem analysis, runtime measurement, health checks, project management and deployment. In the context of assessment, ‘Smart automation’ can be (a) enabling self-test integrated into the code (b) health check suites that monitor health when change is done (c)under the hood automation using API that is more resilient (d) front end based user oriented suites (e) building frameworks that can assist the dev folks earlier to test easier (f) scripts that be easily generated and modified rapidly i.e. ‘code-less automation’ especially for UI.
Smart Analysis When we test, we may find issues or we may not. The key is, what we do with this information.How does this help in getting a clear picture where we are and how good the system is ? How does this help make meaningful business decisions rapidly? How does this allow us to rapidly refine what we are doing? It is about sifting thorough the rich testing dataset and just showing the minimal crisp information to enable rapid decision making. This is what ‘Smart analysis’ is about. Quickly dig in deep and extract nuggets.
Smart testing is the way Smart testing is about doing less and accomplishing more, and rapidly with razor sharp focus on business outcomes and end user experience. It is about doing what it takes to ensure great end user experience all the way, ‘extreme ownership’ as my friend called it! It is not just in the act of assessment/evaluation, it is across the entire of lifecycle of dev/test of smartly using the process, technology and tools.Technology, business, process models are evolving rapidly and disrupting the way we do things and testing too is disrupted.To survive and accomplish more in these interesting times, ‘Test smartly. Accomplish more’.
The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology. Towards this, we will strive to showcase interesting thoughts, expert industry views through high quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.
In today’s world of extreme agility, intelligent systems, SAAS, automated test and deployments, what is the role of humans in QA? How has the way we test software changed?
We live in the age of speed and smarts. Will machines take over testing? Will testing be subsumed into dev? With systems becoming very intelligent, it is only natural that testing become far more smarter. The theme of Smart QA explores the various dimensions of smartness and how we need to reinvent what we do.
To meet today’s demand for speed of delivery, automation seems to be the way forward. With a wide range of testing tools spanning across the entire lifecycle covering all design, execution, management, data creation, structural assessment spanning all types of tests from early stage development test to system test supporting a plethora of technologies, automation is deeply entrenched in how we test software. Is testing therefore about creating automated suites and setting up a pipeline to execute these periodically and automatically?
Yes, automated suites are the order of the day as we move into a continuous delivery mode. The continual enhancement of software demands a mechanism that enables a frequent system health check ensuring nothing is broken as we continually enhance the software. This is where tools and automation come in very handy.
Let us step back as to what we are attempting to accomplish when we test. Well, we are looking for potential issues that would upset the end users experience and risk the business outcomes. So would the automated suites that run periodically uncover potential newer issues as they seep in? Hmmm, they cannot as they are programmed to execute the same paths/flows with the primary focus of ensuring good health. So what do we do? Add/update the automated suites continually and also test humanly. Note newer scenarios are created and some converted into suites, however not all can be figured out and automated as creativity cannot be boxed. It is necessary to be smarter to outwit the elusive bugs. As software is continually modified becoming richer, automated suites need to be synched with them too. A well-formed test strategy and a well-architected test assets are necessary to exploit the power of automation continually.
So where smartness figure in this? Is it not just plain tooling tech to come up with scripts/suites? Let us take a deeper look. What we are doing really is converting our scenarios into scripts and also using appropriate tools & frameworks to enable static assessment and incorporate this into the tool chain. So never forget that the test scenarios to are really the key to effective testing. To be able to this well, we need to be able to understand the system context well, decompose the system into various sized entities to test so was to come up a great strategy, to create well-organised test assets(scenarios/cases/data) covering all the different-sized entities and ensuring these ‘tightly’ cover the software ensuring high coverage spanning all types of tests right from early dev stage to whole system stage. All this up front work demands brilliant smartness, before we exploit tech and tools to make the execution efficient. And this is why I think “Tooling and automation are great, but Smart QA is brilliant”.
Smart QA is about doing less, doing quick and achieving far more. In every facet of the lifecycle be it from the earliest stage of understanding, to exploring the context, charting out the scenarios, scripting suites, intelligent regression, doing static assessment to continuous course correction, it is necessary to do the least, do the fastest and get great outcomes. Let us take a look at the “smarts” in the various parts of the lifecycle in detail.
In today’s world, information as to what is expected is not spelt in great detail. It is terse and simplistic, that is at best clarified by ‘acceptance criteria’. It is no more elaborately articulated as was done in the past. It is expected that the tester explore the system far more carefully and creatively to discern what may have been intended, what would be most meaningful for end users and then ask questions to clarify, to understand, or come up with scenarios to evaluate. Smart exploration is what is needed to rapidly understand the context, and how visual thinking can aid is discussed in “Exploit visual thinking – Smart exploration of software”.
The UI of today’s software is very rich and contains very many features packaged densely on a small screen. I have noticed that how one decomposes a rich UI to into various entities to test, decides how well and how quick one can evaluate. Smart modelling is key to this, this is dealt with in detail in the article “How to test rich UI – Smart Modelling”.
Software is continuously modified necessitating constant retesting/regression. Automated testing is very handy but not everything can be automated. It may not be really necessary to test all every time as systems harden with time. How can we do regress less is where Smart Regression comes in and this is examined in detail in “Three Aids for Smart Regression Testing.
Bugs seep in right from earliest stage of code development/modification, which we believe should be uncovered by automated unit tests. This does seem right, but what a minute – Can we become sensitive to issues that may seep at the early dev stage and prevent these, or detect this as cheaply as possible using ‘smart checklists’ as is done in other mature industries rather than resort to unit test? What a smart checklist is and how this can help is the crux of the article “Smart checklists make you think”.
Smart QA is really about applying intellect to deliver ‘clean software’ by doing the least amount of work and exploiting tools to do the grunt work or be the enablers.
“Tooling and automation are great, but Smart QA is brilliant”
