Blog


QA & Modern Development

First of all what is the difference between QA and Testing? Is there one? Standard IEEE definitions are:-
TESTING means “quality control”
QUALITY ASSURANCE measures the quality of processes used to create a quality product.

This is fair assessment, and it is Quality Assurance that this book is focussed on, as testing is simply a derivative a QA process. What has inspired/driven me to write this book, is to sum up my experiences into a guide for other QA Managers to deal with the unusual and bizarre – the world of RAD, of which Agile is the most popularist exponent. Before moving onto this topic, lets see if we can define Agile. This is a challenge, as the perception of what agile is differs from company to company, and individual to individual.

 http://agilemanifesto.org/

This is a good overview of the aims of agile, but the biggest error is to take this methodology and attempt to build a complete project around it. The main problem with methodologies that claim to encompass a complete project lifecycle, is the dangerous assumption everyone is working off the same page; that everyone understands the implications and possible caveats. Agile has been dogged by theory and tools, rather than focussing on real issue with modern software development – communication. I have been in several bizarre meeting where the topic has been communication issues. Unfortunately the upshot of these meetings is usually “lets email even more” or worse “we are right, they are wrong”. The customer is the driving force of a software project, be it an internal or external one.

The aim of agile is to develop fast, with minimal interference from traditional business processes. The focus is on the customer, but the customer is rarely involved in the day-to-day Agile process. We can see the assumptions mounting up, so rather than following a more critical view of Agile, I am suggesting that development are doing what is required, it is other project members that are not adapting their important roles.Â

Firstly to challenge the traditional role of QA management, and discusses what role attributes should remain, what should be adapted, and additional responsibilities the QA Manager has – whether or not this is defined by the company. Should I be following company policy, rather than defining my own own? They hired a manager, and the assumption is that you can think for yourself, and go against the grain if required. QA requires a thick skin, social aptitude, and complete faith in your beliefs. That is why so many testers did not make it from 20th to the 21st century.




what is the difference between QA and Testing?

First of all what is the difference between QA and Testing? Is there one?

Standard IEEE definitions are:-
TESTING means “quality control”
QUALITY ASSURANCE measures the quality of processes used to create a quality product.

This is fair assessment, and it is Quality Assurance that this book is focussed on, as testing is simply a derivative a QA process. What has inspired/driven me to write this book, is to sum up my experiences into a guide for other QA Managers to deal with the unusual and bizarre – the world of RAD, of which Agile is the most popularist exponent.  Before moving onto this topic, lets see if we can define Agile. This is a challenge as the perception of what agile is differs from company to company, and individual to individual.
http://agilemanifesto.org/

This is a good overview of the aims of agile, but the biggest error is to take this methodology and attempt to build a complete project around it. The main problem with methodologies that claim to encompass a complete project lifecycle, is the dangerous assumption everyone is working off the same page; that everyone understands the implications and possible caveats.  Agile has been dogged by theory and tools, rather than focussing on real issue with modern software development – communication.  I have been in several bizarre meeting where the topic has been communication issues.  Unfortunately the upshot of these meetings is usually “lets email even more” or worse “we are right, they are wrong”. The customer is the driving force of a software project, be it an internal or external one.

The raison d’etre of agile is to develop fast, with minimal interference from business.  The focus is on the customer, but the customer is rarely involved in the day-to-day Agile process.  We can see the assumptions mounting up, so rather than following a more critical view of Agile, I am suggesting that development are doing what is required, it is other project members that are not adapting their important roles.

The traditional role of QA management, has been adapted over time by necessity, rather than any guidelines.  And the additional responsibilities the QA Manager has, extends into release and project management (these roles have been diluted over time, especially on web/media project.  The question I still have for myself, during consultancy work, is should I be following company policy rather than defining my own path? They hired a manager, and the assumption is that you can think for yourself, and go against the grain if required. QA requires a thick skin, and complete faith in your beliefs!




Agile – Customer Focussed?

I believe the negative flipside of Agile, is that though the positives of rapid development, creativity are core to the methodology, the other core principle that that the customer/client (be it internal or external) can be lost in that environment. In such situations more traditional process, and communication can salvage the project, without damaging the overall Agile process.

As with most new methodologies, there is mistaken assumption that by simply adopting the methdology in development will somehow work. I reality, all project members have to be working not only to same guidelines, but also not to forget that each project member represents his/her own project area. Project Management and QA are usually the common areas of failure in Agile environments, which of course leads to damage to relationships external to a company.

There are tools specific to Agile, and MSProject is not my first choice as a project management tool in any case. I always found dotproject was a better integrated project/QA management tool, which is more suited to rapidly evolving Agile projects. However the core of Agile principles is more to do with a way of doing things, rather than software enabling this to happen.

Nothing new has really been introduced, as the idea of development and testing working closely together is just sound software development practice, and shorter release cycles is more appropriate the demands of modern software projects. What is new is better accountability of development, and more interactivity between a company and their client. i.e. more transparency generally in the project lifecycle.

This information was based on my own experience, and in media/gaming way, QA has always been more of a challenge, due to the creative and emotional level of people that work in these industries. Automation is heavily featured in Agile methodology, but in my experience the biggest challenge with Agile is people, not technology.




Open Source Automated Test Software

One of the most impressive uses of test tools I saw in action was the usage of open source test tool STAF (Software Test Automated Framework) in conjunction with Junit. The main advantage was that the company was able to create a very relevant load test environment, on a lower budget. It also does not require expensive hardware to run on.

STAF is a load test tool primarily, and allows you to build a load test framework, and uses XML configuration files to create different test scenarios. It is very scalable, and we were able to simulate 100k transactions spread over a 2/3 day period. This is by no means to limit of the system’s capability. It requires good technical skills and buy-in from project development team, as their input and customisation work is key to successful implementation of STAF.




Agile Complacency

It appears that Agile methodology works well for development by default, but can create issues in other areas, notably support and data storage. As the benchmarks can be changed rapidly on an agile project, this information needs to be filtered down rapidly to prevent problems at product launch stage.

One solution to alleviate this potential pitfall is to keep trainers, support and DBA’s in the agile communication loop. In the end, its the people who have to work with the software ongoing that will experience the knock-on negative effects of Agile. Looking at Agile from higher level, it is easier to see where communication can break down, and where dangerous assumptions are made.

This is not a negative view of Agile, but more of a note that evolvement of the methodology must continue, as well as education to broader scope of people.