Agile testing new sprint having round 1500 test case how to do it ?
We are planning to start the new sprint and in that we may have round 1500 Test case to execute.
So what factor we should consider during the planning .we have to do with two tester and we have 14dys of time .
1500 test case? Is this an interview question.
In general you may wish to prorities your story, put resources on nearly same weighted story, intreact with dev, pm to refine story acceptance criteria, pick infra and early devlope story first, review of test cases process should in place. Spike and productivity stories shoul not be overlook.
Hi Yogi , Thanks for reply .
No its not n Interview QA. We have one printing SW where we got some major upgradation so we will be using agile testing .
As Yogi said, I'd start with prioritization. Look at the most critical user stories and the test cases linked to those, then less critical.
Also, look for test cases that can be run concurrently: if you have test cases that all relate to a single aspect of one function, it makes sense to perform them all at once - say for printing, you might have one test case that covers the layout of the initial print screen, one for the layout of the next screen and so forth. You can cover all of those by running one of the test cases covering the end to end print process.
In the case of printing, you'll probably also want to group your test cases according to the most used hardware. Since you say you've got two testers to do this, I'd recommend having one hooked up to the most popular printer, and the other to the second most popular.
The goal here is that you hit your steel thread/happy path test cases first, the rest of your 80/20 cases (the 20% of your system used by 80% of your users) next, then the rest by priority. That way if you don't get to everything, you can be confident that most of your users will be happy.
One of the key skills of a QA Lead role is coming up with a reasonable test plan. They key to being a good QA lead is knowing when you can test less, and when you can push back against unrealistic expectations. If they give you some # of days before a test plan is even signed off on, than you're in a pretty bad position.
Before target dates are discussed, the following needs to happen.
1. High level specifications should be flushed out.
2. Components that would be changed would be identified, and the amount of risk introduced with that change.
3. Identify a Features to be tested and more importantly features you won't be testing. Explain what risks would be covered by running by tests you plan on running.
Before this point, no target dates should be discussed. Only until you have done 1-3, will you have the basis of establishing realistic expectations. From here, you and project management and dev can discuss target dates. You can either say it's ok, or you can push back if it's unreasonable, and you have the basis to do so because you've done your homework.
It's in my experience that business folks want everything done yesterday. They'll set unrealistic dates because they might not have the same level of insight of the systems they are selling. If you can explain reasonably why X number of days is unrealistic, and back up what you say, they'll respect you and wouldn't mind descoping the project. If you don't create a test plan and justify the time you reed to test it right, then they might think you're just sand bagging. It's really more important the job is done right when you say it is, than it is to be done quickly. If there are many business dependencies on the business side like marketing buying commercial time and magazine ads touting a new feature that isn't delivered yet.. then that's when the **** hits the fan.
Last edited by dlai; 05-17-2013 at 08:12 AM.
I am glad that human medical surgery is not done using the Agile Approach. Could you imagine the hospital saying we have 200 operations that need to be done by six doctors in 3 hours? Just do the important portions of the task.
I worked on Agile projects. They seemed to produce junk. But the competitors are also releasing junk. So everyone in the industry is selling buggy systems and making a profit because they are all just as awful. Also they ran me around like a rat in a maze. We would have team building outings to a picnic or go-cart racing two days before they lay 20% of the team off.
If they are pulling off a stingy gimmik, do it back. Create a rediculus harness, have others fill in data sheets. Have it do something that looks cool, but does nothing.
Does it sound like I like Agile?
bklabel, you sound like you've been burnt - and badly - by what I've heard called "agile, but..." and similar things, where there's a lot of noise and following the outside forms of agile without actually being agile.
My view is, the end goal is high quality software. The way it gets built doesn't matter so much - with the caveat that places with stringent documentation requirements aren't likely to ever go truly agile (as friends of mine working with software for the medical industry inform me). The biggest blocker I've found to reaching the end goal isn't the way the software is produced. It's upper managers who insist on unrealistic deadlines, or can't accept that they're not top-line coders any more and create more havoc every time they overrule someone who knows the code better, or micromanage, or just plain don't trust their people to produce good quality work. It sounds to me like you also got caught with the old fashioned @$$hole type as well.
I don't see any difference on that side from a tester or a programmer perspective, other than that the testers usually get insulted more because so few people realize how complex good testing is (or how often dedicated testers will do the heroic effort because they don't want to see the whole thing go down the tubes).
I've studied engineering methods formally during college. What a lot of people call Agile is not really formal agile. The only real difference between true Agile and waterfall (actually many companies don't even do waterfall and RUP correctly either), the difference between Agile vs. RUP, is it has various ways to limit the size of the project. For example, Scrum uses the idea of fixed lenght sprints, Kanban uses the idea of fixed size buckets that limit work in progress.
None of the Formal Agile methods does not advocate throwing out testing and documentation procedures out the door.
Hey hope things are going well, what I would do...
Bring internal key stakeholder into a room (developer, pm, test manger, BA)
Prioritise your regression pack, bring all high priority scripts into your test schedule
Identify a batch of regression tests which are directly impacted by new features to delivered as part of the release (regardless of priority) add these to your test schedule
Bring all tests written to test the new features of the application and add them to your schedule
Identify high impact defect re-test fixed in the previous 3-4 releases and add them to the schedule
All test cases in the schedule will give you a good level of coverage if you need de-scope any further tests its important its done as a team so everyone clearly understands the risks.
Also if an agile methodology is to be followed the. Perhaps it's worthily considering test automation
Time taken to raise defects
Time taken to re-test defects
You will have impediment and down time
Remember that 14 days will not only be used to run execute test cases, there's loads more that comes with it
Hey your right, i have many years of testing experience, I'm currently writing a Masters dissertation (spare time thing) on Agile and I said something similar in a job interview about 1 year ago, the interviewer disagreed, to some companies all these are just buzz words.
Limited documentation means plan document and design for a sprint/(period of time) at a time, it doesn't mean no docs.