Agile methodology over the Waterfall method

1. Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
2. Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.
3. Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.
4. Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.
5. However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

Values of Agile Modeling

The five values of Agile Modeling (AM) are:
1.Communication : Models promote communication between your team and your project stakeholders as well as between developers on your team.
2.Simplicity : It’s important that developers understand that models are critical for simplifying both software and the software process—it’s much easier to explore an idea, and improve upon it as your understanding increases, by drawing a diagram or two instead of writing tens or even hundreds of lines of code.
3.Feedback : Kent Beck says it best in Extreme Programming Explained: “Optimism is an occupational hazard of programming, feedback is the treatment.” By communicating your ideas through diagrams, you quickly gain feedback, enabling you to act on that advice.
4.Courage : Courage is important because you need to make important decisions and be able to change direction by either discarding or refactoring your work when some of your decisions prove inadequate.
5.Humility : The best developers have the humility to recognize that they don't know everything, that their fellow developers, their customers, and in fact all project stakeholders also have their own areas of expertise and have value to add to a project. An effective approach is to assume that everyone involved with your project has equal value and therefore should be treated with respect. Huet Landry suggests the concept of "Other Esteem", instead of "Self Esteem", where you treat the opinions of others as if they have more value than yours. With this approach your first reaction to another's idea will be most positive.

Accessibility Testing

Testing that determines if software will be usable by people with disabilities.

It is also called as ADA testing or 508 complaiance testing.(American disabilities act). Testing the application with respect to physically challenged persons point of view is called accessibility tesing..

Such as blindness, low or restricted vision, or color blindness. User with visual impairments uses assistive technology software that reads content loud. User with weak vision can also make text larger with browser setting or magnificent setting of operating system.

To know more plz visit Accessibility more

OR

To know more plz visit Testing for Accessibility MSDN

Unit Test

Unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure.

Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended.

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.

The most common approach to unit testing requires drivers and stubs to be written. The driver simulates a calling unit and the stub simulates a called unit. The investment of developer time in this activity sometimes results in demoting unit testing to a lower level of priority and that is almost always a mistake. Even though the drivers and stubs cost time and money, unit testing provides some undeniable advantages. It allows for automation of the testing process, reduces difficulties of discovering errors contained in more complex pieces of the application, and test coverage is often enhanced because attention is given to each unit.


For example, if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places:
1) Is the error due to a defect in unit 1?
2) Is the error due to a defect in unit 2?
3) Is the error due to defects in both units?
4) Is the error due to a defect in the interface between the units?
5) Is the error due to a defect in the test?
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole.

Installation Testing

Installation testing is a kind of quality assurance work in the software industry that focuses on what customers will need to do to install and set up the new software successfully. The testing process may involve full, partial or upgrades install/uninstall processes.

This testing is typically done by the software testing engineer in conjunction with the configuration manager. Implementation testing is usually defined as testing which places a compiled version of code into the testing or pre-production environment, from which it may or may not progress into production. This generally takes place outside of the software development environment to limit code corruption from other future releases which may reside on the development network.

OR

Installation testing (in software engineering) can simply be defined as any testing that occurs outside of the development environment. Such testing will frequently occur on the computer system the software product will eventually be installed on.

Whilst the ideal installation might simply appear to be to run a setup program, the generation of that setup program itself and its efficacy in a variety of machine and operating system environments can require extensive testing before it can be used with confidence.

In distributed systems, particularly where software is to be released into an already live target environment (such as an operational web site) installation (or deployment as it is sometimes called) can involve database schema changes as well as the installation of new software. Deployment plans in such circumstances may include back-out procedures whose use is intended to roll the target environment back in the event that the deployment is unsuccessful. Ideally, the deployment plan itself should be tested in an environment that is a replica of the live environment. A factor that can increase the organisational requirements of such an exercise is the need to synchronize the data in the test deployment environment with that in the live environment with minimum disruption to live operation.

Stochastic Testing

Stochastic testing is the same as "monkey testing", but stochastic testing is a lot more technical sounding name for the same testing process.

Stochastic testing is black box testing, random testing, performed by automated testing tools. Stochastic testing is a series of random tests over time. The software under test typically passes the individual tests, but our goal is to see if it can pass a large number of individual tests.

Difference between Monkey testing an Ad-hoc testing

Monkey Testing : Monkey is random testing, you don't know about the application.
Ad-hoc Testing : Ad-hoc is informal testing where you know about the application well in hand.

Monkey Testing : Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.
Ad-hoc testing : A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well.

Monkey Testing

Testing by means of a random selection from a large range of inputs and by randomly pushing buttons, ignorant on how the product is being used.

Or

Testing a system or an Application on the fly, i.e. just few tests here and there to ensure the system or an application does not crash out.

Or

In computer science, a monkey test is a unit test that runs with no specific test in mind. The monkey in this case is the producer of any input. For example, a monkey test can enter random strings into text boxes to ensure handling of all possible user input or provide garbage files to check for loading routines that have blind faith in their data.

Or

Testers use the term monkey when referring to a fully automated testing tool. This tool doesn’t know how to use any application, so it performs mouse clicks on the screen or keystrokes on the keyboard randomly. The test monkey is technically known to conduct stochastic testing, which is in the category of black-box testing.

There are two types :
1) Smart Monkeys
2) Dumb Monkeys

1) Smart Monkeys : Are valuable for load and stress testing.
                             They will find a significant number of bugs.
                             Very expensive to develop.

2) Dumb Monkeys : Inexpensive to develop.
                             Able to do basic testing.
                             Can find only few bugs.

Globalization Testing

The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems.

Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.

Proper functionality of the product assumes both a stable component that works according to design specification, regardless of international environment settings or cultures/locales, and the correct representation of data.

For more details please visit :
http://www.onestoptesting.com/globalization-testing/

Localization Testing

Localization (L10N) is the process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets.

This process involves translating all native language strings to the target language and customizing the GUI so that it is appropriate for the target market. Depending on the size and complexity of the software, localization can range from a simple process involving a small team of translators, linguists, desktop publishers and engineers to a complex process requiring a Localization Project Manager directing a team of a hundred specialists.

Localization is usually done using some combination of in-house resources, independent contractors and full-scope services of a localization company.

For more details please visit : http://www.onestoptesting.com/localization-testing/

Customer Test

This is another term for an acceptance test.

GUI Test

GUI tests test the graphical user interface. GUI tests are considered functional tests. Applications are used to simulate users interacting with the system such as entering text into a field or clicking a button. Verifications are then made based on the response from the UI or system.

Developer Test

This is another term for a unit test.

Unit Test

A unit test is a method used to verify that a small unit of source code is working properly. Unit tests should be independent of external resources such as databases and files. A unit is generally considered a method.

Agile Testing

Emphasizing testing from the perspective of customers who will utilize the system.

Agile testing does not emphasize rigidly defined testing procedures, but rather focuses on testing iteratively against newly developed code until quality is achieved from an end customer's perspective.

The Word Agile means "Moving Quickly" and this explains the whole concept of Agile Testing.

Testers have to adapt to rapid deployment cycles and changes in testing patterns.

Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing.

Testers are no longer a form of Quality Police. Testing moves the project forward leading to new strategy called Test Driven Development. Testers provide information, feedback and suggestions rather than being last phase of defense.

Testing is no more a phase; it integrates closely with Development. Continuous testing is the only way to ensure continuous progress.

Manual testing, particularly manual exploratory testing, is still important.

Agile teams typically find that the fast feedback afforded by automated regression is a key to detecting problems quickly, thus reducing risk and rework.

Integration Testing

Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.

Approaches of integration testing :

Top Down Testing :
An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.

Bottom Up Testing :
An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

Load Testing

Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".

A load test is usually conducted to understand the behavior of the application under a specific expected load. This load can be the expected concurrent number of users on the application performing a specific number of transactions within the set duration. This test will give out the response times of all the important business critical transactions. If the database, application server, etc are also monitored, then this simple test can itself point towards the bottleneck in the application.

Volume Testing

Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.

For example :
if you want to volume test your application with a specific database size, you will expand your database to that size and then test the application's performance on it.

Stress Testing

This kind of test is done to determine the application's robustness in times of extreme load and helps application administrators to determine if the application will perform sufficiently if the current load goes well above the expected load.
Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

For example :
A web server may be stress tested using scripts, bots, and various denial of service tools to observe the performance of a web site during peak loads.

Software Testing Types

1. Black box testing : Internal system design is not considered in this type of testing. Tests are based on requirements and functionality.
2. White box testing : This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.
3. Unit testing : Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. May require developing test driver modules or test harnesses.
4. Incremental integration testing : Bottom up approach for testing i.e. continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. Done by programmers or by testers.
5. Integration testing : Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
6. Functional testing : This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application.
7. System testing : Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system.
8. End-to-end testing : Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
9. Sanity testing : Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.
10. Regression testing : Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types.
11. Acceptance testing : Normally this type of testing is done to verify if system meets the customer specified requirements. User or customers do this testing to determine whether to accept application.
12. Load testing : It’s a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.
13. Stress testing : System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load.
14. Performance testing : Term often used interchangeably with ’stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this.
15. Usability testing : User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.
16. Install/uninstall testing : Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.
17. Recovery testing : Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
18. Security testing : Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.
19. Compatibility testing : Testing how well software performs in a particular hardware/software/operating system/network environment and different combinations of above.
20. Comparison testing : Comparison of product strengths and weaknesses with previous versions or other similar products.
21. Alpha testing : In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.
22. Beta testing : Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.