future

How Quality Professionals should prepare for the future?

This article is originally published on www.linkedin.com/pulse/how-quality-professionals-should-prepare-future-ahmed-el-deeb/

The initial spark of rebellion started in the 1990’s when professionals came to believe that not all software problems must be treated as an engineering one. People have started to get tired of the high-regulation of the late 1970’s engineering-like processes and the inherent frustration of micro-management and requirements obsoleteness. And it witnessed early attempts such as Rapid Application Development (RAD) and the Unified Process, which served as early drivers to what later came to be Agile Development whose manifesto was written in 2001.

However, it was over the past 12 years that the movement has been shaping and transforming the way we conduct software projects. In front of our eyes we stood watching the transformation yet did nothing in tailoring one of its essential challenges, testing. We watched the process solving the 1990’s problems yet watched it departing away from QA, leaving it no adequate place. We took our place within software projects for granted. And instead of adjusting our place, we raged in tantrums whenever we are bypassed and we increased our timidity in holding on to our old cherished activities which are basically at the root of the problem.

Why we need to prepare? Because the way software is developed and market needs have changed and become faster than how we do QA. There is both practice lag as well as a technological/technical one. Here are main software industry dynamic changes that begs for us to prepare:

1) Agility and Innovation Time-to-market are the main drivers

Time-to-market in the olden days was about making a piece of software available to users within an adequate timeframe relative to the competitive market. However, that generic definition is no longer applicable to software. It became now about when we can make “Innovation” available. Time-to-market definition has changed from mere availability to innovation availability due to two main factors: 1) As we started to produce software much more quickly and easily, thanks to the transformative technology of late 90’s and 2000’s, business owners have stretched their ambitions to innovative features; and 2) Users are no longer users of software, they becameConsumers of software, which means their needs won’t ever be static and they will be in continuous hunger for more features.

With this change of industrial and market dynamics, we are producing Software at higher speed and bigger size, thanks to software development technologies that made this possible. Alas, QA has fell behind in such race. The speed of development and quantity of production have way surpassed QA ability to catch up that it has become a bottleneck.

2) There is considerable gap between QA practice & Dev/Release

QA artifact is human thinking rather than tools, whether this artifact is test cases or clicks and key strokes. Thinking requires the input of information, past knowledge, and understanding. After that, there will be gaps in understanding and blind spots. This means asking questions or rethinking the inputs. The challenge of this thought process to QA is not it being a thinking activity; after all, every phase in the software development process is operated by human thought. However, the challenge is that QA is outsider to software. QA doesn’t create any of it: we didn’t conceive the thought itself, which is created by Product Owners, and we didn’t create the implementation of it, which is created by developers. Thus, we are always on the outside thinking about something separate from us; and this makes our thought process challenging in terms of time. At the end, QA ends up having knowledge more than developers due to this very same reason, but at the price of time that the market is no longer willing to pay.

Reality molds thinking

When mind is combined with the craft of hand, one’s thinking gets personified into a physical entity. Reality molds our thinking in return to our thinking that gave birth to this reality. It’s like our thinking and reality are in continuous feedback loop, each reinforces the other.

And this is what development technology advances have successfully sought to achieve: what I would call Eliminate and Elevate. It eliminated human thinking at all in some parts while elevated the level of human thinking in some parts. For instance, olden day developers had to think of very find details, like Exception Handling. Now, a developer is relieved from ensuring array out of boundary. This is a case where human thinking is eliminated altogether. On the other side, development technology has allowed developers to think in terms of constructs and models. If/Else statements, classes, tags, functions, data structures… are all examples of constructs that conveniently embodies human thinking. This is all unlike QA human thinking activity: we need to tackle all level of details small and big (no elimination) and we need to think in the open; like a philosopher in the garden looking into the sky trying to articulate possible combination of angles to a problem (no elevation). It’s all raw thinking to QA. And ironically enough, this is exactly what seems to separate QA from users and make their existence in companies valuable! When QA cuts corner on this tiresome thinking activity (to save time or being lazy), it loses its existential value in the company and becomes a mere user clicking and playing around, that we can hire anyone in the street to do for us – in fact, the model is there: Crowdsourcing Testing and Pay-by-Bug services.

All the above major factors have been challenging QA over the past years and with time, the gap between QA and software development & production has been widening more and more. QA is important and its existence in the field as a standalone activity till now though all these challenges is a sufficient proof of that importance. However, reality always finds a way and while industry is not seeking to remove it yet it is investing into finding better ways to achieve it. This is happening now; and it is now that you, QA, must start to prepare. How?

A) Become Domain Expert

To break the barrier between the QA and the software being tested, one needs to be a Domain Expert. Most QAs concern themselves by learning the software they are testing and becoming experts in it. However, what QA lacks is becoming experts in the entire domain they are working on, not just their immediate software. By being a domain expert, you bring in more value to testing, you contribute to the business, and you become much more quicker in generating test scenarios that matters the most – as a domain expert you have fingertip sense in knowing where to hit. And from the economical perspective, you are increasing your employability in the future if need be that you shift to product management or a new company that wants to hire your domain expertise. How you can achieve that? Suppose you are working on education and learning products/software:

a) You should invest some of your time researching and reading about other products in the same domain. What are their features, how they are functioning…etc.

b) Not only this, you also research technologies behind them that serve your domain; what are their strengths, limitations…etc.

c) And last but not least, dedicate like one weekend every month to download those products apps or register for an account and play around with them in an explorative testing manner. This exercise will sharpen your skills and enhance your knowledge as well as helping you seeing different types of bugs that will help you even come up with more scenarios you hadn’t articulate with your software.

B) Learn about Software Design

Recall our earlier discussion on users’ tolerance to non-essential bugs given they are provided error-free feature mission? When you start to think of software as Featuresrather than discreet functional specs and bugs, it will become clearer to you that the critical problem in nowadays software is “Poorly Designed” features. They deter users from using the product more than non-mission-critical bugs. In fact, most of mission-critical bugs of features are due to the poor design of it.

In this undertaking, you should partition your learning into two paths: 1) Usability and 2) Design Patterns. That is, you get the outside and the inside. You can follow a focused approach by learning first what your company or product is using. You can ask developers which architectural design pattern they are using and start with that. You can also read about usability of apps in your domain; and do your homework by thinking: a feature like X, what usability and design elements that most bring it forward? With such type of questions combined with your education in software design, you are not only better at testing your features, but an essential contributor to them.

C) Master the science of Measurement

Quality Metrics and Measurements is one of the most deserted branch of QA though its high importance. Without it in place, no one feels it, but try one time to send a real report that provides insightful measurements based on solid metrics and see how much attention that report will harness. Measurements are light. If you are able to measure, then, you are the person who can tell everybody else what’s really going on. The entire world is statistics fanatic. However, in your work as QA, you become the highlight by this.

To master this science, you first need to first define your metrics (I.e. What you are interested in measuring) and your objectives from measuring these metrics. Then, you need to spend more time gaining mastery over these metrics so that measurements out of them are reliable and accurate. You will rarely be able to do this independently; therefore, be ready to speak to other teams and gather some information. And don’t report to the public at first shot. It’s best that you spend time reporting internally, or yourself, first until you have mastered the metrics, found better ways for collection, and obtained repeatable results.

D) Learn Systems Thinking/Engineering Fundamentals

Plenty of modern time problems are System Thinking and Engineering problems. And plenty of problems we ourselves inject in our life are due to our failure to think on the system level. For instance, you are producing a very nice app that help people for example learn about traffic before they go. This app was very slow in crawling traffic information and displaying it to users. Your team after studying the problem realized that the problem is in the frontend layer and worked hard in slashing this slow operation time by reducing the number of function calls in the frontend as well as minimizing decision nodes in each function. You, the QA, has been tasked to test this improvement. You tested it functionally and non-functionally by doing performance tests and you cleared that the app version is ready to go. Next day after release, the entire team was called in that the backend system on server side that is supposed to register and dispatch the traffic information has failed to route traffic data at timely manner; that is, users started to get information about traffic condition of their route several minutes delayed, thus, losing much of their value. The team studied the problem and discovered that when they streamlined the front-end performance, they increased the number of requests between the front-end and the controller operating the backend. They never saw this in the past because they never had such smooth flow, but now the streamlined part has placed pressure on another remote part. This is a typical example of System Problem.

What is Systems Thinking/Engineering? In straightforward definition without jargon, it’s the thinking that your variables are rarely independent but rather Interdependent. When you change variable X, you also affect variable Y in some sort. Your mission as a systems thinker is to uncover the Y variable and the type of affective interdependent relationship with the known variable X you have. To train your self into being better at system thinking:

a) There are available Systems Thinking/Engineering tools you can borrow and use. For instance, I would recommend something called Quality Function Deployment (QFD) as a non-complicated and nice technique for you to start with. Using it, you can draw interconnection between different parts and attributes as well as weighing them.

b) Train yourself to go further steps away from the point you are interested in yet leading to it and leaving from it. If you are a computer science major gradate, then, you must know Automata Theory that we create to define syntax grammar. Automata are considered like a model for a machine; that is how it operates. Same to a feature. How it operates is not just a precise point yet an entire model around it with your feature being only one point in your model and has lines of connected dots before it and lines of connected dots after it. If you train yourself to think in terms of your feature Automata, that is the entire graph of points connected to it, you will uncover untraditional remote parts impacted by the feature at hand.

E) Master Test Automation

Test automation could be the first step in addressing the technological gap between Quality and Development as well as release/delivery processes. Software development is quicker software usage combinations are increasing, and market demands are pushing; this is while testing is purely a human activity. If we need to release new app version that fixes bugs or introduces something new every one or two weeks, we need to be able to run over everything and provide feedback in 1 or two hours. This is impossible with manual testing. The matter gets even more handy with Continuous Integration and Delivery processes (CI & CD). With each development Pull Request, subset of test automation corresponding to areas impacted by the pull request are automatically triggered. When it’s Green, the pull request gets automatically merged and if Red, automatically rolled back, and further investigation is done on the causes of failure.

If you want to master test automation effectively, I recommend that you first find state-of-the-art technologies and learn them. I have seen many people in attempting to do automation, they start by using plugins and code-generation tools or, if they are more serious, they jump into learning a given programming language they are told is used in automation. This is a wrong approach that will prolong your journey and make you less efficient. Plugins and code-generation tools could be useful if you want to test static software, but they disintegrate if you are working on a organismic product that enlarges with features every while. On the other side, test automation is a family of technologies and never a single thing. That is, developing and working with a real test automation framework is to work with a set of technologies combined together. Therefore, it’s important first to find out this family of technologies and follow an integrative approach in learning them. There are many languages and technologies out there; however, my recommendation always goes to Cucumber, Capybara, Ruby programming language as well as Selenium webdriver. From experience, I find them the most efficient in coming to play together and they are extremely supported by a wide variety of code libraries in virtually any programming task you can imagine. However, don’t reinvent the wheel. If you are already adept in PHP, find those technologies that revolve around them; same if you are more experienced in Java. They are also popular in the field of test automation and you will surely find supporting platforms for them.

As we stepped in the field of software, we should be always tireless in preparing and developing ourselves. In a rapid industry like software, it’s slow death to shelve yourself and fail to notice the trends, problems, and transformations. It’s also the nature of that field that you owe your own edge to yourself not the company. You handle the responsibility of seeing things and preparing to handle them.

Posted by on 12 Sep 2017

Lead QA Engineer

Leave a Reply