Page 1 of 2 12 LastLast
Results 1 to 10 of 13
  1. #1

    Implementing a new automation testing process

    Hi all,

    Iím in a bit of a panic right now so please feel free to give me any advice at all.
    I've been a build and automation engineer for a relatively major project for almost a year and am used to the testing process of concentrating on one project (developing automation scripts, run daily automation, build scripts, verify builds). Each month we have different milestones and thus different sets of test scripts to code but itís always been focusing on that project alone.

    Now I have been hired to a tester role in another country whereby the situation is like this:

    There are multiple applications to support, possibly in the 20s of known applications (they can be applications of any types, SQL reports, DTS, Web Apps, WinForms); any developments to be done are requested into a queue system by the project managers aka system analysts.

    There are 4 developers, no testers ever had been involved. Currently the developers are handling the test in a buddy-like system whereby two devs will pair up and one becomes a tester and they change roles for the next in queue.

    I donít think there are any deployments or any daily builds, the changes/development made to these apps are probably on the fly.

    Iím not too sure how thorough they actually test the applications they develop but I am suppose to be their ďsaviorĒ in terms of quality assurance.

    My worry is that I donít know where to approach this issue from. I guess the first part of the solution is to gain the trust of the developers and make friends with them. Iím relatively new since Iíve only worked for 2 years, a year as a dev and as a year as a tester. I am very bad at politics. How do you make a someone feel good that you have found bugs in the software he/she wrote?

    The second step I was thinking of was to just handle the applications one by one as it enters the queue, to let them have the Design, Code, Test, Deploy cycle.

    Another problem is to do with tools, currently they only have the Visual Studio 2005 testing tool and that I know is not enough.  But given the diversity in the application types, Iím also at a loss as to what tool I should request for :/

    What would you have done if you were in my position?
    Sorry for the lengthy post.
    Really appreciate any advice or comments,

  2. #2
    Join Date
    Mar 2004
    West Coast of the East Coast!

    Re: Implementing a new automation testing process

    So can I assume that you have little to no manual testing experience?

    My advice in this situation is to avoid automated tools all together! This set of circumstances dictates that you will not be the savior, sorry. What you can do is learn one application at a time and write some basic manual tests to try and cover as much of the app. as possible. Help the developers when they need it, but insist that in exchange for your help, you need them to log, the test cases which they are using, to some sort of central repository. When you get more people and experience and you are not so busy, then you can consider if it would be cost appropriate to automate some of the tests which you have accumulated. You have a long road ahead, and since you seem to specialize in automation, you picked the wrong job. Maybe in a few years, the company will be ready for some automation, but it is not that time yet. Fight for what you know is right and be up front with them about your concerns. Speak with the development leads and management and offer your assistance and have a plan as to what they can do for you also.

    Best of luck.
    Personal Comment

    Success is the ability to go from one failure to another with no loss of enthusiasm.
    ~ Winston Churchill ~

    ...Rich Wagner

  3. #3
    Senior Member
    Join Date
    Apr 2003
    Wisconsin, USA

    Re: Implementing a new automation testing process

    Originally posted by dianas:
    My worry is that I donít know where to approach this issue from. I guess the first part of the solution is to gain the trust of the developers and make friends with them. Iím relatively new since Iíve only worked for 2 years, a year as a dev and as a year as a tester. I am very bad at politics. How do you make a someone feel good that you have found bugs in the software he/she wrote?
    <font size="2" face="Verdana, Arial, Helvetica">Diana -

    Classic first mistake. You made an assumption, probably without even realizing it.

    How do you know the bug is in the software that the developer wrote?

    The "politics" you speak of is really the art of examining the assumptions and throwing out the ones that don't hold water.

    In this example, the "bug" can be in one of three places - the code, the requirements, or in your test. OH NO! SAY IT ISN'T SO! But yes, it can be a faulty test too.

    So I would approach the developers with "I found an issue. I need your help in identifying what the cause is. I know it can be in one of three places...." and make "the code" the last choice. I think you will find that the developers will be very open to talking/working with you as long as you are perfectly willing to take some of the blame too if it turns out the test was wrong.


  4. #4

    Re: Implementing a new automation testing process

    Do you have a decent bug/issue tracking system that is used well - without people being beaten for entering issues and properly prioritized and worked? If not, that is by far the first place I'd start. Until you track the issues, you won't know what to do.

    As these other guys said, automation isn't the answer, as the military says "It's a force multiplier". Meaning properly applied automation makes short staff stretch further. But done wrong or at the wrong time it can also suck all your time to no result.

    Issue tracking identifies your targets and allows you to measure and report progress.

  5. #5

    Re: Implementing a new automation testing process

    Thanks for the reply guys,

    Rich W &gt; yes i do have manual testing experiences, 25% of the test cases have to be manually tested as i was unable to automate them.. i was aiming to automate their applications because the interviewer said that's my responsibility .. oh oh...

    Darrel Damon &gt; you're right, i shouldn't just go up to them and say, hey your code is buggy :X

    WhollyMindless &gt; currently they are using product studio right now to track bugs and issues whew..

    i guess i should think thoroughly if i want this... manual testing in the long run is not what i am looking for :| i don't mind manual testing like writing scripts to check something bit by bit (like dts transactions)...but if everyday i were to click the same buttons to verify builds i think i'll go beserk :|

    do any of you do alot of manual testing?
    Thanks again

  6. #6

    Re: Implementing a new automation testing process

    Yes and a lot of it too. Doing it from past 2 years, manually tested 4 poducts, and doing really great.

    But now is the time for us to move into automation, since the the product has become quite steady, and have a very good understanding of user requirements


  7. #7

    Re: Implementing a new automation testing process

    What you are describing is building an SQA process from scratch. This is NOT an easy task but it can be rewarding.

    You've hit on one of the keys in that you need to work out a way to interact with the developers in a cooperative manner. They've become used to a process that really doesn't incorporate testing at all and even in the best of situations there's going to be some inertia based resistance to change.

    The best advice I can give you to start is to involve the developers in the creation of the testing process itself. Sit down and talk with them. Explain what you're trying to achieve and get their input on how to do it. I'm not saying to defer to them, but definitely get them involved. They are the ones that have experience with the applications and will no doubt be able to give you a big boost in defining your test cases and procedures. The more involved they are in the testing process the more they will understand it and not resent the changes that it makes in their daily lives. Your goal is not to make them feel good about the bugs that are found but to feel good about the testing process by designing a good process in partnership with them.

    I'd also suggest picking up some books on testing and software design. You'll need to know at least the basics of designing a good SQA process in order to direct the discussions. Besides building a relationship with the developers you MUST get an accurate idea of what the current situation is.

    Once you've evaluated the current situation and have learned more about what the specifics of your situation is then you can evaluate automation and other testing techniques for how well they meet your needs.

    A couple of things you mentioned raised red flags for me.

    One tester is almost certainly not going to be able to give good coverage for 20 applications. The procedures that you develop should take this into account and be structured so that new testers can be added easily at a later date.

    The fact that they have not had any testers at all up until now is kind of scary. That may indicate a serious lack of understanding and appreciation for SQA by management. Be prepared for frustration when trying to get resources for testing or commitment to new processes.

    I've been through the process of starting SQA departments a couple of times. If conditions are right it can be great thing. If they're not it can be pure hell. I have turned down this type of job in the past because it was readily apparant that management just wanted everything to go along like it had been but with an extra monkey clicking around in the app. If they can't show you or at least commit to having defined practices for development as well as testing you may be better off finding another job.
    --- Hacksaw

  8. #8

    Re: Implementing a new automation testing process

    Beware - you may also use up the goodwill you've developed with other departments to get this off the ground.

    When you put your head up sometimes people want to shoot it off - even if you're doing something that is necessary.

  9. #9

    Re: Implementing a new automation testing process

    Wow, thanks for all the advice!

    Rash_Test : i've had a developer background, so i get really frustrated when i'm ask to test by clicking buttons [img]images/icons/frown.gif[/img] luckily for me, this new role is mostly focused on testing databases

    cvieira : you're hit the spot when you mentioned "SQA process from scratch", i was told this will be a really difficult task for me, also considering i've only had 2 years working experience!(magic word is if) if i pull it off well, i'll gain a great experience. i did have in mind to get the developers involved, especially in looking at my test cases, to ask for their input and suggestions. you sound really experienced in this area :| i'm really scared now ... but i am also excited at the opportunity, apparently i was told they'll rely on me alot because they really want this SQA implemented and i'm the only tester... *cross fingers*

    WhollyMindless : thanks for the warning... i'll keep that in mind :|

  10. #10

    Re: Implementing a new automation testing process

    Dianas, I worked on a similar project and the biggest problem I ran into is that there was no upper management support. They were not willing to add funding to the test team (me) and they were not interested in implementing a SQA process (once bad habits are part of the culture, it's hard to change them), yet they were concerned about quality and the customers were beginning to raise questions about quality.

    Last I heard the whole project was cancelled by the customers and everyone in the project got their walking papers.

    Good luck.


Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
BetaSoft Inc.
All times are GMT -8. The time now is 03:52 PM.

Copyright BetaSoft Inc.