Here is my presentation in the monthly meetup of Agile Vietnam in August, 2015. In this session, I shared our approach and implementation for current Agile project in both mindset, team structure and technical aspects. It’s really good that I got a lot of questions during my presentation time and feedbacks afterward – lot of them conflict with my share in some points or wholeness. If you have something like that, please comment or contact me for the open discussion as you are a testing domain master who may have different approach to me, an Agile / Lean fan and have another view point of whole project and don’t just focus on testing area.
But please note:
- My share is just in Agile project. It maybe incorrect for another project that doesn’t follow Agile method. For example, “the total cost usually doesn’t change” seems incorrect in a traditional project.
- Our specific doings are not new or magical things – they are just a normal things that you are doing in any project. For example, unit testing is as the same as it in any project. BUT my idea is the wholeness where we can combine the separated things together and make it automated and run it everyday. It recalls to Agile testing manifesto “testing throughout over testing at the end” to “defect prevention over defect detection”. I’m sorry for lacking of recall to my share before about our continuous integration, you could find it here – it’s not the project I showed today but the idea is the same.
- It may conflict to you because it seems to decrease the importance of tester (QC, QA) role or work. No, it helps tester (QC, QA) reduce her works by quality built-in but cannot replace her importance.
And here is my view points (again, in Agile project):
Automation testing is not a tool that let us work from Monday to Thursday and let the machine do your repeatable works in Friday. It’s a method to let us work from Monday to Friday safety by knowing our issues and preventing bugs everyday.
Yes, it recalls to“testing throughout over testing at the end” to “defect prevention over defect detection”.
We have to do the manual works for automated test, includes the testing for it. So more automated testing could be done, more manual work may need to be done.
Remember we usually refactor code / structure in Agile project instead of having a fixed design in traditional method, so we need to continuously maintain the test afterward manually.
The total cost usually doesn’t change. But whenever we want to execute large set of test cases in a short time, we can – that we normally cannot do by using people.
That means if you need to spend cost (people, effort, money, time…) for testing, its total usually doesn’t change, no matter that the automation or manual testing is implemented. So please define your objectives of applying automation testing. If you care about time reduction, please spend more money or people. Or if you care about people (team improvement), please spend more time. In my opinion, you could benefit more from automation testing in waterfall project than Agile project in maintenance cost (as it usually doesn’t change) BUT it doesn’t help in quality built-in and continuous integration run.
More unit test, fewer UI test.
Could you remember the automation testing pyramid?
Thousands thanks to you for spending time hearing me. Millions thanks to you with your feedbacks, especially your disagreements – just comment or contact me for open discussion. I may call for a coffee for the discussion in very next day, would you like to join?
