Posted on Author dev Categories Blog

Software Testing Myths to control quality of IT Projects

-Navneesh Garg-

The quality of software applications has become a key challenge for most IT project managers as the multidimensional and complexity of applications has increased over the last decade.  The key causes for this are the lack of software planning and inclusion of testing resources at the correct stage in the project, and also the appropriate test parameters to test.  The difficulty is compounded by some popular software testing myths which cause lack of focus on testing and poor application quality thereafter. Key software testing myths include-

  1. Testing is an avoidable cost
  2. Testing is too expensive
  3. Applications can be tested by developers or business users or part-time resources
  4. Testing cannot begin until the entire application is developed
  5. Testers and developers are rivals

Testing is an avoidable cost

Most project managers think that spending money on software testing is like spending money on insurance.  It gives you peace of mind but is an unnecessary cost, particularly if you do not use it. Based on personal experience, that’s not quite true. Per industry standard, though only 10-15% of users end up claiming insurance, benefits of software testing are recognized in 80-85% of projects.  So spending on testing definitely has benefits to the end quality of the application and ultimately improves the experience and increases end user satisfaction while at the same time reduces the total project cost.

Testing is too expensive

There is a saying, ‘Pay less for testing during software development or pay more for maintenance or correction later. Take your pick!’ Early testing saves both time and cost in many aspects. Lately companies have introduced innovative delivery models  to reduce the overall cost of testing for both for SME and Enterprise client. For instance software test specialist company AdactIn Group (www.adactin.com) has innovative delivery models like Software Testing as a Service (STaaS™), Packaged Testing, Smart Ramp-up and Down (sRURD™) and Nearshore testing which assists in providing excellent testing value at affordable rates.

Applications can be tested by developers, business users or part time resources

Software testing is a specialized activity which needs specific focus, mindset and a skill-set that the software programmer will not have. It is like auditing, you need a specialized auditor to check the work of the accountant to ensure every aspect has been covered. Similarly, you cannot get anyone who knows the application to do software testing. In my experience, I have seen numerous instances where applications tested by business users or part time resources failed due to lack of testing of negative scenarios or alternate workflows.  Thinking of alternative testing scenarios, trying to crash the software with the intent to explore potential bugs is not possible for a tester without the right skill-set, focus, and mindset that is inquisitive, and looking for faults.

Testing cannot begin until the entire application is developed

Most project managers leave testing to commence once the application is fully developed. This approach leads to two key challenges.  Firstly, testers may not have adequate time to plan their testing, and secondly defects are found later in the cycle leading to further application delays and overhead costs.  Starting testing early gives greater chance to perform static testing which includes reviewing of requirements and design docs and also affords enough time for testers to plan and be prepared for their testing during execution phase. The cost of finding defects earlier in the lifecycle is much less than finding and fixing defects in later stages, often by up to 40% if found early rather than in the latter part of the software development process.

Testers and developers are rivals

Actually, the testers and developers work side by side in a team, and if there are any disagreements, then they should be encouraged to resolve their differences in an open and constructive manner or ask for the business team for feedback on the implementation. There are dedicated professionals in both fields, and communication between the two is important.

Summary:

Software testing should not be treated an overhead, but a necessity, it needs to be part of the development cycle and not at the end of the development. The right people with an inquisitive mind set should perform testing, very much like an auditor, but someone who is going to highlight the issues and provide possible avenues to resolve software bugs.  Finally, software testing should be an integral part of the development phase with immediate action taken to resolve issues when they are at the modular level rather than the system level.

About Author

Nav Garg is the CEO of a leading test consulting company Adactin Group (www.adactin.com), headquartered in Sydney and an experienced Test Architect and consultant. He is also a published author of a books titled  “Test Automation using HP Unified Functional Testing” and “Test Automation using Selenium with Java” which  has  consistently ranked amongst the top 100 books selling on Amazon in the software Testing Category. You can reach him on Navneesh.garg@adactin.com.

Posted on Author dev Categories Blog

Java API: Backward Compatibility

What is a backward compatibility?

– Deepthi Halbhavi-

Backward or downward compatibility in Java API is a property of an API that allows older API usages to function without breaking their existing implementation when an API is modified.

An API Interface

Let’s look at the simple API example below.

Example:

The API consists of only one interface Foo with one method bar(), so the user that implements this API will need to implement the interface Foo.

The following class FooImpl implements Foo and implements bar() method.

Simple implementation for a simple API. But the things get trickier when a simple API is modified to accommodate new requirements.

Let’s check that out.

Modifying an interface

Now, let’s modify the Foo interface and add a new method fooBar() and see what are its implications on the implementation which is FooImpl!

A new method is added in the Foo interface and if the implementation is using the same API then it will fail in two ways.

  1. The existing implementation will not
  2. The existing implementation will not be able to use the new API and may not be able to use new features. Hence the implementation is stuck with the older version because of no backward

Approaches to overcome the above issues

Implement new API

Just implement the new API.

As we saw above, the API is modified so, FooImpl will just implement the newly added method fooBar().

Pros:

  • Keep up-to-date with the API

Cons:

  • Enforces implementation to be added for new the API which may not be required at the time of upgrade
  • Not all the API users would want to implement the new API
  • It is not backward compatible

Interface versioning

In this approach, any new modifications to an interface are put in a new interface. Which means create a new interface that extends the existing one and suffix it with, say _V1

Let’s consider the previous example and apply this approach.

This is the original interface:

A versioned interface extends the previous one

Now the implementation has a choice of how to implement when to implement. For ex:

  1. FooImpl implements new interface which is Foo_V1
  2. FooImpl implements Foo and FooImpl_V2 extends FooImpl and implements Foo_V1

 

  1. Do not implement the new interface Foo_V1 at all if there is no requirement to implement it yet

Pros:

  • Both of the aforementioned issues are resolved
  • Implementations have choice which version to use
  • Implementations have choice whether they want to implement new version at all
  • Fully backward compatible
  • Extend the previous implementation for the new API version

Cons:

  • Increase in the number of interfaces
  • If FooImpl_V1 is versioned and extends previous implementation then it cannot extend any other class even if you wanted it
  • May not keep up-to-date with the new
  • Need to be aware of the new API changes because it won’t complain in a form of compilation errors, hence leading to missing API

Using default method (Java 8 and above)

Java 8 introduce default methods in interfaces to provide backward compatibility. default methods allow interfaces to have implementation without affecting classes that implement such interfaces.

So, let’s use this in our example API to make it backward compatible

The default void fooBar() method provide default implementation and it won’t affect the FooImpl

class that implements Foo.

Pros:

  • Both of the aforementioned issues are resolved
  • Fully backward compatible
  • Keeps up-to-date with the new API with default implementation
  • Implementations have choice whether they want to implement new version at all
  • The implementation can extend another class

Cons:

  • Need to be aware of the new API changes because it won’t complain in a form of compilation errors, hence leading to missing API features
Posted on Author dev Categories Blog

Three National Awards: What’s the Secret Sauce?

Over the last three weeks Adactin has been recognised in three very different forums for its performance. First, at the end of October the Australian Financial Review (AFR) placed the company in its ranking of Fast 100 companies, based on metrics it has monitored over the last three years. And then in rapid succession in mid November we were recognised by our industry peers by being placed second in the CRNs Fast 50 and 16th in the Deloitte Technology Fast 50. The CRN was specifically focused on the ICT sector while the Deloitte award is more catholic in its technology tastes. All awards are national awards.

It’s tempting to think that there is a secret formula for achieving the sort of company growth which the AFR, CRN and Deloitte have recognised. There is a formula of sorts but it’s not a secret one. In fact you might find it a boring formula and will want to tell us you have heard it all before. Maybe so, but for Adactin the following tactics lie at the heart of our growth strategy. None make any difference on their own, but when woven together they make for a compelling engagement with our customers and that is what we are all about.

Above everything else we strive for a reputation for excellence in customer service and to comprehensively meet specific customer needs, even when those needs appear at the last minute.

It’s similar but critically different – in delivering excellent customer service we measure our success by the degree of customer satisfaction achieved. And that measure is not simply a customer saying ‘well done’ or ‘we love your work’. It’s measured by customer retention. Will a customer stay with Adactin and place more work with us when the original task is complete? Most do.

Customers are people too. They need to be heard, and they need to know we understand what we have heard. So we take extra care when we bring people onto the Adactin team. It’s not enough to be a good technologist. Our team members need to be careful listeners, empathetic partners and disciplined practitioners too. Care in the process of vetting our staff and contractors prior to assignment on projects pays customer satisfaction dividends. Oh, it also means we have a spectacularly low staff churn rate.

Having identified the right people we are able to focus on speed of execution, and aim to deliver a response in days rather than weeks or months. When we combine this with innovative delivery models we are well on the way to exceeding client expectations, given these have been shaped by large competitors who are most often weighed down by complex processes.

The speed of response is enabled and reinforced by our membership on key service and procurement panels, both in the federal government and state government. A potential customer can take some due diligence assurance from our presence on these panels, but most importantly the panels shorten the time it takes to have a solution directed at a problem. That all goes to the drive for excellence in customer service. Adactin is a member of Federal Government panels such as the ATO, DTA and Defence, and is on the NSW Government 0020 and 0007 Panels.

Finally we stay on the wave of emerging technologies like digital transformation, (big) data analytics and artificial intelligence. These technologies increasingly solve problems for customers in short periods of time and for dramatically less cost than traditional technologies. We diligently apply ourselves to areas where we can harness new technologies to achieve customer satisfaction.

So, as you can see, there is no secret sauce in what we do. And it may seem like its textbook stuff. But the growth numbers speak for themselves and we are very pleased the AFR, CRN and Deloitte have been listening. Each award applauds this strategy and all those in Adactin who have been so focused on making our customers successful.

1 … 6 7 8 9 10 … 13