Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development Method was developed in the U.K. in the mid-1990s. Its a ' Existing Agile Method '. It is an outgrowth of, and extension to, rapid application development (RAD) practices. DSDM boasts the best-supported training and documentation of any ASDE10, at least in Europe.

DSDM’s nine principles include active user involvement, frequent delivery, team decision making, integrated testing throughout the project life cycle, and reversible changes in development.

Existing Agile Methods

Dynamic Systems Development Method (DSDM):

The Dynamic Systems Development Method was developed in the U.K. in the mid-1990s.It is an outgrowth of, and extension to, rapid application development (RAD) practices. DSDM boasts the best-supported training and documentation of any ASDE10, at least in Europe. DSDM’s nine principles include active user involvement, frequent delivery, team decision making, integrated testing throughout the project life cycle, and reversible changes in development.

Agile Team Members :

More about Agile Team Members :

Agile ScrumMaster : 

1.) Knows Scrum philosophy and practices.

2.) Works to ensure team stays on-process.

3.) Facilitates work of Product Owner and Development Team.

4.) Protects the team from impediments.

5.) Personal commitment to the team.

Bumptop Beta Testing Feedback:

Today I got a mail Anand, the man behind the idea Bumptop (http://bumptop.com) to be part of there BumpTop private beta! 

So, I have done some observations which I would like to share with world.  

Things I would like to saw on BT-Apps. 

I have added a modified screenshot of my BT-Apps. 

My First observations for this beta:

1.)  When I load BT-Apps. all my desktop icons looks very mesh up on BT-Apps. What I mean to say is that it whould be bettter that BT-Apps only displays the name of folder of files when user put his/her mouse cursor on folder or file. 

2.)  We can also add a small search box either on left or right sides on BT-Apps. it can be place at top left corner or top right corner of BT-Apps.

3.)  Another thing is that, I would like to see in future BT-Apps. is a clear exit button on right side corner (down). This will help user to easy switch between BT-Apps and other OS apps.

Chrome_Crash_Event_ID_Information:

For security reasons.

I have to hide the computer name. 

Data in Bytes:

0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 48 61 6e 67 ion Hang
0010: 20 20 63 68 72 6f 6d 65 chrome
0018: 2e 65 78 65 20 30 2e 30 .exe 0.0
0020: 2e 30 2e 30 20 69 6e 20 .0.0 in 
0028: 68 75 6e 67 61 70 70 20 hungapp 
0030: 30 2e 30 2e 30 2e 30 20 0.0.0.0 
0038: 61 74 20 6f 66 66 73 65 at offse
0040: 74 20 30 30 30 30 30 30 t 000000
0048: 30 30 00  

Another Google Chrome web browser issue reported.

First Isssue No. : 700

Second Issue No. : 997

Scrren shot of the second issue attached.

Chrome Bug Tracker : 

This is the actual Chrome bug tracker.

 

Google Chrome

Google started its own web browser : Chrome

Yesterday, I was testing some youtube application on this new browser and suddendly I found a crash on the browser plug-in side. 

The Adobe shockwave plug-in broke down hence the whole you tube apps stops working. 

So here it was : BUG-700.

More about SCRUM:

Scrum is really a project management methodology to facilitate agile software development, and enable the creation of self-organizing agile teams. A ScrumMaster is like a traditional project manager in the sense that he/she oversees the centralization of team communication, requirements, schedules and progress.

But it is also very different because his/her main responsibility is to facilitate team communications and provide guidance and coaching, while removing impediments to the ability of the team to deliver its goals. Unlike a traditional project manager, the ScrumMaster doesn’t direct the team, because an agile team is based on the philosophy that a team member is committed to the other team members, not to a management authority.

Test closure activities : 

During test closure activities, we collect data from completed test activities to consolidate experience, including checking and filing testware, and analyzing facts and numbers. We may need to do this when software is delivered. We also might close testing for other reasons, such as when we have gathered the infor-mation needed from testing, when the project is cancelled, when a particular milestone is achieved, or when a maintenance release or update is done.

Test closure activities include the following major tasks:

1.)  Check which planned deliverables we actually delivered and ensure all incident reports have been resolved through defect repair or deferral.

2.)  Finalize and archive testware, such as scripts, the test environment, and any other test infrastructure, for later reuse.

3.)  Hand over testware to the maintenance organization who will support the software and make any bug fixes or maintenance changes, for use in con firmation testing and regression testing.

4.) Evaluate how the testing went and analyze lessons learned for future releases and projects.

Scrum : In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with each other to get a job done. In software development, the job is to put out a release. Scrum for software development came out of the rapid prototyping community because prototypers wanted a methodology that would support an environment in which the requirements were not only incomplete at the start, but also could change rapidly during development. Unlike XP, Scrum methodology includes both managerial and development processes.

Two agile software development methodologies :

The most widely used methodologies based on the agile philosophy are XP and Scrum.

These differ in articulars but share the iterative approach described above.

XP :

XP stands for extreme programming. It concentrates on the development rather than managerial aspects of software projects. XP was designed so that organizations would be free to adopt all or part of the methodology.

XP development :

XP projects start with a release planning phase, followed by several iterations, each of which concludes with user acceptance testing. When the product has enough features to satisfy users, the team terminates iteration and releases the software.

Agile methodologies embrace iterations. Small teams work together with stakeholders to define quick prototypes, proof of concepts, or other visual means to describe the problem to be solved. The team defines the requirements for the iteration, develops the code, and defines and runs integrated test scripts, and the users verify the results.

Verification occurs much earlier in the development process than it would with waterfall, allowing stakeholders to fine-tune requirements while they’re still relatively easy to change.

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.