Agile testing uncovered…

I have been a part of agile testing for quite some time now and have experienced its edge over the traditional style of testing. Over the years I have seen that most companies shy away from this form of testing for one or a combination of these reasons; i.e., implementation issues, lack of awareness, risk involved or simply just a resistance and hesitance to change. Through my post below I am attempting at assuring readers that agile testing is not only simple and extremely effective but also goes a long way in achieving delight in your testing strategy.

What is Agile testing?

Agile testing likes its development counterpart refers to a concept of breaking down the entire process into small pieces in a bid to achieve results as quickly as possible. Thus, agile testing is nothing but validating requirements in the shortest time possible. Product Owner’s, Scrum Master’s, Agile BA’s, Agile Tester’s, Agile Developer’s, Agile Architect’s, and Agile Resource Managers can all implement this methodology of testing.

Some advantages of Agile Testing

• Ensures time and budget optimization as all phases of SDLC need to be completed quickly.
• Ensures all change requests or enhancements are implemented without budget constraints with minimum impact on time to market
• Ensures good coordination due to daily nature of activities thus determining issues & gaps in requirements in advance with countermeasures deployed rapidly
• Ensures comprehensive testing in situations where business requirements documentation is hard to quantify.
• Ensures that the product delivered is in line with business needs and timeframes.

Some learning’s

• When Agile testing is weaved into a project early in the product development cycle, it ensures that time/ work estimates are accurate thus ensuring that deadlines are met. This is primarily due to the fact that testers are exceptionally good at clarifying requirements and identifying alternative scenarios.
• Deploying Agile testing right at the beginning of projects also ensures that developers write their code to pass tests as the test approach is known well in advance.
• Early stage Agile testing also is an opportunity to bring in automated acceptance testing into the process. This is especially relevant when the development is also in the Agile mode.
• Testers are always one step ahead as they design the cases for upcoming release also, thus enabling developers to pick up at the start of the iteration.

Things to watch out for

• Project quality management is hard to implement and quantify unless the test team are able to conduct regression testing after each release.
• Attrition as always in the development cycle can have an adverse effect on project development.
• In the case that Agile Scrum is being used, it can be the leading cause of scope creep, when not managed properly.

All in all when managed properly, Agile Testing can give most projects the edge in ensuring that ROI on products can be seen much earlier than expected while keeping costs down to a minimum. I would love to write more about my experiences with agile testing but before I do, I would like to hear the views of readers in order to make this a more interactive exchange. How do you view Agile Testing?

Vikram Deshmukh |Senior Manager | Zen Test Labs

Software Quality, Development and Coding Standards…

The best applications are those that are not only coded properly but also easy to add, debug and maintain. The concept of ‘maintainable code’ is easy to contemplate about but difficult to practice. Developers code in specific and individualistic styles. Their styles of coding become their second nature and they continue to use that in everything they create. Such a style might include the conventions used to name variables and functions ($password, $Password or $pass_word for example). Any style should ensure that the team can read the code easily.

However, what happens when we start to code bigger projects and introduce additional people to help create a large application? Conflicts in the way you write your code will most definitely appear.

This is where the concept of ‘CODING STANDARDS’ comes into play.

Coding standards are very articulate and deeply formulated to be consistent and when developers follow these standards, it makes the end result more uniform, even if different parts of the application are written by different developers. Knowing these standards and the language is always easy, but the catch is in deciding which standard to apply when & where.

I have found that the entire process of testing & quality assurance becomes relatively simpler when developers have followed coding standards. This also goes a long way in improving the performance of the application. When coding standards have been adhered to it results in easy and quick grasping of what the application is supposed to do and what it is not supposed to. During maintenance phase, it undoubtedly, enhances readability which leads to better maintainability. By adhering to these standards testers do not feel disconnected or bowled over when they begin working with the application. I believe it’s even more relevant in the current scenario, when different processes of applications are built by different set of developers (internal teams, vendors, etc).

Some of the secure coding practices, I believe that are high priority:

  • Validate input data
  • Heed compiler warnings
  • Architect and design for security policies
  • Sanitize transferred data
  • Mitigate model threat
  • Checklist

I understand that it is not possible to apply all coding standards at all times, but if applied appropriately, it would enhance performance and reduce scientific misconduct. What are your views on coding standards and its impact on software testing?

Janhavi Hunnur | Marketing | Zen Test Labs

Upcoming testing trends?

I was at STARWEST, California earlier this month and it was interesting to hear some of the industry experts talk about current challenges software testers face. Even though, I could not make it to all sessions given the fact that we were presenting the last keynote; the ones I did attend were pretty good.

Most of the talk I heard was around how testing and testers today find themselves in a state of flux.

Development cycles are getting shorter and the ability to test rapidly in an agile mode going forward is what companies want. There was some talk around how testers need to also look at developing programming skills to stay ahead of the curve. I heard a few speakers say that you can’t dedicate time specifically to test, a few mentioned how you need to throw it out to users and let them test while others talked about how crowds could be sourced to find defects. I think this entire line of thinking was coming from one section of the software testing industry; i.e., the ones who are developing apps for mobile, web or cloud.

Take the case of our business, software testing in banks is an extremely critical activity. Not only does it involve large financial data but also invariably will have a lot of elements of regulation and compliance in it.  If I had to tell my customer, I will use a crowd to test your application which you can give your users to validate and all of this will save you 20 days- they’d just go elsewhere…To a bank the risk of losing 20 million is far greater than saving 20 days. Having said that, here’s what I feel. Going forward software testing will evolve into 2 areas; i.e., agile testing and traditional testing.

In the agile mode, most companies will be looking at optimizing, automating and crowd testing in a big way. The ideal scenario here would be to have a system which tells the developer whether he is breaking the code while developing and where he is breaking it. Companies will have a crack team of testers who can test and fix on the fly and the crowd will be used to see if anything got through.

Traditional testing will evolve to be a process wherein regression suites will be automated, business users will manually test releases with an automation engineer automating on the fly. Hybrid test automation frameworks will drive the change in this direction. Areas like performance testing and security will continue to remain specialized areas.

Be it the agile or traditional modes, testers will not be able to survive without one of the three skillsets; i.e., test automation, domain knowledge and the arguable one programming.

What do you think?

Hari Raghunathan | AVP | Zen Test Labs

Follow me on Twitter: hariraghunathan