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.
tristaanogre wrote: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.
tristaanogreSorry... I disagree with you... What you're describing.. it's too good to be true.. The point is, that's only true in theory.
For example: one of the main objectives on working Agile is on delivering working software every sprint (2 or 3 weeks), for the purpose of providing a demo to stakeholders. In these demos the main goals is happy flow usage of the application. There is 0 focus on robustness, good quality, etc.
And again it's stressed by the fact that one other important approach in the Agile Manifesto is that interaction between people is considered to be more important than documentation... And as you all know, oral communication just doesn't provide good enough basis for clear and unambiguous documentation, and so I stick with the opinion that Agile methodology doesn't provide any solid safeguards for robust Quality Assurance.
To provide real Quality Assurance it's better to start using a different software development methodology which encapsulates "quality assurance way of thinking", respect for good quality specification and documentation, and respect that developing an IT system is an engineering job.
With just knowing what kind of bugs have surfaced for us in a development cycle I have not seen a need to automate individual stories and regression test them within a sprint. Overall processes and higher level processes I could see being useful though. I would like to hear the other side of that argument to know why anyone would want to do that - automate individual stories for regression testing. Any input?
Because individual stories exercise code that could be subject to change. It's a CYA deal. Basically, I want to have the confidence that, when the code changes, that we'll catch any adverse effects of that code change BEFORE we get too far down the SDLC path. You're two vending machine test cases cover slightly different code paths. If there is the potential for code to change in that code path, then I want to make sure that we don't break the functionality when it does.
As I've mentioned a few times now, there's a decision making process in determining what to include and what not to. Each project, each app, etc., will make those decisions based upon what they know about what's in there. The risk of NOT automating something needs to be weighed against the investment it will take to automate it. If the risk outweighs the investment, better automated it. If the risk is acceptable in light of what it will take to automate it, then don't bother.
But one thing that I've found in my years is that is NEVER a fool proof process, weighing those risks. There have been numerous times when we've weighed the risk and said, "Nah, that will never need to be retested" and so we leave that case out of the regression suite.... and then, no joke, within a day or two of releasing a new piece of code, that thing that we decided not to regress breaks... and we're stuck scrambling to get patches out not to mention appeasing customers.
It's a process...and risk is part of it. I tend to lean towards automating as much as possible and makes sense rather than only "high level" stuff. More often than not, it's those little details that break and make for angry customers than it is the big stuff. See my pro-tip post down stream here concerning something we opted not to do in automation that ended up getting us some VERY angry customers.
I'd say new features in general are lower risk. I have never seen a customer, or business user, angry about details so much as an entire area of the application that just doesn't work or isn't accessible. Like I said the process needs to work at the very least so I have found that to be the highest risk in any situation. If people can't complete the process then they can't do their job and that usually makes them unhappy. Most important though what I am getting from this is that it does not necessarily make sense to automate every single story. Which is what I was getting at. When I started here the idea was proposed to me to automate everything and eliminate manual testing. Which if you saw how manual testing was done you'd probably understand that there wasn't much to replace and a very VERY scripted approach that appeared to fit into a DDT perfectly. Only after a year of research and observation that isn't quite how it is really working and other QA appear to just be doing the manual scripts to get them done - more than anything else.
