Geek4Eva

There have been numerous debates on the topic of Testing v/s Quality Assurance (QA). Like: QA has bigger scope than testing, testing is more effective, QA helps find issues earlier, etc.

As per my understanding the commonly accepted argument is that ‘testing’ is something that comes at the end of the SDLC. It is the process of executing manual or automated, functional or non-functional testing. It is (mostly) conducted by specialised testers. Testers may be involved in the process from beginning, they might or might not have much input to make, but the actual testing only occurs at the end. If the development is iterative then multiple iterations of testing. But the bottom line is that testing always occurs at the end when developer passes on the piece of development to tester for testing.

Whereas QA is from the day the project is initiated. Depending on your environment, if there is lot of ‘business as usual’ (BAU) or maintenance stuff happening then I would like to say it is the on going process.

In our Applications team we believe in ‘QA’. We understand the importance of it and the advantages of implementing it. In order to achieve that the QA team recently released the new QA process where we have ‘quality control’ measures at various stages of SDLC. Various roles within the team have been given the responsibility of QA at different stages. An example of which is that Solutions Analysts (SA) are responsible to QA a Business Analyst’s (BA) work and a Developer will QA a SA’s work. As in the person next in the SDLC process QAs the work of the person before him.

Some of the advantages of QA are:

• Transperancy
• Early involvement of people
• Early feedback
• Find issues early
• Lesser cost of fixing issues
• Quicker delivery

Below is the QA process that we have come up with. It is just a high-level representation of the actual process, which is like 38 steps long. This process has inputs from the QA team, BA team, all the managers of our group and the Project Management office.

Haven’t really had a first-hand experience of Test Driven Development, though have come across some real promoters of it.

The two most common push back that I hear from developers or their managers for not being able to implement this are:

1 – It takes a while to implement as in training developers and them into the habit.
2 – The extra cost that is involved in creating those Tests

Image Source

I’d say both these factors are quite subjective and it’d be difficult to estimate the cost for them.

But Miško Hevery, an Agile coach and developer at Google has gone ahead and tried to estimate the Cost of Testing. And he has estimated an overhead of 10% for writing tests for any piece of code.

So a naive answer is that writing test carries a 10% tax. But, we pay taxes in order to get something in return. Here is what I get for 10% which pays me back:

* When I implement a feature I don’t have to start up the whole application and click several pages until I get to page to verify that a feature works. In this case it means that I don’t have to refreshing the browser, waiting for it to load a dataset and then typing some test data and manually asserting that I got what I expected. This is immediate payback in time saved!
* Regression is almost nil. Whenever you are adding new feature you are running the risk of breaking something other then what you are working on immediately (since you are not working on it you are not actively testing it). At least once a day I have a what the @#$% moment when a change suddenly breaks a test at the opposite end of the codebase which I did not expect, and I count my lucky stars. This is worth a lot of time spent when you discover that a feature you thought was working no longer is, and by this time you have forgotten how the feature is implemented.
* Cognitive load is greatly reduced since I don’t have to keep all of the assumptions about the software in my head, this makes it really easy to switch tasks or to come back to a task after a meeting, good night sleep or a weekend.
* I can refactor the code at will, keeping it from becoming stagnant, and hard to understand. This is a huge problem on large projects, where the code works, but it is really ugly and everyone is afraid to touch it. This is worth money tomorrow to keep you going.

Sounds promising! I am quite keen to discuss this with my development manager – what are their plans on this?

Here’s a quick and simple overview of the main differences between Waterfall Development, Iterative Waterfall Development, Scrum/Agile Development and Lean by Agile101.net

Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

• You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
• You leave the testing until the end, which means you’re leaving issue discovery until late in the day
• You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
• You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
• You’re heavily reliant upon a project manager driving the way – the power of one

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches.

The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features.

The most commonly occurring issue in this type of scenario (in my experience) is bottle necking.

For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing.

Another common symptom of this type of approach is over-commitment.  It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way.

You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined.

For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases.

It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches.

We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature.

With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again.

In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level.

In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

I am currently working on a relatively long project and after 6 weeks into it I had found my sweet spot for the project.

Image Source

Sweet Spot? What exactly is ‘Sweet Spot‘?

Steven DeMaio in his blog – How to Find Your Project’s Sweet Spot helps us to identify when is the right time during long projects to do bulk of the work.

As per him there are two common approaches:

The 11th-Hour Approach. When you wait too long to do the bulk of the work on a project

OR

The 1st-Hour Approach. You’re also vulnerable to underachievement if you dive into a project before it has had a chance to stew in your brain

The approach he recommends is: The Optimal Approach. In which he recommends: “After you officially take on a project, give yourself a brief window during which you’re actively thinking about it but haven’t yet begun the work in earnest — that all-important “stew” time. Just as your ideas begin to bubble up and give off their heady aroma, that’s your creative sweet spot. It’s precisely when you should initiate your highest-intensity activity.”

Yeah right, agreed. Personally, yes I liked the idea and it will work fine for someone for his personal tasks and duties.

But I am not sure how much of it is applicable to IT projects and specially those projects with a huge team. As most of the work is inter-dependant and it is difficult to get everyone to give more than 100% at the same time.

Nevertheless I think it is worthy enough for me to share it with my Project Manager and other relevant managers on the project.

Measuring Test Automation ROI – in his post I.M.Testy has briefly touched on some aspects of test automation.

Image Source

I quite agree with his post and there are certain things that I would like to comment on and those are:

• I totally agree that “Automated software testing ‘is software development.’” and all the managers need to accept and understand that. Therefore an automated tester may demand and does deserve an equal salary package as his software development counterpart.
• I think it is quite difficult to come up with a measurable ROI on automated testing – but thats my understanding. Though it goes without saying that automating any testing is going to payback in future.
• There are always some managers (business and project) who do not understand importance and advantages of automation.
• Upscaling of team members is also very important and every testing manager should invest some time on training the team to understand the ROI of automation and take smart decisions on what tests to automate.

I am yet to work on a project where BDD – Behaviour-Driven Development framework is used.

What is BDD?

Behaviour-Driven Development (BDD) is an evolution in the thinking behind TestDrivenDevelopment and AcceptanceTestDrivenPlanning.
…

It presents a framework of activity based on three core principles:

1. Business and Technology should refer to the same system in the same way – ItsAllBehaviour
2. Any system should have an identified, verifiable value to the business – WheresTheBusinessValue
3. Up-front analysis, design and planning all have a diminishing return – EnoughIsEnough

Image Source

Here are some links on BDD introduction, followed by people’s personal experiences with it:

• http://behaviour-driven.org/
• http://behaviour-driven.org/Introduction
• http://xndev.blogspot.com/2009/08/why-i-like-behavior-driven-development.html
• http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/