WHAT IS AGILE?

Agile is about being open about what we’re capable of doing, and then doing it
– Kent Beck


Value System :
• People
• Collaboration
• Honesty
• Trust


Attitude :
Thinking guided by principles and reflected in behaviour


Simple Framework for dealing with change :
• Self-organisation
• Visibility
• Inspection
• Adaptation


Adaptive Ecosystem :
Tightly couples self-organising Team to a Product Owner

Test Management tool : Zephyr

Zephyr is a Next Generation Test Management tool and is based around the concept of Desktops & Dashboards.

Every role in a QA Department has a customized Desktop with relevant applications that allow them to do their jobs faster and better, as they all share data from a centralized repository and communicate via a collaborative backbone.

Dashboards are automated and live, keeping the whole company updated on every aspect of testing and product quality.

Agile testing :

These same imperatives can underlie a practice of Agile Testing. Agile Testing would most obviously apply to Agile development projects, but it should work - perhaps less well - on conventional projects too.

The first step is to abandon the notion that others communicate at us with requirements and design documents, and that we communicate back at them with test plans and bug reports. We've always realized that the documents we base our tests on are flawed - incomplete, incorrect, and ambiguous - but our reaction has been to insist, in our usually powerless way, that the document producers do better. But now we can see that "better" will never be good enough. Documents can't be an adequate representation of working code. So we can let free of the illusion that documents will save us. We can view them as they are: interesting texts, partly fictional, often useful.

Rather than communicating at people, we need to join and encourage the ongoing project conversation. Testers and developers should sit in the same bullpen, share offices, or occupy alternate cubicles. Many testers should be assigned to help particular developers, rather than to test pieces of the product. The test plan should evolve through a series of what James Bach calls "drop-in meetings" - short, low-preparation, informal discussions of particular topics. These will result in what James Tierney calls "test doclets" - short memos addressing a specific issue. Test status should be reported via big, public, simple-to-read charts that answer specific development questions like "what parts of the product can we stop worrying about?"

Conversation with the customer is as important as with the developers. Remember: the customer is trying to figure out what they need, want, and are getting, in large part by trying out the working code. Testers should sit down with them as they do that. Creating some tests together is an excellent way for both of you to learn what matters - and also to describe it to the developers in a clear and concrete way.

That's an instance of the Hands-On Imperative. Exploit that with developers as well. The normally strained relationship with them will be less so if they see you wanting to get started testing, even on something unfinished, especially if your expressed goal is to help them improve and complete it. They'll value tests they can run as they continue development.

Agile Testing is not the answer for all projects. Neither is any of the Agile Methods named in the first paragraph. No single approach can be. But now is a time when we need more experimentation with project styles, the more so because there's an increasing move toward standardization of software development practices, a move that in my opinion is entirely premature.

Testing GUI Applications - By Kapil Sharma

GUIs have become the established alternative to traditional forms-based user interfaces.

GUIs are the assumed user interface for virtually all systems development using modern technologies.

There are several reasons why GUIs have become so popular:

• GUIs provide the standard look and feel of a client operating system.
• GUIs are so flexible that they can be used in most application areas.
• The GUI provides seamless integration of custom and package applications.
• The user has a choice of using the keyboard or a mouse device.
• The user has a more natural interface to applications: multiple windows can be visible simultaneously, so user understanding is improved.
• The user is in control: screens can be accessed in the sequence the user wants at will.

Test Principles Applied to GUIs :

Our proposed approach to testing GUIs is guided by several principles, most of which should be familiar. By following these principles we will develop a test process which is generally applicable for testing any GUI application. Note that the proposed test approach does not cover white-box testing of application code in any depth. This approach concentrates on GUI errors and using the GUI to exercise tests so is very-oriented toward black-box testing.

# Focus on errors to reduce the scope of tests

We intend to categorize errors into types and design test to detect each type of error in turn. In this way, we can focus the testing and eliminate duplication.

# Separation of concerns (divide and conquer)

By focusing on particular types of error and designing test cases to detect those errors, we can break up the complex problem into a number of simpler ones.

# Test design techniques where appropriate

Traditional black box test techniques that we would use to test forms based applications are still appropriate.

# Layered and staged tests

We will organize the test types into a series of test stages. The principle here is that we bring tests of the lowest level of detail in components up front. We implement integration tests of components and test the integrated application last. In this way, we can build the testing up in trusted layers.

# Test automation...wherever possible

Automation most often fails because of over-ambition. By splitting the test process into stages, we can seek and find opportunities to make use of automation where appropriate, rather than trying to use automation everywhere.

GUI (Graphical User Interface) applications are software applications that provide a visual interface for users to interact with the underlying functionality of the software. Testing GUI applications involves checking that the software functions correctly, looks visually appealing, and is easy to use.

Here are some common approaches to testing GUI applications:

Manual testing: This involves manually interacting with the application's graphical user interface and performing tests to ensure that all functionality works as expected. Manual testing can be time-consuming, but it allows testers to evaluate the application from a user's perspective and identify any usability issues.

Automated testing: Automated GUI testing involves using software tools to simulate user interactions with the application's graphical user interface. This approach is faster and more efficient than manual testing, and it can help identify bugs and issues that might be missed during manual testing. Automated GUI testing can also be used to perform regression testing to ensure that new updates or changes to the application do not break existing functionality.

Accessibility testing: Accessibility testing involves checking that the application's graphical user interface is usable by individuals with disabilities, such as those who are visually impaired. This testing may involve using assistive technology tools, such as screen readers or magnifiers, to ensure that the application's graphical user interface is accessible to all users.

Usability testing: Usability testing involves evaluating the application's graphical user interface to ensure that it is easy to use and navigate. This testing may involve conducting user surveys or running focus groups to gather feedback from users and identify any areas where the application's graphical user interface could be improved.

Performance testing: Performance testing involves testing the application's graphical user interface to ensure that it is responsive and fast. This testing may involve stress testing, where the application is tested under heavy loads to ensure that it remains stable and responsive.

Overall, testing GUI applications involves a combination of different approaches to ensure that the software is reliable, easy to use, and visually appealing. 

Inability to find all faults

A problem with software testing is that testing all combinations of inputs and preconditions is not feasible when testing anything other than a simple product.

This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing.

More significantly, parafunctional dimensions of quality--for example, usability, scalability, performance, compatibility, reliability--can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another.

Testing Measurement :

Any measurement program can be divided into two parts. The first part is to collect data, and the second is to prepare metrics/chart and analyse them to get the valuable insight which might help in decision making. Information collected during any measurement program can help in:

• Finding the relation between data points,
• Correlating cause and effect,
• Input for future planning.

Normally, any metric program involves certain steps which are repeated over a period of time. It starts with identifying what to measure. After the purpose is known, data can be collected and converted in to the metrics. Based on the analysis of these metrics appropriate action can be taken, and if necessary metrics can be refined and measurement goals can be adjusted for the better.

Test Strategy

Test Strategy : It is a way to do testing of certain functions of an application or some time whole application, in nut shell it is not a test plan it is a extended sub-plan or certain specific pre-determined set of steps for testing of the module or system.