Top Technology companies with constant growth and high dreams about aquiring talent !!!

With huge competition and infinite opportunities for talented individuals, whole market scenario is changing. With this some of the companies need to rethink about their hiring strategy, apart from moving with new challenges and opportunities in same verticals or newer ones.


Let me start with an anonymous example, which is one of the top software company. They always hire from IITs and top Engineering colleges in India. In 2011, the salary gap between this company and it's competitors increased by many fold. Due to constant growth, company is not a position to match those compensations and at the same time, they need to retain their employees, as domain knowledge & experience is very important for delivering good quality solutions. Growth is at constant pace and more compromise on quality can prove as a big disaster.


At the same time folks from IIT like colleges always look for new challenges and have some goals to achieve in life. These are mainly fast pace folks. With current scenario, most of the folks have started thinking about start-ups.


With all this, some of the companies who have been hiring people form top colleges are seeing a deep decline on talent pool. some part of it is going to competitors who are in good shape to pay much more. And others are focused on their ideas for start-ups. In my opinion, trend about going for Start-Ups will take a pace and soon we shall see lot of new technology or e-commerce coming in market.


How such companies should handle such situations. This is a big question for top leaders of these companies and a big pain for managers, who are seeing lot of attrition and need to deliver same thing during end of a month or quarter. 


Should they also start looking at middle-tier colleges? How to pace up with increasing salaries, when revenue increase is almost constant, year over year? Should they tighten the processes to reduce overall risk and look at fresh talent available? etc. 


This was one of the random thought came to my mind and thought of putting it somewhere. I will find out more details around the same and share soon...

Some of the Basics about HP QTP (Quick Test Pro) tool

Recording modes in QTP
QTP supports 3 types of recording modes

1. Normal mode also called Contextual
2. Low-level recording mode
3.Analog mode

Normal Mode: It is the default recording mode and takes full advantage of QTP's Test Object Model. It recognizes objects regardless of their position on -screen. This is the preferred mode of recoding and is used for most of the automation activities.

Do you really understand Data Structures : Part -2

QUE. What is the data structures used to perform recursion?

Stack. Because of its LIFO (Last In First Out) property it remembers its ‘caller’ so knows whom to return when the function has to return. Recursion makes use of system stack for storing the return addresses of the function calls. Every recursive function has its equivalent iterative (non-recursive) function. Even when such equivalent iterative procedures are written, explicit stack is to be used.
 

QUE. What are the notations used in Evaluation of Arithmetic Expressions using prefix and postfix forms?
 

Polish and Reverse Polish notations.

QUE. Convert the expression ((A + B) * C – (D – E) ^ (F + G)) to equivalent Prefix and Postfix notations.
 

Prefix Notation:
^ - * +ABC - DE + FG
 

Postfix Notation:
AB + C * DE - - FG + ^
 

QUE - Sorting is not possible by using which of the following methods?

(a) Insertion
(b) Selection
(c) Exchange
(d) Deletion
(d) Deletion.
 

Using insertion we can perform insertion sort, using selection we can perform selection sort, using exchange we can perform the bubble sort (and other similar sorting methods). But no sorting method can be done just using deletion.

***Long time back these questions were read from one website about placements and I had all these questions noted down in a Notepad. I just copied whole content, so that it can be helpful for relevant folks.

Do you really understand Data Structures : Part -1

1. What is data structure?

A data structure is a way of organizing data that considers not only the items stored, but also their relationship to each other. Advance knowledge about the relationship between data items allows designing of efficient algorithms for the manipulation of data.

2. List out the areas in which data structures are applied extensively?

- Compiler Design,

- Operating System,
- Database Management System,

- Statistical analysis package,

- Numerical Analysis,
- Graphics,

- Artificial Intelligence,
- Simulation
 

3. What are the major data structures used in the following areas : RDBMS, Network data model & Hierarchical data model.

RDBMS – Array (i.e. Array of structures)

Network data model – Graph Hierarchical data model – Trees
 

4. If you are using C language to implement the heterogeneous linked list, what pointer type will you use?

The heterogeneous linked list contains different data types in its nodes and we need a link, pointer to connect them. It is not possible to use ordinary pointers for this. So we go for void pointer. Void pointer is capable of storing pointer to any type as it is a generic pointer type.
 

5. What is Minimum number of queues needed to implement the priority queue?

Two. One queue is used for actual storing of data and another for storing priorities.

***Long time back these questions were read from one website about placements and I had all these questions noted down in a Notepad. I just copied whole content, so that it can be helpful for relevant folks.

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;
}
}

Community Testing - Another good practice to gain confidence on Quality of your Software !!!

During one of the projects during last year, our testing team was most stressed up with lot of activities. During the mid cycle, all of us in Testing team realized that we have too many bugs to regress and lot of feature testing pending. If we opt for regressing bugs, we have risk of finding new bugs very last in the cycle.
So we had to balance the things, but as all of us know that saying something like following is very easy but practically things can be very different in testing -

- Let's balance bug regression and testing, when there is a cap of having bugs less that 20 in your court. And most of the tester have more than 35 bugs.
- Let's test on these platforms as well, as it's a quickest thing to do.
- Let's test this bug on Win-7 in Japanese language and Standard User etc etc...
- Etc... (I don't want to rude to the Managers or Developers who use such sentences :) )

Another challenge was Integration testing which was planned to start from coming week. This kind of situation can occur in any project which is more buggy in initial stages.
Now when an individual tester starts working on ToTest bugs, it used to become hard to find more time to test new features or functionality.
So Team came up with an idea to have a time slot of 2 hrs everyday when all of the tester will meet in the lab and will be testing their own features. We called it as Community Testing and found various advantages of this:-

1. It helped each QE to do dedicated testing of their features and in turn all of them had good confidence.
2. This Exercise also helped in accelerating Integration testing, as each tester had an opportunity to discuss their overlapping feature areas to make appropriate test scenarios on the run.
3. More productive as it was more disciplined.

Now in our teams, Community Testing has become a part of every Test Plan people enjoy doing it.


*** My Personal View - In every project a stage comes when meetings, bug discussions, investigations, emails start taking too much time and hardly any time to do focused testing of our regular features.
Community testing gives an opportunity to forget about all these things and do focused exercise for gaining confidence. Within few days every tester starts feeling good. While in other scenario, when s/he spend multiple days doing bug regression, meetings etc... they loose confidence and get stressed up.

COMMUNITY TESTING is a rocking concept in my opinion. Share your opinions through comments.

Return on Investment and Payback of TEST AUTOMATION

Of all the reasons, the most relevant and easy to convey to top management is the return out of Automation :-

- Gives consistency to the project by regular feedback in quick way.
- Helps in pushing the boundaries of the software.
- Give more time to testing team for focusing on other aspects of Quality for final release in market.


With this quick recap of all recent articles, we shall we discussing the hurdles for Automation !!! But need to wait for tomorrow...

If you are not able to understand the context of this post, please have a look at http://computersfundamental.blogspot.com/2011/06/why-should-we-automate-our-test.html where it started from the need of Test Automation in a Software Development Team.

Automated Test-Suites are Great Documentation !!!

Agile Software development approach use examples and tests to guide development. When tests that illustrate examples of desired behavior are automated, they become 'Living' documents of how the system actually works.
It would be already recommendable to add appropriate comments with relevant description to your Automation Scripts. But anyway results out of input values to Automated framework is a good enough proof of documented functionality of a particular Software.

It's very hard to keep static Documentation updated all the time, while in case of automation this problem never occurs.
Automation is a wonderful way to ensuring that we tested our updated code because keeping our results in PASS always need upgradation of our Automation Scripts as per new code changes.


If you are not able to understand the context of this post, please have a look at http://computersfundamental.blogspot.com/2011/06/why-should-we-automate-our-test.html where it started from the need of Test Automation in a Software Development Team.

Least Influential Testers and Quality People with very High Influence - Which one is better ?

Yes, Testers with very high influence and with least influence can be bad for a particular project. Situation becomes worst when Developer working with such testers are not bothered about arguing on things and don't have strong opinions.

Why this came to mind and how I am concluding this?

Today I was sitting in my office and overheard a conversation between a tester in my team & relevant Developer. Tester had logged a bug which seemed to be as-designed. Developer gave one reason that it's discussed in a meeting and should be as-designed. On this Tester got annoyed and said - "I was not in that meeting, I guess. And with workflow makes perfect sense" ... and gave some reasons in favor of that. Developer was just listening and agreed to what that Tester told him. Developer didn't give  second thought on the reasoning given by tester and conversation happened in the meeting.

This is a typical example of Highly influential tester working with a Developer with less influence, weak onions etc. This way Developer end up doing/fixing things, what is suggested by Tester. Usually Testers have very strong opinions and they kind of convince other folks easily. For such Testers, Developers should be more attentive and in case of doubt, Developers should get opinion from Managements and product Managers who are responsible for product requirements.

Conversations become more interesting when more influential developers work with highly influential Testers  :-)

I have enjoyed such conversations during my career many times ! But believe me, it gives better results if both tester and developer discuss it constructively without thinking in terms of effort, time etc. Also it gives a wonderful experience for both the folks and help in improving their negotiation skills.

Now let's come to other thing when Tester is not very influential. Not being very influential doesn't mean anything bad, but Tester with least influence should not accept comments from developer or any other team members, if not convinces. And should try to follow the standard processes to share the opinion through Bugs, Email-discussions and let management take right decision rather accepting some comments conveyed through informal conversations.

Many times, Senior Developers give some technical reasons which may not be right from user's perspective. And if Tester is not convinced with those reasons, there is no point accepting things only because you can't influence others opinion.

Hope I conveyed my thoughts in right way. Please feel free to share your opinion about this through comments !!! That will be most appreciated.

Higher Management at Software Companies - Dare to accept the mistake and try to correct on your own?

I am not sure if title of this post is clear or not. I wanted to pose this question to Higher Management in Software companies and also wanted to know about %age of managers who dare to accept the mistakes and try to correct themselves.

Here are basic things I want to highlight through a basic story :-

- As a Lead/Manager, do you panic in bad situations?
- As a Lead/Manager, do you take responsibility of any mistake or just pick someone from your team to point all the fingers?
- As a Lead/Manager, what do you think about your responsibilities?
- As a Lead/Manager, How many times, do you lead by example in bad situations?
- As a Lead/Manager, how many times you give 100% credit to your team for any achievement?

In most of the projects team dynamics are unique but still there are some common things, out of which some are good for healthy work enviornment and some are not. Most of the times things keep running on right path unless deviated by various external situations. Have you started getting confused?

Here I am going to tell a short story of an incident when one of an important member of corporate management find some problem with an alreased version of software. During his usage found that a particular behavior in software is not very intutive and wanted to know the logic of it's design. He sent an email to director who is heading the software engineering team for that product.

Director called a meeting with Engineering Manager and Quality Manager of that team.Both of them had almost no clue why this feature is behaving like this. Please note that it was a problem when things were giving correct results and the workflow are not intuitive.
Just after the meeting Engineering Manager asked Quality Manager, this behavior seems very wiered and why didn't we catch this problem. Although Quality Manager was not very convices and he felt that behavior was decent. It was more of perspective problem.

Before we start with next part of the story, let me throw some light on the issue raised ! Actually this was 7th release of the software and so called problematic area was there in the application from first version of the software.

Both the managers thought about it and got to know that feature was designed 4 years back for first version of the software. Co-incidently the quality engineer who tested this software in first release was still working on same feature and he was an expert of that area. Quality Manager calls him and ask why this behavior is so wierd rather asking the rationale of the design. Although the Tester explained each and everything, s/he was not able to relate why this question was asked after 4 years of this design. Lots of other meetings happened that what should the team do about it. Many folks even talked about releasing an update by changing the behavior.

During one of these meetings some of the Managers conveyed that they were never aware of this particular thing and this should have been taken care long time back. From this point, the tester was very disappointed and tried to figure out details related to this behavior and s/he found following details:-

1. S/he found an email where design proposed by Product Management was very well appreciated by all the Manager however the feature development and testing team had some concerns with this design. As it was not useful for 15% of the users and this software had lacks of users acorss the country.
2. Tester also found a bug which had all the statistics with a proposal of giving two workflows to use the feature and the other one was the expected by the VP. And this bug was deferred by these Managers only !
3. Few more emails where reference of this behavior was discussed in detail.

WHAT WOULD YOU CONCLUDE OUT OF THIS AND HOW THE RESPECT METER REACT ON THIS?

Now here are some basic questions that arise :-

1. Was this a so big issue?
2. Was there any need to discuss this thing in so much detail?
3. Shouldn't these managers figure out details for conveying it to higher management without much Panic?
4. was this something to discuss with so much parties involved?
5. Can a Manager say that he was not aware of software behavior?
6. And lot many others...

I think I started with something very sepcific and lossing track... So I am stopping here for you guys to think and will share the next part soon :)

Why Should be Automate - Automated Regression set provide a Safety Net !

A Software tester who has worked on following projects will really appreciate the fact that regression testing is very challenging and boring at times :-

- Very large project with lakhs of lines of code a and we keep on adding new features to it.

- A badly managed code with lot of bugs and bugs are being fixed on regular basis.

- A software application which has a common code-base but released in various forms

- etc...

In most of these cases challenge is to make sure that new feature or bug-fixes in old code are not breaking any existing functionality. That effectively means retesting things which were already working and can have risk of breaking something.

Knowing code and planning regression testing in optimized way is usually a good practice but Automating such areas give much more confidence. At times regression automation may demand lot of maintenance as tester may need to update the scripts after a particular change in the code, but effort to update existing automation system should be less and easy. Also it depends upon the initial planning for automating test scenarios for a particular project. Better we understand the nature of our project, more time we shall save on maintaining the automation environment.

Another reason which I see is important in automating regression peices is fearless attitude of software team to be open for fixing old bugs to improve overall quality. I have seen teams who have been working on same code-base for last 10 years and it's a big fear to fix a severity-1/2 bug in older code. Why so, because each one in the team knows that time cost of testing that change in legacy code will increase and even after that we may not be able to figure out the side-effect. If such teams maintain a good automation harness, it should be fearless to fix any old problems as if any change impacts, can be caught by automation system.

Regression automation systems should be able to tell the developers that what you have broken by a particular change in older code :)

If you are not able to understand the context of this post, please have a look at http://computersfundamental.blogspot.com/2011/06/why-should-we-automate-our-test.html where it started from the need of Test Automation in a Software Development Team.

Why Should be Automate - Frees people to do their best work !

Automation can free up testers to do better things during the time they save due to automatic test runs. But the only thing is planning automation tasks in such a way that it cover most of the main scnearios and scripts should not be very demanding in terms of maintenance.

If whole automation setup reliable and needs less manual inputs, people can better think of other test scenarios and do exploratory testing. As we know testing an application with 100% test-cases is not possible as any application can have thousands or lacks of user scenarios. With various white-box techniques we can ensure that all the functions in a code are tested but but covering all the path conditions etc is not that practical. 

Here Automation gives as opportunity to testing team to explore more areas to test and make sure things are better with those efforts.

 

Why Should be Automate - Manual Processes are error prone !

At times repeated testing can be boring and it becomes more sad when scripted test cases need to be run. Project deadlines create more pressure on top of that and a tester tend to miss the corners and specific scenarios which may ruin the whole effort put in past.

With all such limitations, testers may happen to miss some steps or provide some wrong inputs which may be dangerous in terms of accuracy test. At times, team has to work late and that may not be a healthy way of getting things done. As a tester reponsibility to certify something is huge and it becomes difficult at times.

E.g. - Build process and testing around it is critical and some basic automation may help in doing things fast without error. 

Why do Test Automation - Manual Testing take too Long !

This is one of the main reason for automating our test suites and becomes more important for ongoing projects with more funcitonalities each day.  Most of the application have various functionalities integrated so well that test scenarios increase exponentially. Although it's pity that sometimes higher management doesn't understand this fact. Non-Tester only understand this challenge when they see some bug after release, which is worst part. Let me control my emotions here :), as we are not discussing that part of test-teams here.

If we consider as example of Agile Software Development, after firt realease there can be an expectation to release shorter versions, dot releases or minor fixes in short duration of time OR even every day. And in this kind of situation it is close to impossible to test everything and certify. Many times Automation laso takes too much time for such projects, but that is something which can handled using Vm enviornments to run various test scenarios in parallel.

Regression is one of the area which is more challenging and difficult to handle manually. When an application is manually certified and we do some changes in code, it becomes difficult to cover everything again manually and we may miss some important bug due to this. For regression, automation gives at least some level of confidence apart from manual testing done my the team.


   

Why Should we Automate our Test Scenarios?

Usually following reasons are main cause of thought regarding Automation in a particular Software Development Project :-

1. Manual Testing takes too much time. (But faster ways of doing the things may not be simulating actual user scenarios? What's the thought)

2. Manual Processes are error prone. (If manual ways of doing can be error prone, then we as Software development team should know the areas which are error prone and try to avoid that user get caught by those errors. Aren't we avoiding the ways to discover those error prone areas?)

3. Automation frees people to do their best work. (How many people really think that Automation really need no manual intervention. Even if we say that an automation runs on its own and don't need a single manual input. Is the person who automated, always relax while automation is running? And does our Automation scripts always work without change? If Yes, are we doing any development or not :) )

4. Automated regression tests provide a safety net. (This is one of the point which seems most reasonable...)

5. Automated Tests give feedback early and Often.

6. Automation can be good return on investment.


We shall be discussing each of these factors in details, before we move on to the things which do not promote Automation much in a Software Development Cycle !!!  

"A Developer code should always challenge a Tester and a bug should be more bugging every time for a Developer !!!" 

How do you think about Test Automation in a Software Development Project?

 How do you think about Test Automation in a Software Development Project?

- A Way to test things quickly and gain confidence.
- Reduce Manual effort  and in turn getting good quality by reducing cost.
- A Secondary method of testing things to gain confidence.
- A way to cross check the main functionality of back-end !
- A way to impress higher management, even it's consuming more time/resources to maintain the Automation Framework !
- What else?

Here is how I think about it. And here we are only talking about Functional Automation, not Performance or Load automation thing !

Actually similar to other planning, Automation plans also depend upon the size of project, type of technologies used, Development Cycle, External Dependencies etc.

Let's take an example of a software which has longer development cycle and has lot of legacy code. But the application is a fun application which gives good user experience and less functional support.
Now this kind of application has following challenges:-
- Lot of Legacy code. How to test it?
- Ensuring best user experience?
- Repeativtive changes over a longer period of time.
- etc..

Now questions are :-

1. Should we do Functional Automation for such Software?
2. If yes for first question, What all should be automated?
3. If yes for first question, How much of Automation with be sufficient?
4. Since application should give best user experience in terms of workflows, UI etc, how should this part be catered. This question becomes more critical when all the legacy features are tightly integrated with new features.

Before we start discussing this, I will pause to think more on these points and will write soon about my clean thoughts !

TRUST is an important thing for a Quality Engineer or Tester.

It's been more than 6 years that I have been working with various Quality Engineers and every one is different from other and have unique working styles. But the most common thing which is seen with a tester, Quality Engineer or a Quality Analyst is Level of TRUST they gain from various team members like Developer, Manager, Product Manager and other folks in the team.
TRUST between the team members is very important and it becomes very important for Testers in two ways -

1. Other's TRUST on them is important and governed by the way a Tester performs within the team. 

2. TRUST Level a Tester has on the developers. (Although it's recommend to never TRUST the code programmer has written :) )

Here we are not going to discuss the second part about TRUST but the first part.

Being a Tester/QE/QA, gaining TRUST of team members is a very important thing as we own the responsibility of best possible quality of final product or application. 

If I take a simple example of the way a Quality manager deals with his/her team-members (testers) depend a lot on the way each individual has gained the TRUST over a longer period of time.

A Quality Manager has a very BIG responsibility with him to deliver best Quality Product in the market although he/she is not directly testing everything. TRUST is the thing that gives him/her confidence about overall quality on the Software at various stage of a Development cycle.There would be few people who have gained that trust and managers doesn't like to follow up too much with these kinds of folks, but story changes completely with folks who have not gained that trust. 

The worst part is when someone gains the trust and then looses it with some silly things.

IDEA of this write-up is to help people understand the significance of TRUST in workplace. Everyone wants to grow in her/his career and key is to work hard and improvise with time. Trust me that honest and sincere working habits also impact our personal life. If we do our work in well, there is very rare probability of getting stressed up unless work is not in control or there are other factors involved.

I have seen people having different thoughts like -

"Why should I work too much" .. "What if I complete a task of 5hrs in 1Hr and say OK" ...

Personal life in one these things change their way of thinking as well and all those things impact their personal life too! For a manager or a lead, it's not a very difficult thing to judge that things are going wrong. And there are very simple solutions to resolve such problems. But the harm is that the TRUST level goes down and it also impacts the way or the other.
 
In Software Industry, there are lot of practices to overcome such flaws which can impact the progress of a project through low confidence level or less TRUST. But the important question is why should a person do such things.

Most of the people in Software Industry work very hard during the starting years of their career and over time aspirations change. With that, working style also changes... but Testers need to be very careful while doing their work and about their involvement in various other things around them.

TRUST is the BIGGEST ASSET for a Tester and every tester should keep this in mind. Building GOOD Level of TRUST takes times and taking it to lower levels can be instantaneous.

Various Teams and Role in an Agile Development Project !!!

Continuing the last discussion about Agile Testing, let's talk something about the different teams involved and their roles in Software development process. There are mainly two teams - Customer Team and Development team.

Customer Team include business experts, product owners, domain experts, product managers, business analysts, subject matter experts or every other person who is directly or indirectly related to the business part of the aplication/software beging developed.
Customr team writes the user stories or feature sets that developer team delivers. They provide the samples or examples that will drive coding or designing in form of business facing tests. Customer team communicate and collaborate with developer team throughout the project and during each iteration development team test & improve.

Testers are integral part of Customer Team who help making requirements and examples to help customers expressing their requirements as testing stories.


Another team is development team, where everyone in the team is involved in delivering code... Agile principles encourage team members to take on multiple activities, any team member can take on any type of task. Many agile practitioners discourage specialized roles on teams and encourage all team members to transfer their skills to others as much as possible.

E$ach teams needs to decide what expertize their team require. Programmers, system administrators, architects, Database Admins, technical writers etc. ; people who wear more than one of these hats may be part of the team...

Testers are also integral part of developer team as testing is central component of Agile development models. Tester ensure the highest possible quality for business people by making sure that development team try to achieve best quality practices to add business value to their user stories.


There is high degree of interaction between Customer Team and Development Team in an Agile environment.  Ideally they are same team with a common goal of providing best possible solution to the user stories and add more value to the business ! Agile Project proceed in small cycles in continuous manner. One chunk of user stories in picked and done in a cycle of one to four weeks and then move on to next user stories. During each cycle Customer Team meets with Developer team to understand how much user stories can be picked and they prioritize their stories accordingly. Customer Team helps developer team to pick the stories in relevant fashion. Testers play a major role in identifying the priority as they are more aware of the interaction of each story with other and their impact. In each Agile cycle Developers code for test and tester team remain on top of all the changes and make sure that every cycle produces best possible quality. Tester has to be in touch with both the teams regularly to ensure that Business needs are met by keeping an eye on techincal complexities to implement those business needs...


Some Agile methodologies don't use the terms as tester.  In those cases all the member of an Agile  team think about the testing scenarios and stretch their ideas to make sure that the vital role of a Tester is a big responsibility... This new opportunity gives an idea to stretch the thought process and which is not a skill everyone can attain !!!

What exactly is AGILE TESTING?

There is lot of buzz about "AGILE" these days and we can hear Agile word in any of the software development organization these days. But what exactly it is and why suddenly everyone starting talking about Agile methodologies in Software Development? 


Every company or teams within are practicing various Agile methods these days.. Like Scrum, XP, Crystal, DSDM, FDD etc... Does these names sound new to you? Not a problem, we are not here to discuss the Agile in detail as of now. Idea is to understand the basic meaning of it and what all is associated with it.


Usually we use two terminologies for our convenince - TESTER/QE/QA and PROGRAMMER/DEVELOPER! The person called TESTER/QE/QA does all the activities revolve around testing and PROGRAMMER/DEVELOPER implements the logic for a software by using various technologies available. But does it completely define their role? In Agile, there is a focus on these two type of folks and idea is not to narrow the definition of these roles. In Agile, each member irrespective of the role is responsible for high quality software which provide a value to Business Problem. 


Several fundamental practices used by Agile Teams relate to testing. AGILE programmers use test driver development (TDD) and also called as Test-Driver Design to write quality code ! With TDD, programmer writes a test for tiny bit of functionality; if it fails , make appropriate changes to make it work/pass.. and then move for the next tiny functionality of the software !!! 


Agile Testing is not just the testing activities do in a Agile project. Some testing practices like Exploratory testing are inherently agile, whether it's done an agile project or not.


Agile development model encourages us to solve our problems as team. Business people, programmers, testers, anlysts - everyone involved in software development - decides together how best to improve their product. 


Don't worry if things are not very clear after reading this particular post. We shall be focusing on Agile testing for next few weeks and keep a track of topics being covered.

"Test Architecture" Training by QAI in DELHI, INDIA

*** Its my personal opinion about this training.  

Yesterday I attended a training on "Test Architecture" by QAI @ Vikram Hotel, Lajpat Nagar, Delhi, INDIA.

There were 13 attendees from Microsoft (4), Adobe (4) and Aricent (3). Most of the attendees had 5+ experience and some of them had come from Hyderabad to attend this training. During the first half we were told that industry is not following some standards and their technique is going to do some magic to ensure that we test 100% :) . We were taught definitions like Validation, Verification, Test Cases using Boundary value analysis, Equivalence partitioning etc... We spent 1/4th of the time in all these things which are done in first year of our career in testing. In the second half most of the attendees were frustrated and asked for goal of this training. This was asked by many people in different ways as different times. Finally some of us decided to share the feedback with QAI and Adista Testing.

We were really looking forward to attending this training as it was supposed to be meant for people with 4-5 years of testing experience and because of our faith in the quality of trainings delivered by QAI in the past. However, this time, I hate to say, we are very disappointed.

The content of the training was much below the expertise level of an experience tester. In fact, it was suitable for a person with 0-1 years experience. A tester with 4-5 years of experience does not need to be taught how to write test cases. Moreover the quality of slides and the delivery of the training were amateurish. Not at all up to QAIs standard. I am afraid to say the training hasn't added anything to our skillset as Test Architecture.

I decided to not waste another day(7th August) there and have requested QAI to refund the Training Fees.