Developter & Tester/QE/QA ratio in a Software Project?

It is one of the most common questions, we face in almost every project... 'What is a reasonable Developer to Tester Ratio for a Software Development Project?'… Sometimes the question comes in variations, like 'Are there standard Developer to Tester ratios for Enterprise software, Driver Software, Financial Accounting Software etc.?'. At times it's associated with  budget allocation… like in 'What is a reasonable Development to Testing budget breakdown?'.
There are few things that I see bad about the topic: 

- When management assumes that test estimation could be done based on Dev : QA ratio 

- When a Tester/Test-Lead don’t understand why the Manager is so concerned about this ratio or even see it as Management’s lack of understanding of testing process.

And in my opinion all this depends project to project and exact stage of the project... Followed by a more elaborate explanation that one size doesn’t fit all. As far as I know there is no such thing as an authoritative ratio, for several reasons:

    I do know that some companies keep internal track of that numbers, but this kind of information is not shared publicly as it can impact market and question may come on quality standards.

    What if their competitors find out? Knowing that your competition is doing substantially better or worse from a resourcing perspective tells you something about how efficient or inefficient your competitor is.
 

    Software is hard to categorize… are you dealing with Travel software, Operating system software, Device Drivers, ERP Solutions, MIS systems, a monolithic app, an app running on the mainframe / UNIX / heterogeneous environment, Hybrid application, Cloud services etc.?

For applications mainly closer to hardware or core systems of our computers like operating systems, device drivers, highly technical, and algorithm driven software, ratio close to 1:1 can be seen. The higher the number of end users, the closer to a 1:1 ratio we get, because the risk is proportionally higher.

For any business application, we might have seen more of a 4 developers to 1 tester/QE ratio. Some really lose organizations go as far as 10 developers to 1 tester. A lot of this is driven by company history and their commitment to quality. Type of Industry plays a role as well – some industries, like medical devices, demand perfection. While others like e-learning, are more lose. So what the market bears in terms of quality perception drives the ratio as well. There are many standards in software industry which also help various organizations to decide this ratio. For example, projects which need quality of Six-Sigma level will surely need a decent ratio of Developers and Testers.

Overall here are some variables that may influence this question:

    1. Size of a Software project
    2. Duration of Software Project and corresponding timelines
    3. Type of Software Project (version 1.0 vs. version 10.0, rewrite vs. maintenance, etc.)
    4. Technologies involved

    5. Development methodology (Waterfall OR Agile, etc.)
    6. Organizational setup 

    7. Regulatory requirements
    8. Quality of the deliverables

What are User Stories in AGILE SOFTWARE DEVELOPMENT?

A user story is actually a functionality which defines actual need of end user or business organization. 


Usually User stories are composed of three components as -


1. A written form of story which is used for planning and also a good tool for reminding the actual need during different phases of a project.


2. Conversations about a story which make an outline about the detailing in right context with right details about the story.


3. Test which convey and document details... and something which can be used a tool for determining the completion of a user story.


As times these three steps are also known as - Card, Conversation and Confirmation... Ohh again 3Cs :)

Agile Software Development - What the hell it is?

Agile Software Development practices are hot in Software industry these days and all for good reasons. I have been working in an environment which has just started adopting some of the Agile methodologies and mixed them with our standard practices. So of course, we are still in learning mode and trying to fetch most out of what we have learned so far.


As of now, I am not directly involved in any of the Agile processes being followed in my organization. But I wanted to know how they work and why they are in such a high demand these days... So when I went to a friend in office that what exactly it is and what all you guys do.


His first reaction was - How the hell can you say that you have zero knowledge about Agile. I am a frequent participant of various conferences happen in India and many times heard big leaders talking about it, but somehow I was never able to digest all that theory :) ... Now I realized that anything which is not in practice is theory and one has to start with theory only !


So I thought of understanding it now. Today I got a book  by Mike Cohn, who has written about User Stories Applied under main title of Agile Software Development.


We have lots of books in Library but I picked this one because of it's different name - 'User Stories Applied'. Even I was not aware what User Stories are :) ... Anyway, whatever story I was trying to make above is true upto one level but I have some knowledge about Agile Software Development methodologies and now ready to learn more about these... 


Hope to share more around AGILE things and first we will understand what these USER STORIES are :)

Unresolved Customer Problems due to minor things !!!

As readers of this blog know that we always talk about Computer Softwares or Hardware. This is more about  Software aspect, where a team of Engineers and testers delivered a software in market. Now this user reaches to tech-support. tech support folks tried all possible things and escalated to engineering team. Story starts here - 

When things are escalated to engineering team,  there are two ways to take it. One is to jump directly that it's not possible and we have seen this working here. Most of the times this kind of comment comes from a tester or quality engineer. Other way is to understand the user problem and try to figure out the missing information which can lead us to probable cause of a problem.

This is one of the thing associated. We shall come back to our first part after knowing other things involved... Let's have a look !

1. Many times user escalations are not taken very seriously unless it comes through higher management. And unfortunately, this is considered as secondary activity in most of the engineering companies. But again, it's not a generic case with all ! Who take is seriously is good !!

2. Many times engineers are not very keen  for working on such user problems, because of nature of problems involved. Most of the times, user report things in very obvious and straight workflows. To investigate such issues, people need patience and right motivation. Even if patience is not there, motivation can work :)

I will keep adding items in list mentioned here. Let's continue on the part where tester takes the case positively and has right motivation to work on it. S/he tries and most probably, problem will not be so easily reproducible. S/he will try to think of relevant things around this and if all fails, s/he need help from developer who coded that particular functionality. 

Now again, attitude towards the problem will matter. Many times developers have tendency of asking a reproducible scenarios before doing anything. In practicality, many time user issues are not so obvious to be reproduced. So idea is to work together and try to figure out probable causes.

Right attitude of engineers with belief in team-work is only thing that can help any software company in long-run. Otherwise, any XYZ company can hire brilliant minds to produce brilliant products. It's always better to have brilliant folks with right attitude !!!

Small things make a big difference in long run and Customer Advocacy one thing, which is really important for long term growth of any organization !!!

How to REVERSE a Linked-List by writing a C++ program?

 I hope that you are very well aware about Linked-List. Here we are talking about reversing a Linked-List which means that first node should become last node of a Linked-List and Vice-versa...

void Reverse_Linked_List(void)
    {

// When there is no Node in Linked-List
        if(List_head==0)
        return;


//When there is only one Node in the Linked-List
        if(List_head->next==0)
        return;



//When there are only two Nodes in the Linked-List
        if(List_head->next==List_tail)
          {
              List_head->next = 0;
              List_tail->next = List_head;
          }
       else
         {
            List_node* pre = List_head;
            List_node* cur = List_head->next;
            List_node* curnext = List_cur->next;
            List_head->next = 0;
            List_cur-> next = List_head;

for(; curnext!=0; )
{
List_cur->next = pre;
pre = cur;
cur = curnext;
curnext = curnext->next;
}

curnext->next = cur;
}
}