Test Automation Problems (5) – Integration – Support and Feedback

Posted by Albert Gareev on Sep 15, 2009 | Categories: Problems

Parent page: Test Automation Problems

Support and Feedback 

Business logic investigation, test case design, and test script programming are distinct activities. A professional automation engineer is capable of carrying out the all three, however the overall progress will slowdown. Since test automation project often starts when automated testing results are already needed there is no surprise in disappointment of the long building curve.

As discussed in the previous posts, identifying the all requirements is a great challenge and informal task. Agile development practices do allow succeeding even with unclear requirements but it’s heavily based on the user feedback. 

Points of consideration 

1)     BA/QA Support 

  • Even if detailed and clear documentation is available it always takes certain time to “play” with the application and to get used to it. A few demo/training sessions will help to quickly get the overview of application’s structure (from the user’s perspective) 
  • Once set up, the infrastructure (test input/output data files, table structure, test results output) will be used throughout the all automation / automated testing lifecycle. Investigating what is already in place in testing process will help to set up the infrastructure better matching existing format, and re-use existing data 
  • Test scripts require test data (input and expected result). Test data creation does not require programming. Manual testers helping automation engineer with test data set up will not only boost release of testing scripts but will get more familiar with them 
  • Not a paradox, testing program also needs to be tested. Manual testers could greatly help in automation by validating implemented test logic and reviewing test results 


2)     End-user feedback 

  • Test execution report and fail report are the end product of automated testing. End-user feedback will help getting them as clear and detailed as required 
  • Manual testers reviewing and validating implemented test logic could provide valuable suggestions on what else could be covered within it or by extending it 


3)     Management Support 

  • In the beginning of the automation project it’s critical to understand the overall testing process and test automation needs. If testing goes process through traditional Smoke-Regression-Sanity phases then building Smoke Tests will help to benefit from automation sooner. If testing process is informal or the application’s GUI/logic change often than automating core functionalities first will give better test results delivery rate over the effort spent on continuous maintenance of the scripts 
  • “Knowing what test cases to automate” is a popular question. Answering it from the end-result stand point, manager should evaluate 3 factors: what coverage will be gained, how fast to create, how easy to maintain. Automation engineer will help answering those questions and will add one more criteria: what could be re-used to cover other test cases 
  • Although regression testing phase comes closer to the end of the test cycle, including automation engineer to walk-through meetings where new features / application changes introduced will help in updating scripts earlier 

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.