Testing the system behavior which is not there

Yesterday, we were giving a demo of our mobile test automation POC to a client for their android app in the financial domain.  It was a simple scenario with login to the android app and then testing the market watch feed to the logged in user.

The screen as below:

The POC was based on the existing manual test scenario with the suggested data from client. Using the correct login id and password takes the user to the welcome screen.  If the user id or the password is not correct then the application would throw an error message and request you to try again with valid credentials.

After the demo of the successful login and further steps in the POC, the client representative asked us to update the test to use invalid password which was very long.  The data suggested was “anand long name in the password 8hj”, this string was 35 character long.  When we reran the test the login was unsuccessful as the password was invalid, however the password field didn’t accept the full string and truncated it to 12 characters “anand long n”.  So the conclusion was that the test passed as it didn’t allow to login with invalid password with an observation that the test didn’t do enough to catch the fact that the entire password string was not used to run the test and the test data for the password was actually truncated.

Now should the above test trap this condition and not allow any further characters post 12 characters to be typed into the password field?  Should it throw an error?

What do you think?

Here is my $0.02…

I would look at the behavior of the system in the requirements in the same scenario. What happens when we manually run the test?  Is it conforming to the requirement?  The manual test and thus the test automation script needs to validate this behavior of the system.

It would be wrong for a test case to validate something which is not part of behavior of the system and even worse trap and override the system to give warning and errors.

In the above test case when I manually enter the password, after 12 characters the system does not let me type any more characters, but please note that it does not stops me from entering any further characters into the field.  If I was not looking at the screen then I would simply type away all the characters and process with the next steps.  A test automation tool is like a person who does not look at the screen only interacts with the system under test.

This seems innocuous at first but consider this, if the valid password is “123456789012” (12 character string) and I used test data as “123456789012345” (15 character string), the system would allow me to login with invalid test data as it would truncate the long string into a valid password.

http://www.reactiongifs.com/wp-content/uploads/2012/11/typing.gif

Now it is up to the users to decide what should system do if I am happily typing away even though the password field allows max 12 characters?  

1. The system should let user type more than 12 characters and not truncate (as it may pose a security risk to reveal the max length of the password)

2. The system should pop-up an error message that user has reached max characters allowed in the password

3. Or the existing way where the users can type as many characters but system will truncate it to max allowed characters without knowledge of the user.

Once we close on this system behavior from the varied perspectives of functional as well as UX testing then we need to accordingly validate this behavior using manual and automation test cases.

I would also like to bring your notice that above scenario is also an example of how testing can lead to functional as well as the user experience requirements when it is either done along with or prior to system requirement gathering. This will help us study requirements from a behavior perspective which can then evolve and lead to better test cases and eventually high quality.

Happy testing!!

ATDD Mobile Test Automation - Integration of FitNesse with Appium - Part 1

FitNesse is a collaboration tool, some Agile enthusiasts use this tool to facilitate ATDD (Acceptance Test Driven Development) or BDD (Behaviour Driven Development).  Compared to Cucumber where the focus is on the behavioral aspect, here we also get inclined towards the test data framework.

Appium is the premier open-source tool for mobile testing.  Here is my video on integrating FitNesse with Appium.

FitNesse can be downloaded from this link --> http://www.fitnesse.org/FitNesseDownload




The prerequisite for Appium project are as below:

• Install Android SDK
• Install Node.js
• Install Appium
• Install Appium Java Client
• Configure Appium in Eclipse (preferably maven project)

FitNesse server can be started using following command:

java -jar fitnesse-standalone.jar -p 9090

where -p gives which port to start the server.

Configure the project in eclipse with FitNesse and Appium dependencies and run the mobile test.  More details on Eclipse setup in part 2.

BDD Mobile Test Automation - Integration of Cucumber with Appium

Behavior Driven Development (BDD) is very popular with many Agilists out there, specially those focused on Testing. However my view is that BDD is not about Test Automation, it is about collaboration so that the expected behavior of the application can be determined. Cucumber happens to be the tool of choice to implement BDD.  While doing this for web applications, we can drive the features through WebDriver.

Lately the application development has been inclined towards mobile apps and we need to extend our exiting BDD frameworks to handle app, be it Android, iOS or Win Mobile.

Appium is a neat tool for anyone who has exposure to WebDriver, irrespective of that also it is an excellent tool for mobile testing.

Here is my video of running Appium tests for android app using Cucumber.

You can create the Maven project using the following POM.xml:

1:  <?xml version=&amp;quot;1.0&amp;quot; encoding=&amp;quot;UTF-8&amp;quot;?>  
2:  <project xmlns=&amp;quot;http://maven.apache.org/POM/4.0.0&amp;quot;  
3:  xmlns:xsi=&amp;quot;http://www.w3.org/2001/XMLSchema-instance&amp;quot;  
4:  xsi:schemaLocation=&amp;quot;http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd&amp;quot;>  
5:  <modelVersion>4.0.0</modelVersion>  
6:  <dependencies>  
7:  <dependency>  
8:  <groupId>junit</groupId>  
9:  <artifactId>junit</artifactId>  
10:  <version>4.11</version>  
11:  <scope>test</scope>  
12:  </dependency>  
13:  <dependency>  
14:  <groupId>org.seleniumhq.selenium</groupId>  
15:  <artifactId>selenium-java</artifactId>  
16:  <version>LATEST</version>  
17:  <scope>test</scope>  
18:  </dependency>  
19:  <dependency>  
20:  <groupId>info.cukes</groupId>  
21:  <artifactId>cucumber-java</artifactId>  
22:  <version>1.0.14</version>  
23:  <scope>test</scope>  
24:  </dependency>  
25:  <dependency>  
26:  <groupId>info.cukes</groupId>  
27:  <artifactId>cucumber-junit</artifactId>  
28:  <version>1.0.14</version>  
29:  <scope>test</scope>  
30:  </dependency>  
31:  </dependencies>  
32:  </project>  

The code for JUnit test runner is as below:

1:  package com.qaagility.atacalc;
2:  import cucumber.api.CucumberOptions;
3:  import cucumber.api.junit.Cucumber;
4:  import org.junit.runner.RunWith;
5:  @RunWith(Cucumber.class)
6:  @CucumberOptions(format ="pretty", tags={"@only"}, features = "test/resources/ATA_Calc.feature", monochrome=true)
7:  public class TestRunner {
8:  }

Back after a long time and wishing you a very happy new year to you all!!

So what does 2013 holds for us in the testing area, I find this year full of lot of prospects and exciting developments for the testing world.

As Agile is changing from the "buzz-word" to "must-have" for most of the clients, I expect to see lot of traction in this area.  Historically the Agile has been more of the developers' baby, they seem to have been driving it. However lately the shift can be seen where the distinction between the developers and testers seem to have reduced significantly and we are looking at Agile teams where the team members are "all-rounders" with cross-skills.  Earlier it was nice to have teams like that and we aspired for such Agile teams and for lucky ones eventually the teams transformed into this using pairing and extensive training and coaching.

The testers now have been evolving and getting more development-centric, and developers getting hang of testing beyond Unit level.  Due to this leveling of the skills, now testers seem to placed in a better position to drive the development activity, some may term it is TDD but what I foresee is a "less intense" TDD. What do I mean by that?

TDD in pure sense would mean that we strictly write the tests first and that gives the scope of development to the developers and they write code that passes the test and stop at that.  A less intense TDD would be that you write the test first however it does not take the onus of describing the scope for the developers.  So developers would still refer to the SRS (reqt doc) in order to code, the difference being that they will have high priority tests ready for them to conformance to requirements.  Subsequently more testing would be done at integration and acceptance level to get the appropriate coverage as required.  So if you are not comfortable calling this variation of TDD then we can name is around the concept of early testing  (mind you, these are not static tests from V model).

This variation of testing gives ample powers to testers in an Agile (or traditional) methodology and also brings in concept of quality early in the SDLC.

The Future of Testing

http://saucelabs.com/blog/index.php/2010/11/the-future-of-testing/

Selenium Jobs Explode

IE9: users will soon be out of date, warns browser expert

Selenium User Meetup 2008: Lightning Talks

Article info : Soft Skills that Make a Tester

Article info : Soft Skills that Make a Tester

Agile Testing

Gartner Publishes BPM Cool Vendor List, Agility and Dynamism Are Key

Gartner Publishes BPM Cool Vendor List, Agility and Dynamism Are Key
By David Roe | Published Apr 15, 2010 Comments 1 comment
Featured Webcast: Leveraging Enterprise 2.0 on Your Intranet

Gartner has just published its list of ‘cool’ business process management (BPM) vendors for 2010. The list consists of five small companies that have made key advances in BPM over the course of the last year.

Taking as a caveat the disclaimer contained in the report that it does not guarantee any warranties or abilities of any software to perform any particular task — Gartner (news, site) reports tend to contain this as a matter of course — the report does throw up some interesting material, apart from the list of companies that it considers ‘cool’ in respect of BPM.
What Is BPM Anyway?

So what is BPM? As a term it is thrown around the web like cheap confetti, but it is as often as not applied to systems that are not truly BPM systems. According to Gartner, BPM implements processes that will directly improve enterprise performance and operational performance.

BPM software or suites is software that applies those processes and achieves the dual goals of best performance and enhanced efficiency.

Again by Gartner's definition, a BPM suite must include 10 areas of functionality:

1. Process execution and state management engine
2. Model-driven composition environment
3. Document and content interaction
4. User and group interaction
5. Basic connectivity
6. Business activity monitoring (BAM) and business event support
7. Simulation and optimization
8. Business rule management
9. System management and administration
10. Process component/registry repository

Taking this list of functionality and by analyzing the different abilities of the five, Gartner has managed to draw some conclusions about current BPM software that are probably worth noting.

Simply put:

* BPO providers are increasingly using BPM suites to implement process changes.
* BPM suites are increasingly being used as platforms to build solutions for process-specific tasks.
* BPM suites are increasingly being characterized by ease of use for workers not directly involved in IT.

‘Cool’ or ‘Uncool’?

Before plunging into the list it is worth noting what it means by a ‘cool’ vendor in the first place. Gartner defines a ‘cool vendor’ as one that is innovative, interesting, and has or will have a business impact on the future of IT.

The result is a list of companies that are not particularly well known, but which have developed software that has drawn the attention of Gartner at least.
Cool BPM - So who made it onto the list?
BizAgi

BizAgi, based in Bogota, Colombia, focuses on handing more responsibility to business users to improve processes. Its principal products include a free BPMN 1.2-based modeler, an Express Edition and its "model once, execute anywhere” edition which have all contributed to building a wide customer base that includes 150 academic institutions.
ICCM Solutions

ICCM Solutions provides an IT service management (ITSM) and service desk solution built on Metastorm BPM. Its principal product, e-Service Desk , which comes on-premises and as a hosted service, supports Information Technology Infrastructure Library (ITIL) processes across all phases of the business process life cycle using a BPMS that gives scope for continuous improvement in processes.
PNMsoft

PNMSoft is a member of the Microsoft Business Alliance, has developed processes that help business process outsourcing companies respond more efficiently and quickly to the changing process needs of their clients. It also focuses on improving end-to-end demand management processes between the business process outsourcing provider and its client organizations.
Questetra

Questetra provides a cloud-based solution to manage human workflow and improve worker productivity. It offers business people, who have no programming or systems knowledge, a simple to use workable platform for process improvement running on a shared Amazon EC2 infrastructure. It charges a US$ 10 per end user per month fee for this cloud service.
Whitestein Technologies

WhitesteinTechnologies applies processes that have the ability to self-adapt to changing business conditions. Focusing on an agile and dynamic world, the architecture, using a multiagent approach, ensures self-adaptive behaviour in processes whether those behaviours are proactive or reactive.
BPM in 2010 and Beyond

In January this year, Gartner published its 5 BPM predictions for 2010 and beyond. Combined they outlined BPM moving forward as agile and dynamic with technologies like discovery software, social software and mobile applications coming together and making them easier to use and more relevant for the end user.

In the five ‘cool’ vendors listed it is possible to find some, if not all, of these characteristics with emphasis on dynamic and agile deployment.

Article info : Software Risk Management Makes Good Business Sense

Article info : Software Risk Management Makes Good Business Sense

Project team structure - The Vedic way

Whenever we look at any project, we invariably see the various teams taking the center-stage at various point in the project life cycle. Where do we get this team structure, is it part of modern project management parlance? No necessarily, as we delved into our Indian vedas, we found similar description in the context not so far away from our existing team structure requirements. Lets me share some more...

In our vedas, it has been documented that people are of three basic types - Gyanyoga, Rajayoga and Bhaktiyoga. The Gyanyogis are the ones inspired by intellect, Rajayogis are inspired by Leadership and strategy and the Bhaktiyoga people have complete faith in their masters and are inspired by their devotion.

The start of any new project stems out from an idea that is mulled over and over to give a proper shape and plan. This is done by the people who belong to Gyanyoga category, these are the innovators and intellectuals. In a modern project these will be people in the board of directors or the advisers.

The idea is then converted to execution plan and the team of people are entrusted with the execution within the overall vision and strategy of the project. These are the Rajyogis, we call them the managers in our modern projects.

The team of people that will do the actual execution of the project should have full faith in their managers and should be devoted to the work that is assigned to them. The managers manage their day to day work to evaluate to ensure that the overall objective of the project is met. These people are Bhaktiyogis, also called team members in modern project teams.

So you see our vedas can educate us in all aspects of our lives including the professional...

Recession Blues - Companies, think twice and retain your employees...

The market is very turbulent and news of people getting laid off just does not seem to end, in fact the trend seem to be increasing. Pundits are saying that this is just the beginning and the gloom may last till 201o end. What should a company do if they do not have enough work for their employees? Should they feel themselves to be helpless and fire their people. For some companies it is an opportunity to 'cut the fat' and only retain the best talent that they have. Some have planned lay-offs and others are just doing it as knee jerk reaction to the market sentiments as the measure to cut cost. Is this the only option they have - the western model of hire and fire? We think this is not the right approach. After all it costs a lot of time, effort and money to train people - technology-wise, culture-wise and business-wise. Hence when the tide of recession turns, the company will need to go hammer & tongs to recruit people and reinvest time, effort and money to train the new recruits. Should there be some method to this madness and mayhem? We say yes, in such times companies need to be more sensitive to their employees, after all we are in India and companies should take this opportunity to truly treat their employees as family members. Here we propose a conceptual model to come out as a winner and leverage these hard times to imbibe our Indian cultural ethos in our companies and not just survive by firing people and cutting cost.

Numbers attached to this model:
1. Retain the employees with salary cut.
2. Find the differential between the amount saved if employees fired (A = All salary) vs. retaining employees with salary cut (C = Salary Cut). D = A-C.
3. Create of pool of such people and assign tasks with quantifiable results. (R = Worth of results).
4. We need to keep R >= D to make this work.

Variables affecting the model:
1. Resource pool count fluctuation
2. Unplanned entry and exit to the resource pool (temporary project assignment, resignations)
3. Other costs associated with the resources (seating cost etc.)
4. Top management support and commitment.
5. Measuring the results and converting it to quantifiable numbers

Gaps in Quality Processes in our daily lives

Once we know 'What' is to be done, 'How' becomes a very important aspect... rather THE IMPORTANT aspect... why I say this is because 'how' we do it decides the Quality of the 'what' we are doing.... Here 'what' may be anything... I mean 'ANYTHING'.... anything from the time I wake up to the time I hit the sack at the end of the day... it may be related to my brushing of teeth, eating my food, taking bath, driving to work to doing each and every task at my work place to.... And in Quality parlance, this 'How' is called 'Process'.... Hence 'Processes' are 'THE IMPORTANT' things in all aspects of our lives... Unfortunately we seldom realize this quality perspective consciously or even think about it, and this leads to what I term as "Quality By Chance"... Many a time this leads to poor quality in our daily lives - personal. professional and social... Many a times the immediate damage it causes might be minuscle but some times it is ever increasing if nothing is done about it, and may hurt us badly in long run. We typically try to adjust to these problems instead of finding solutions to them, at least not in the early stages.

Let's take a typical day of our life and see how following the quality processes or lack of it impacts on the overall quality of our lives. Starting early in the day our car-wash boys, there are about 350 cars in the compound and this group of 25 boys wash them everyday. They do not have any planned leaves and they just take off whenever there is a need or just like that. They can coordinate amongst themselves and take planned holidays and also the cleaning of cars will not get affected. Other part of it is that they all do washing individually to carry out every task, while this could be devided amongs them e.g. group1 can do the dusting, then group2 would do the wet-washing and then group3 will wipe and dry. This can happen, with a plan with parallel tasks and save on time and effort and also improve the quality of car washing.

The next task is at home, where set of 40 'Bais' (Housemaids) do the cleaning of around 300 flats. There work is highly unstructured and always tend to have some or other scheduling problem. Both, the employers and the 'bais' need to have better communication and structure to their tasks so that the work could be done more efficiently, at the right time and within allotted time.

After this we are ready to leave house for work, if we use our own transport (self-driven or driver), there are umpteen instance on our way where we get impatient (putting it mildly) and try to steal our right of way. This behavior is common across all section of drivers, literacy or financial standing not withstanding, nobody gives a second thought while blatantly not followingh the rules or processes set by the traffic authority. If we give way to others and follow the traffic rules, it may seem like that we are taking longer but it's overall effect would be saving us lot of time. I am sure this can be mathematically, scientifically and socially proven.

If we take autorickshaw, we will struggle to find the generous auto driver who would do ud the favor to take us in the direction where we want to go. If we are not lucky, we could be hunting for the ellusive auto for long time. I know there is an RTO rule that the autorickshaws need to ferry the pasengers whereever they demand to go but I also understand that it is not possible all the time. The simple solution to this could be that every auto carry a small sign of the route they are interested in goin towards. This will avoid the unnecessary haggling with the auto drivers and make our lived easier and less stressed.

Ego of testers - fuel to exploratory testing?

Why do some testers feel that they do not have to follow the test script blindly and they know better than that? Is asking them to stick to the test script, insulting to their intelligence? I am not too sure about the answers as it has many psychological and social layers.

I think there is a need to identify the inherent nature of any individual tester, if some feel that they would do better doing exploratory testing then we need to respect that. At the same time, effort must be made to validate their claim to assess their aptitude. Those testers who wish to be 'free-birds' should be not be forced to stick to pre-decided test script, it will certainly suppress their creativity. While we go about doing this, we got to ensure that we are not producing 'rogue-testers' (apologies if anyone is offended by this term). As saying goes from Spider-man movie, 'With great power comes great responsibility', so we need to be careful that we are not giving power into reckless hands. I would not like to use the term 'adhoc testing' as synonymous to Exploratory Testing, 'adhoc' for me signifies careless, sloppy and chaotic, things we do not relate to testing.

Now who would be ideal candidate for exploratory testing: someone who is well-verse with the application functionality and design, someone who has strong intuition, someone with strong analytical skills, someone who can design and modify the test design on the fly.

Exploratory Testing need not be against the ides of test scripting, rather it should be used in combination with test script based testing. And each of these teams would require testers with specific temperament and ability for successful execution.

Agile Manifesto

The Agile Manifesto reads as follows:

"We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value [the following]:

• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."

The Agile Manifesto has a list of general principles attached to it.

"We follow these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• We welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• We build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity—the art of maximizing the amount of work not done—is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

What's your interpretation of this?...

Agile Testing - Only for Agile Development methodology?

Before I introduce the new paradigm of the Agile Testing process for ALL development methodologies (including Agile), I am put across my thoughts over the traditional Agile Testing practice which exists in the realm of Agile development.

Simply put, it is the testing practice that follows the agile manifesto, treating development as the customer of testing. In this light the context-driven manifesto provides a set of principles for agile testing.


First let me list the Agile Development Methodologies that I a aware of:

• Extreme Programming (XP)
• Crystal
• Adaptive Software Development (ASD)
• Scrum
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• XBreed
  

Now let us look at the basic role of testing any project irrespective of the underlying development methodology:

• Testing is the headlights of the project- Where are you now? Where do you headed?
• Testing provides information to the team- This allows the team to make informed decisions
• A “bug” is anything that could bug a user- Testers don’t make the final call
• Testing does not assure quality- The team does (or doesn’t)
• Testing is not a game of “gotcha”- Find ways to set goals, rather than focus on mistakes
  

To focus on one of these, the common XP Practices are:

• Test-First Programming
• Pair Programming
• Short Iterations & ReleasesRefactoring
• “User Stories" Acceptance Testing
  

In Test-first programming:
Developers write unit tests before coding. This
- Motivates coding
- Improves design (reducing coupling and improving cohesion)
- Supports refactoring (Refactorting --> “Changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”.) - Make the simplest design that will work. Add complexity only when needed. Refactor as necessary. Refactoring requires unit tests to ensure that design changes (refactorings) don’t break existing code.
Many open-source test tools have been developed to support this. for e.g. xUnit


Pair Programming
All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code.


Iterative Test-Driven Development
Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops.It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.

Now lets look at Acceptance Testing
User stories (same purpose as that of use cases but are not the same) are short descriptions of features that need to be coded. One or more automated acceptance tests must be created to verify the user story has been correctly implemented. Acceptance tests verify the completion of user stories. Ideally they are written before coding.

Should users go along with this?
Some say that XP is an invitation to poor quality and an excuse for hacking. I think that XP is exciting and will improve the practice of testing in the industry.

Even better if we can have an independent Agile Testing process (that is 'independently agile') irrespective of the underlying Development Methodology... please watch this space for more on this.

Are you a tester?

We all are testers, makes you ponder? Yes, we all test, sometimes more than necessary but we do it all the time... checking if the house door is locked properly, establishing that the vegetables that we are buying are fresh, taking prospective car to test-drive, solving the test-papers from previous years before the exam, pressing the elevator again while it is already pressed and last but not the least, checking to ensure our fly is not open.


All of the above involve verifying and validating our certain expectations or fears (positive and negative testing) associated with the target that we are dealing with. These actions help us reaffirm our belief in the outcome that we expect, makes us tad little more comfortable. Comfortable in the realm of the related risk and cost associated in case of finding a "bug" later after the ownership is transferred to us. Thus the intensity and complexity of the testing varies based on the risk and cost. For example we should be comfortable if told that the sofa-set that we buying is tested to the effect of 99%, we may not feel the same if our airline says same thing for the aircraft that we are going to board (are we going to ask whether this is the 100th flight??!!)

Out need to test arise from the fact that we are humans and we can make mistakes, even machines can go wrong at times. We need to ascertain that the product or the process is as per the defined guidelines and standard, this leads to quality associated with the product. Higher the percentage at which the tests pass, higher is the quality. So essentially we are assuring the quality that we expect from the object under test. Also, to ensure the element of manual defect does not creep in, we tend to automate the tests, especially in case of the multiple repetitions of the test cases under various data sets and scenarios. This leads to test automation and agility in the quality assurance process.

I shall write some more associating the technology of testing and automation concepts with our daily lives. But aren't we all testers here?