I am facing a similar issue in my current position of how to work in test automation in an agile environment.
The primary concerns I have are reusability and where to focus our efforts.
I have for some time been automating our test cases just for the sake of getting them done and appeasing my coworkers who are desperate to justify their necessity - but where does the meat go? I have yet to see any value in this type of automation. In fact I find writing test cases to be a complete waste of time and added fluff to the QA process. Writing out scenarios and breaking down requirements into meaningful action items to test I have found to be pretty useful but writing out all my steps for everything I test...waste of time.
Just as I drive to work every day I do not need to write the steps and document every turn I take to arrive at my destination. I do it quite well on my own - naturally - because I have done it for some time now and I am familiar with the steps involved to start my vehicle and arrive at work. Sure I occasionally look for alternate routes - or maybe even drive somewhere besides work - but the maps do not apply to subsequent trips and therefore do not see a purpose to keep them around.
I know how to drive my car - I know how to use google maps - I'm prepared for whatever lies ahead.
So automation can jump through a bunch of steps with different data sets, but so can I - and I learn more - catch more - do it faster without having it automated or wasting time on the fluffy redundant documentation of that process.
So I have typically been leaning towards Automation being valuable only in regression testing.
What do you all think about test cases and can you elaborate on the greatest value that automation has in the agile environment?
Ryan_MoranThanks for your reaction.
I think the credo "context is everything"also counts here.. It all depends on the potential risks involved in the system you are testing (whether it's manual or automatic: doesn't matter in this case).
Example: the (sub)systems which run (fly) an airplane will need the full bunch of documentation, and the 'complete package' of testscripts, worked out in detail. No compromises. Why? Because human lifes are potential at stake.
When your testing efforts are focused on a "regular" IT system in "typical" business, most of the times human lifes are not at stake, and therefore risks can be lower (as an example). Mix these context aspects with (lack of) available to time, resources, etc, and you have to make the decision if complete 100% complete and accurate testcripts need to be worked out in 100% detail... And this again relates to agile way of work: a lot of companies choose to work 'agile' because of some of the benefits of this software development method: it results in fast deliverables, with a high degree of interaction between end users and developers...
But, at the same time, Agile has it's cons as well.. One of them being lack of robustness, and this is caused by lacking of time to work out all the documentation and all the testscripts you are referring to as well...
Putting it back togeter in the example: I am 100% there is no airplane manufacturer in the world (whether it's the plane itself, or any software systems running in/on it), which even starts to think of working Agile for their development/manufacturing processes... the risks are just too high! To rely on the 'old, classical', documentation, decent testing, in each and every (sub)step of their development/manufacturing processess...
If the company you work for has choosen to work "Agile" you can conclude for yourself that quality assurance is not the major point of focus, in whatever their it systems need to do. Being a tester in an Agile culture has its challenges, you can figure it out yourself.....
mgroen2 wrote:
If the company you work for has choosen to work "Agile" you can conclude for yourself that quality assurance is not the major point of focus, in whatever their it systems need to do. Being a tester in an Agile culture has its challenges, you can figure it out yourself.....
I disagree with your statement that utilizing an Agile methodology (SCRUM, KanBan, Lean, etc) means that quality assurance is not the major point of focus. At the company where we implemented a blend of Scrum and KanBan, QA was DEFINITELY in the focus of our development. The purpose of the Agile methodologies we employed were not simply to get deliverables out the door at a high velocity, but to make sure that what we DID get out the door was good quality. This meant that we needed to adjust our expectations as to how many deliverables we could get out within a particular time frame... and that's where companies frequently fall down. They get too caught up in "get it out, get it out fast, get paid fast" and forget that exponentially increasing cost of failures the further down the development line you get. If you build in good QA practices within your Agile methodology, even if it, contextually, doesn't make sense to do the robust documentation, you'll still have good quality product. In this I agree with Ryan_Moran... sometimes documentation is done simply to say that the documentation is done... which goes back to that rule I mentioned about artifacts. If you write a test plan with the full robust test scripts, execute it once... and then never look at the documentation EVER again... why the heck did you spend time creating the artifact in the first place?
tristaanogre wrote:
mgroen2 wrote:
If the company you work for has choosen to work "Agile" you can conclude for yourself that quality assurance is not the major point of focus, in whatever their it systems need to do. Being a tester in an Agile culture has its challenges, you can figure it out yourself.....
I disagree with your statement that utilizing an Agile methodology (SCRUM, KanBan, Lean, etc) means that quality assurance is not the major point of focus. At the company where we implemented a blend of Scrum and KanBan, QA was DEFINITELY in the focus of our development. The purpose of the Agile methodologies we employed were not simply to get deliverables out the door at a high velocity, but to make sure that what we DID get out the door was good quality.
---------------------------------------------------------------------------------------------------------------------------------------------------
With this objective in mind, it sounds very unlogical to use Agile. Let me ask it this way: why didn't management of your company used Cleanroom Software Engineering methodology? This method and underlying approaches relies much more on the prevention of bugs (instead of the Agile-ish "continous rewriting") provide much more instruments to provide in depth solid testing.
Because quality is not dependent upon the methodology but on how well it is implemented. If you go into an Agile structure, no matter the tool used, with the mindset of "We're just going to write code and get it out quickly", then yes, quality will suffer. BUT, if you go into an Agile structure with the mind set of "We're going to write QUALITY code, make sure it's good stuff, and deliver it as quick as we can without sacrificing quality"... then you're golden. And, keep in mind, that quality is not the job of just one group of folks injected at the end. It's a mindset that needs to start even before the first line of code is written. So, as long as quality is the mindset, you can use waterfall, agile, iterative, spiral, blah-blah-blah to your hearts content... because you are approaching it with quality as the goal.
