Overcoming the Technical Doubt in Automation Testing

Is our project mature enough from a technical point of view? Do we need to plan ahead to have a good technical start? Does the process matter and does it interfere with our technical decisions? Although automation testing is a trade-off between budget, time and quality; one of the most rewarding skills for a QA is the technical one. Improving and getting better at a technical level can lead to overcome our day to day technical doubt in the automation projects that we work on.

Transcript

1. Overcoming the Technical Doubt in Automation Testing 3 Pillar Global
2. Doubt, noun = a feeling of uncertainty or lack of conviction E.g. "some doubt has been cast upon the authenticity of this code" Technical debt, concept in programming = code that is easy to implement in the short run is used instead of applying the best overall solution
3. ...by becoming better 1. Technical concepts vs. Software dev methodologies 2. Know automation testing architectures 3. Be ultra-modern 4. Improve coding skills
4. #challenge 1 master the process
5. Scrum in Tech • Manual Test Cases • Frontend • BDD • Automated Test Case Coverage • Less time to code • More time spent on metrics • Takes time to adapt to changes
6. Kanban in Tech • Backend • TDD • Focus on code structure • Code coverage • More time spend on code • Less/No time spend on coverage • Quickly adapt to changes
7. Scrum vs. Kanban in Tech Improve credibility with clients • Frontend • BDD Focus on continuous delivery • Backend • TDD High product quality • Manual Test Cases Increase productivity and quality • Code Structure Product stability • Automated Test Case Coverage Increase efficiency • Code Coverage Team members reach sustainable pace • Low in tech • High in coverage Team members have ability to focus • High in tech • Low in coverage Allows client to change priorities and requirements quickly • Needs time to adapt to changes Reduction of wasted work/wasted time • Code - Quickly adapt to changes
8. Success in test automation requires careful planning and design work.
9. #challenge 2 having an awesome ecosystem
10. Great ecosystem? • Analysis of System/Requirements • Research • Programming Language • Automation Frameworks • Test Management System • Continuous integration • Integrated Development Environment • Repository
11. Mobile cross-platform ecosystem • IntelliJ IDEA • Appium • Android SDK • Java JDK • Node js - install appium • iOS 9.0 and 8.4 Simulator • Xamarin Android Player • UIautomatorviewer • Maven • Cucumber • Junit - unit testing framework
12. API/UI web ecosystem • PyCharm/Vim • Django • Pytest • Bamboo • Bitbucket • AWS Services • Selenium • Virtualenvs • Drivers • pip • A lot of libraries
13. Test Scripts Desired Capabilities (iOS/Android) Test Case (Cucumber) JUnit Reports Simulator / Real devices Jenkins triggers the test execution Jenkins pulls the code from GitHub ...and sends the results back to Jenkins 1 2 3 4 5 SELENIUM Application PATH Device Name Bundle ID Platform Name Platform Version Implements WebDriver specifications
15. #challenge 3 be a coding guru
16. Why? When? What? How? • Objective • Establish automation priorities • Repetitive • Cause human error • Require multiple data sets • High risk of defects • Different hardware and software • Suitable Design Pattern • Updates
17. Good automation code • Coding guidelines, clean code • Parallel execution • Good structure: • TDD: components and UI • BDD: test packs and components • Reduce the use of Test Data • Continuous code review • Refactoring • Be Flexible
25. #challenge 4 change their minds
26. How should I start? Research. • Client’s needs • Frontend/Backend • What SDM I use? Do I need metrics? • Diagrams • Risks • Prototype • Being ultra-modern • Learn, learn, learn...
27. #challenges accepted! “You don't have to be great to start, but you have to start to be great.”
28. @AlexandraNagy nagyalexandra28 alexandra.nagy@3pillarglobal.com