Bringing Automation to Manual Testers

Bringing automation to manual testers (with no budget)

There are 9 development cross-functional agile teams. 2 testers and 5 developers. Tester vs. developer? Staff of testers who only do manual testers. Defect leakage is lower. No problem form an efficiency POV.

If not have automation training, then job satisfaction is down b/c Google says manual testing is dead. Have no training budget for tools or training?

What could he do? Do a number of activities to create hand-on experience to do small tests on their own. Brian isn't from a testing background. It should really come from the testers. Would love to have someone from testing department to step up and lead it. Brian is being a facilitator.

Potential Tactics

• Technology association Oregon to have a panel discussion to host at their office. Invite local experts who have implemented automation, and get testers to come to hear success stories. Hear about tools to use, Learning Curve.
• Brown bags: Do a series of internal presentations about automation with the tools and code base.
• Academy classes: Talk for a topic and ask questions.
• Use power shell as a testing tool. Invoke domain business objects and do some testing on.

Need to foster hands-on experience

• Record and play automation tool. 3 classes to work through an application of record and playback -- all doing the same one. Everyone who wanted to do testing could do that. See scripts that was generated, and talk about the script after the fact
• Then train the testers in programming over 6-8 weeks, and have homework. Train control structures and basic OO programming. Could buy books.
• Organize a user group to show others.

• Identify places where automation would be helpful.
• Create opportunities

How much free time do testers have? Are they storming or forming? If they have homework, then they'd have to do extra time.

Introduced test automation, and cut regression test time by a certain amount of %. Personnel turn-over. If need 20 hours to automate test, then is there going to get pushback.

Commit to a story that's focused on quality during each sprint. Tag stories that you can track and report on them.

Did some training classes where the students train each other in Java. People who are novices are better at training each other. Need one person who knows what they're doing.

Did training of OO analysis and design at a bank. Cultural differences, and they didn't take well to outside training. Start small and engage testers at developing their own curriculum. Take into account the culture, and it's more likely to succeed. Start small and grow it rather than starting with a big bang. Time is ripe, and there's enough momentum out there that needs to be pushed a bit.

Testing new feature, is it difficult and take significantly more time to test it automatically.

Anti-pattern is short-term thinking rather than long-term planning. If product manager isn't supportive from a timeline perspective, then the long-term benefits will be the first to go.

Has to be a commitment to the long-term to get out of the short-term, fire-fighting mentality. And slowly quality slowly degrades.

IT is on board for Agile, but didn't educate business about agile. Need to slow down in the short-term in order to go faster in the long-term.

Implemented agile, and the deliverable times is down to 2 weeks, and the QA became the bottleneck. Then had to go back up to 3 weeks. Need to automate the testing. Review the tools. Have the engineer go to QA staff and train them. QA staff is heads down on their 3-week cycles.

Fostering the sense of leadership, and have the developers start to evaluate

Gauge their interest. How easy for them to pick up.

In choosing tools: Easier to train on? Or better to get a tool best for their technology stack? Potentially have a BDD.

Developers will train the QA staff to take the test for Java certification course done by Oracle.

Strategy for training people: Local tech user group to do their own training. Struggling how to teach novices who don't have full time to learning this. Start with 1-day workshop to get development environment set up. Added a 2nd user group meeting for new users with 1/2 trainers and 1/2 people who are novices. Ask experts how to do a specific task. As an expert, you do them so much that don't think about them as concepts. As a practice, then you write down the question so that you can teach it to them the next time.

If someone asks it, then others are thinking it.

• Python and Ruby groups are having a 2nd meeting every month with an occasional workshop. Beginning Ruby meet-up. Lots of people who want to learn. Experienced people know that you can learn bad things, and so testing helps to learn the good ones. Went over xUnit and BDD and some Cucumber stuff, and there will be more sessions like that in the future.

A ladder of tasks and competencies for people contribute and start to being able to contribute. In Drupal, there's the Drupal ladder.

• Tester pull down developer code, and build it and run it.
• Look at unit test, and be able to read it. Start to turn Blackbox testers into Whitebox testers
• Open hatch: One Barrier to entry is using version control. How to make a commit to git, and it's like a video game. Make a pull, and make a change. And then they get points or stars.

• Automate low-hanging fruit. Start with some easy tests to get experience so that they can get through rough spots. Start small. Case studies: Need to have small projects where automation written didn't need to be preserved beyond task that they could do within the course of their regular testing.
• Optimizing whatever is really repetitive and whatever would do the most impact in the least amount of work. Automate what you're doing a lot, and look for something has a decent bang for your buck.

• SQA User Group is just getting started up -- http://www.sqaug.org/
• Work on acceptance criteria as a cross-functional team, and help business see the benefit so that we can invest more time and energy into QA.

• Started using Fitness tool to automated business-facing acceptance testing, and then the product managers would look at it within English. But the product manager didn't care or look at the test. Testers and developers had lots of conversations which were really helpful.

Business object layer exposed through an API, and the testers could give a scripting language so that they could reach the test objects. Testers could write business-facing acceptance tests with Cucumber, and then it'd be a good step towards automation.

Java has a lot of odd rules for non-programmers, and it'd be intimidating because it's not intuitive.

Programmers know more than one language. Learn the easiest things to learn, and once you have the concepts, then going to more complicated languages like Java become easier. Don't try to learn everything at once. Make it cumulative.

If you need budget, then ask "How much is QA saving you?" instead of "How much is QA costing?"