4 reasons against, and 5 in favor ;-).
All companies related to the ICT sector perceive a multitude of signals in our day to day that indicate the profound change that has already occurred in our activity, and in the value that our clients perceive from it. Software testing has not been immune to these changes.
Before 2012, the market was very different. The software testing business was focused on the Large Customer segment. As a result of poor planning in many SW creation processes, and the lack of ALM methodologies based on Quality Assurance, large-volume testing projects were carried out, with continuity over time and stable demand, and with classic models of test management, that is, based on theoretical-predictive models.
The current scenario has changed. There is enormous pressure on the costs of the IS areas of organizations, and Quality is a very compromised factor due to this pressure, which has led us to question whether an independent verification and validation process will imply an unnecessary extra cost.
Likewise, there are new agile methodological scenarios, where the philosophy of multidisciplinary teams and overlapping activities leaves less room for the independent verification and validation (ISVV) model.
In short, we find ourselves with small volume projects, with very tight schedules, conditioned to a growing budget dependency and, therefore, to a variable demand that is more complicated to manage.
It is not that there is no longer a vocation for Software Quality. Simply, the lower investments, the best software creation tools, and the new agile testing methodologies force us to change our approaches to our clients. ¿Is the figure of the tester out of play?. ¿Independent verification and validation, with control points external to development, is no longer useful? Or, getting more to the point:is it worth spending money today on a software testing service?.
Let's see the 4 reasons why, a priori, we would answer NO to this question:
1. El budget adjustment experienced by all IT departments often takes a victim: software testing.
2. In an age when investments are viewed with a magnifying glass, there are still companies that opt for software creation processes without Quality controls, or very few and very specific. The justification is simple:why do I have to spend twice the money? Why do I have to prove what someone who already charges to do it well has done? In these cases, it tends to better assume that there are more penalties to the development area, until the development is of the expected quality. Especially in not very complex or non-business critical environments, there are clients and organizations that have not yet understood the need to work on their SW with Quality.
3. Every time there is more and better suites and Software creation ecosystems, with a constant evolution every year, which relativize the value of other types of IT services. This makes the SW increasingly industrializable, less personalized. And therefore with a lower potential error rate.
4. Por último, la integration of testing in the development process itself. There are new methodologies that require immediate adaptations in short iterative cycles (togile, lean management), very effective in certain types of projects (See http://www.javiergarzas.com/metodologias-agiles). An independent validation cycle in these short development cycles is only possible if there is full integration between the tester and the development team. And this is not always easy ...
However, There are many arguments in favor of estimating that the quality service and software testing is still relevant and necessary, in many cases, to include it in our budgets..
1. The first reason lies in the user, in the Client. All current developments should follow one way or another IPV models of immediate perception of value from our SW. This agility in the perception of value by the end user is essential today and increasingly conditions the application development process. It is no longer measured if what we have done is good (Satisfaction), but what we must do to make our SW better (Loyalty). To do this, we must take care of the user experience, regardless of the technical or methodological characteristics of the development process. This is a natural area for the software "validator", who must certify the application. In the field of mobile applications, this aspect is especially important.
2. We must not forget that the ICT sector is advancing on something already consolidated, and legacy systems continue to be in many companies the great guarantor of the Business. These systems continue to operate in traditional development environments, and it is difficult to implement new development models in most cases. In this case, the figure of the validator or certifier with its software testing in a traditional model is still vital for these large organizations, with large systems. And with a lot of business at stake.
3. Of course, today there are many more checkpoints and quality assurance (Quality Gates) in the process of developing an application. There are new elements in the production chain that need to be tested that did not exist before. For example, in a mobility application, testing network behavior models can be essential to ensure the performance and operation of certain applications.
4. La date pressure on production start-up of a software undoubtedly produces a further deterioration of the quality of the software. And at present the pressure on dates, especially in the Latin American market, is indisputable. The figure of the "validator" is therefore essential, even when some minimum quality indicators have been defined, before the release of an application pressured by dates.
5. Finally, in M2M environments, the Increase in the variety of devices and Management Systems (See http://www.tid.es/es/Tecnologia/Paginas/M2M.aspx ), and the evolution of the mobile app market implies an exponential growth in the needs of software testing and certifying platforms and applications.
Ultimately, we believe that there are scenarios in which independent software testing activity is essential.
But it must be clear that the change in the ICT services model necessarily implies a change in the model in Quality Services and software testing. And that this change in turn implies new Software Development processes, feeding the entire model as a whole with validation and continuous improvement mechanisms.
Therefore, based on all these premises, we have changed our model in quality services and software testing, and our new response to the market is based on 4 fundamental principles:
2. adaptation to demand
3. low cost, and
4 technological renovation.
On these 4 principles we built in 2011 our new Test Factory, under the motto: Testing is always cheaper than Non-Quality.
Why does the Testing Factory Model meet our 4 principles? How do we manage to respond to the challenges of the sector with this Model? That is something that we would like to tell you in a next post 😉
What is worth it is sure to read the article a couple of times, without reading diagonally!
Deep arguments and fundamental principles… very demanding.
Only by changing our management model have we been able to achieve these principles.
In favor of Testing as long as it does not become a penalty process for developers and leads to the ruin of an economic war even within the same company, this process must take place focused on the client and declare in the tests that the Non-conformities in accordance with the technological principles of development established by the company and the requirements defined in the process in order to eliminate all possible execution errors, ambiguities and difficulties in their exploitation by the client. It can be within the technological development process or outside of it, both have advantages and disadvantages, it seems appropriate that there be testing both as part of the development process and outside of it since both focus on different processes. It is almost impossible to avoid human errors and I do not believe that the existing technologies avoid it, in any case the analysis of this problem is more complex, especially if the economic, financial, market and customer factors are included.
BTW, the link to TID is broken.