We compile the five business questions that we find most frequently in the field of automatic software testing. If you identify with any of them, we encourage you to vote in the comments which is THE QUESTION for you.
Arrive at Asking these questions requires having visualized that the use of programs is critical in the development of your business. Our experience has taught us that there is a group that is not sensitive to impact of the software on your turnover … yet. They come to be the flat earthers software quality assurance (SQA).
Among those who already know that the earth is round and
who are interested in software testing,
we observe that they are typically
Development, Applications or SQA Managers
overwhelmed in their day to day,
investing in testing and
with little time to attend to us.
Does it sound?
Our responsibility is to maximize your investment and reduce your workload.
How?
Providing stability to your products thanks to automatic assurance.
By the way, in this client archetype almost no one admits that they automate tests. Almost everyone tests, and hardly anyone automates. Could it be out of modesty? Is it due to ignorance?
To recognize or not to recognize
So let's go with the 5 questions, they are all equally significant, they are all five stars:
Q - When is it possible or useful to automate tests?
Behind this question we can read: "is that mine is special", special because it is complicated, because of particular, because of cheap ... They still think that automating tests is Science Fiction or for idyllic situations that do not apply to them.
It is frequent that they have had some exploratory initiative in their team at the controls of a Selenium or even pulling a Jenkins, that they have tried to automate in their spare time and thus have issued their diagnosis of impossibility / infeasibility, simply because they were not applying a criterion globality.
R/ It is almost always possible and useful to automate. When is established by understanding test automation as an investment. Interested in adding test automation to our software build and deployment process when it is profitable for the business.
Q - Do you use a special tool? Do you do it based on custom scripts?
This is usually the question among those who REALLY know the value of software testing and know that it is possible to automate it, so they focus on test automation tools.
Thus, in some cases they have already bought commercial products, such as those of the defunct HPE Software (integrated in Micro Focus), but they are not very sure of their value. In other cases, they consider the possibility of working with an OpenSource tool.
R/ The tools are the consequence of our decisions at the software quality assurance (SQA) process level. For example, incorporating the
agile design with TDD it requires aligning the work culture in the organization, which is something much more expensive, deep and profitable than buying a tool. The minimum level of concern has to be
what is the testing strategy that we are going to use,
Typically, business flow testing orientation is the most recommended option.
Q - Where do I start to automate?
Problems with environments, monolithic systems, “patch over patch and patch again” developments, departmental silos, etc. Our interlocutors have to live with so many bugs that they end up showing the same allergic reaction when they are told about automatic tests (Another bug more!). Hence his disorientation on where to start.
R/ To orient yourself in this jungle, we recommend starting by identifying test tasks that are boring, repetitive and without much apparent value, but that could be decisive at very specific moments or that always generate fault conditions in your current systems. It's just a small first step, but it relieves the stinging.
Then it is time to enter more elaborate nuances, such as frequency of change or criticalities from the business. Our focus is usually to ensure that there is no backlash on the product, that is, automate functional regression tests.
Q - What do you need to be able to automate?
A defensive question motivated by day-to-day pressure, related to concern about the adoption curve and the lack of expectation of tangible results. In these scenarios, the pilot or proof of concept proves almost miraculous.
Be careful, we don't do miracles. If the current manual tests are not minimally documented, we will not be able to automate anything in the restricted framework of a pilot. Again, our experience is that a customer who does not document their testing is often a flat Earther: "consistently testing software is overrated."
R/ Therefore, our base reference is that a certain documentary level is available for manual tests. Not much, we need a document "of those who normally use" and a minimum attention so that our specialists can build an effective Pilot in less than ten days.
We are human, we have our tricks, such as orienting tests to business flows and leaning on
Zahorí as a base solution for functional test automation, when we are facing cases of web or mobile automation, of course;).
Q - Can you automate any test of any application?
When asked this question, we often feel at a crossroads: either you need to start now or you don't plan to automate anything.
As a first measure we recommend our page dedicated to self-discovery:
R/ The answer is: Yes ... but we want it to be profitable for you.
If you have a web or mobile interface, YES.
In case of wanting to automate tests on host / cobol processes, YES.
For applications with high levels of integration with legacy systems ("legacy"), If possible, but The maintenance of all these automatic tests is usually very complicated, which puts the profitability of this investment at risk.
And here we come. We have shared these doubts with you because we understand that they must be resolved in order to take advantage of the advantages obtained by prioritizing the value delivered as a work culture. With them we sketch our answer to the necessary who, what, where, why and when to incorporate automatic functional testing in your software build cycles.
Have we managed to clear up your main questions about test automation?
Yes? Cool!
No? Join us, we accept the challenge!
Ready for the challenge
According to what they say at the beginning of the article, I think the question is, what is the use of automating? because not everyone is familiar with the usefulness of these processes and although it is emphasized that the ideal is to maximize investment and reduce the load, companies need to know specifically the implementation of these processes what types of loads will reduce and what will be their return on investment per implement the automation process
Indeed, as you say, companies must know in advance what profitability, or what Value, automation will bring to their SQA processes. We understand that automation will be profitable as long as it allows us to provide value and personalized experiences to our own customers, ensuring their user experience through an end-to-end SQA process, with broad functional coverage. We also tell about it in this article, in which some companies tell how they have found that value with automation: http://www.elmundo.es/economia/innovadores/2018/02/25/5a904c62e5fdeaa75c8b4674.html
And since this depends on the SQA processes of each company, I also invite you to participate in this questionnaire on Automation: https://goo.gl/forms/njLCuE5oxOVUrNZs2
Thanks for your contribution!.
Many times we find point 4, there is hardly any documentation of the manual tests and in some cases not even evidence ...
Nice article, thanks!