Agile: I live by my principles

Principle 1

On Agile teams, we build the product well from the beginning, using testing to provide feedback on an ongoing basis about how well the emerging product is meeting the business needs.
This sounds like a small shift, but it has profound implications. The adversarial relationship that some organizations foster between testers and developers must be replaced with a spirit of collaboration. It’s a completely different mindset.

Principle 2

{Continuous testing is the only way to ensure continuous progress.}

Principle 3

The need to get all testing done in an iteration may mean that the team simply cannot do as much in each sprint as they originally thought. If this is the case, then Agile has made visible the impedance mismatch between test and dev that already existed. And that means that the team was not going as fast as they thought. They appeared to be going quickly because the developers were going fast. But if the testing isn't done, then the features aren't done, and the team just does not have the velocity they think.

Principle 4

Measure the time between when a programmer writes a line of code and when someone or something executes that code and provides information about how it behaves. That’s a feedback loop. If the software isn’t tested until the very end of a long release, the feedback loops will be extended and can be measured in months. That’s too long. Shorter feedback loops increase Agility. Fortunately, on Agile projects the software is ready to test almost from the beginning. And Agile teams typically employ several levels of testing to uncover different types of information.

Principle 5

Principle 6

This principle is an example of the discipline that Agile teams have. It takes tremendous internal discipline to fix bugs as they are found. If it’s a genuine bug, as opposed to a new story, it is fixed within the iteration. To do otherwise is like cooking in a filthy kitchen: it takes longer to wade through the mess to do the cooking, and the resulting food may or may not be edible.

Principle 7

Instead of writing verbose, comprehensive test documentation, Agile testers:

• Use reusable checklists to suggest tests

• Focus on the essence of the test rather than the incidental details

• Use lightweight documentation styles/tools

• Capturing test ideas in charters for Exploratory Testing

• Leverage documents for multiple purpose

Principle 8

Agile teams don’t count something as “done,” and ready to be accepted by the Product Owner or Customer until it has been implemented and tested.

Principle 9

Tests provide concrete examples of what it means for the emerging software to meet the requirements. Defining the tests with the requirements, rather than after, and using those tests to drive the development effort, gives us much more clear done criteria and shared focus on the goal.

Agile Development

There are three groups of people involved in a software project

• Project Managers 
• Developers
• Testers

If we consider the people who really work on the project, these are the Developers and the Testers. Both of these lie under the category engineers but the irony is both of them are looked upon as the North Pole and the South Pole. These two group of people cant stand each other. Its a Tom and Jerry kind of relationship. It is said that opposites attract but these two groups attract just to prove their supremacy over the other.

Now lets think about the the tagline in the above picture, "They are not so much different but they have different path for the same goal, to improve the QUALITY". Here Quality is referring to the correctness of the end product to be submitted to the customer. That is what matters to both and both the groups have their own way of ensuring the same.

Its very important for the Testers and Developers to be on the same path while the application development and testing is in progress. There can be a scenario where these two groups can be on different paths and then the end product will be something that will be hilarious to common man and not so hilarious for the customer.

Agile Techniques are useful to bring the Testers and Developers on the same path. Agile development recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Testers on agile teams lend their expertise in eliciting examples of desired behavior from customers, collaborating with the development team to turn those into executable specifications that guide coding.
The term "Agile" was introduced in 2001 at the 'snowbird' meeting to describe a variety of methods including Scrum. The main purpose of Agile Development is served for the projects that support Iterative Development. Agile teams really do need testers – or at least people who have strong testing skills. But there is a small grain of truth in the idea that Agile teams don’t need QA.  That’s because Agile teams don’t need is QA acting as a Quality Police.  The business stakeholder – whether the Scrum Product Owner or the XP “Customer” – define what’s acceptable and what’s not.  The QA or Test group supports the business 

stakeholder by helping them clarify acceptance criteria and understand risks.

Software Testing ???

If we think of how testing originated, then we may go on thinking for years and we may never find the right answer. what i feel is that as a human being we all have the TALENT inside us to test. We generally perform testing for everything that we can think of, from a needle to a large machine in our house. Looking or seeing any product is testing. There is a Tester in each and everyone of us. The cartoon below might just allow us to identify the tester inside us.

Reactions:

In Childhood, I always wanted to be someone who will have an impact on the society. I wanted to fight criminals or a sportsperson like Sachin Tendulkar. But now i have ended up being a Software Tester. And I am Loving it :)

This is what happened to me 

Software testing is the process of validating and verifying that a software program/application/product:

1. meets the requirements that guided its design and development;
2. works as expected;
3. can be implemented with the same characteristics.
4. satisfies the needs of stakeholders

{"Verification and validation are two different processes"}

Now for every process there needs to be a systematic way of representing the process. In Software Testing field this systematic way is called the Software Testing Life Cycle (STLC). Lets look at how this thing mentioned in Green looks like

This is how I live :)

Do Provide your comments and queries. This will make us learn more :)