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.