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.