Agile Testing ,Lean principles

vodQA Bangalore

2012-01-19T01:07:00.000-08:00

vodQA, the Thoughtworks testing conference is happening in Bangalore on 11 Feb 2012.The format seems to be quite interactive and 11 Feb looks quite an exciting day for those who see testing as the vital cog for IT and business agility.

The key thing is - there is no entry barrier as the conference participation is free.

I am participating in a panel discussion along with some of my esteemed colleagues who along with them bring plethora of experience on the topic of agile testing.The discussion should bring out paradigms, challenges , adoption patterns ,advancement in practice and toolsets etc.

There are lightning talks, interactive agile games and showcase of agile testing.

I am looking at the opportunity to exchange thoughts and experiences with participants.

Here is the link to event-page

http://testing.thoughtworks.com/events/agile-testing-teams-and-enterprises

Why Testing is perceived as least agile: What needs to change

2008-06-09T01:50:00.000-07:00

A story about how testing failed the business

I was on an agile project. The test team started with great objective of keeping pace with test automation. Iteration 1 to 3 were quite uneventful, every test designed was automated. By this time Customer had first feedback from actual user. Entire UI design was changed, none of the tests were running, development team made changes as per the new UI requirement in a week, it took 2 weeks for automation team to change scripts to make these pass. By this time the test team had 2 weeks of automation backlog. Few more changes and backlog had increased to 6 weeks on a 12 week long project. Project team was getting nervous because of lack of regression testing, and pulled every tester in manual testing.
Later, some business users and developers were available to provide some additional bandwidth. But the automated tool was difficult to learn, proprietary in nature, looking at the scripts it was difficult to understand what the tests were trying to achieve as tests were programs. We couldn’t leverage skills of available resources. Business wanted to push through another release to preempt competition. Lack of automation meant delivery organization needed more time in manual testing effort.
Business was under dilemma- go with release date,may create loss of face or Don’t release give the advantage to competition on a platter.

This is not an isolated case nor is it going to be a one off occurrence in future. As long as current state of testing allows above situations occur, testing will be seen as non agile, may be party poopers or associated with waste.

Business and IT need to think testing strategically

If we see testing in the light of what business or organizations want to do, this perception might change. Testing needs to use business needs to improve efficiency in testing. There are some key business driver for testing as I see from my experience -

• Reduce or stabilize the cost of testing

• Improve release cycle to production. (Time to market, beat the competition)

• Reduce time spent in regression testing

• Reduce defect escape rate - Improve the quality of deployed application.

• Early Feedback of what application does and doesn’t do, allowing business to make informed decisions.

Testing should address Business and IT needs

Well, looking at the above business driver and putting my waste/efficiency hat, I think this is what roughly translates into requirement for testing –

• Testing must keep pace with development

• Test asset created must be able to run on multiple development and deployment platforms when any change happens.

• Business context should drive testing; business must be involved in testing.

• Test must be executable

• Test design and execution happens in real time

• Testing results reported in a way business understands

• Testing should not hinder change in business directions

Testing is a multi skill activity: Testing needs collaboration and innovation

I think I clearly understand the requirement now, however I see there are gaps, sometimes big gaps in the current state of tools and practices which will prevent me to achieve what I wanted to achieve –
• Key Business values and features are often not adequately tested

• Business is not involved in testing

• Test Automation tools lack the ability to write tests in language of business, The intent of tests are not clear.
• Converting test specification or intent of tests into executable tests often requires building a test framework from the ground up.

• Some automation Tools don’t support the programming language used by developers, hindering leveraging developer skills.

• Making changes in executable tests are non trivial activities. Test Automation Engineers spend most of their time maintaining tests. (Waste) rather than adding more tests (Value).

• Cost of tools and lack of flexibility of tools to support multiple programming languages means that organizations can’t leverage combined efforts of development and testing team.

Clearly, this means that testing should be far more collaborative than what it is now and requires far more collaborative effort in building tools and practices which leverages strength of individuals on the team and just not the testers, to make it effective and efficient.

Bringing Test Automation Early in Development lifecycle:Looking beyond Test Automation tool

2008-05-05T01:42:00.000-07:00

While everyone agrees the benefits of early and continuous automated regression testing, few agree that test automation in early part of application development life cycle is such a good idea because of the effort and skill sets involved in making this happen. Having a test suite and infrastructure which allows deterministic and repeatable run is a key success criterion. Keeping test maintenance cost to a minimum under rapidly changing application is another challenge .One of the reasons of test automation not being successful early in application development lifecycle is not thinking beyond test automation tool. There are few basic problems where thinking beyond functional test automation tool will help and allow testing teams to do early test automation effectively. I have used few of the strategies listed below with relative success-

Dealing with changing functionality nightmare

– Right happy path tests, once stable include others

– Find a roadmap from customers/ BAs -It’s worthless to automate tests which fail before being useful. Knowing the functionality road map helps in picking up a test for automation at the right time.

Dealing with frequent application schema changes

– Baseline data and apply incremental changes to schema as schema changes

– In case database structure is governed by object models, Test should build the data through application layer, till there are few changes in object Model. Once object model that take a dump of your base lined database and apply incremental schema changes.

Dealing with Brittle UI

– Use a tool which can be integrated in an IDE being used by developers, so that developers can fix it when they are making changes.

– Don’t Hard code ObjectIDs, Maintain in a common object Repository.

– Don’t try automating, try API route, test all business rules. Be aware - don't take the API plunge lightly as it may require precious development resources and you might have to throw them later on. Do a trade off between no automation vs. automation through API carefully.

Dealing with in deterministic response from external application interfaces- Create stubs which return precooked responses based on some token in the request but the format of response is governed by interface definition.