Tag Info

Hot answers tagged

4

Point of testing units and components before whole system is to localize bugs BEFORE they damaged some unrelated part of the system, causing confusing red herring error. If you mock the surroundings of a component, you eliminated moving parts - and localized the bug. Of course you need to weight the effort to mock: because it is code, it will have bugs and ...


4

I'd suggest you start by taking a look at some of the related questions and their answers, particularly this one and this one. Also, if you don't have Crispin and Gregory's Agile Testing, get it. Some things that I've found helpful include: Test plans will still happen - but they tend to be much more lightweight and built as you test. Some tools support ...


3

I think exploratory testing is one of the (agile) skills you can use in an Agile team to increase quality, but it is not an essential part of the Agile workflow. Though I think its slowly becoming a industry standard. Revised books like the Art of Agile and newer books Agile testing are giving it their own chapter. This clearly means its a technique worth ...


2

Agile testing generally means the practice of testing software within the context of an agile workflow. When testing in an Agile way, there are few, if any, rigid adherence's to requirements documents and checklists. The goal, instead, is to simply do whatever is necessary at any moment to satisfy a customer’s requests, replacing documentation with ...


2

Is Exploratory Testing a core part of Agile Methodology? or it has no link with Agile process. Kindly explain in detail! Let's look at what each one of these things is and then see how they might go together. Exploratory testing is an approach to testing. You can use any test technique in an exploratory or scripted way but the important thing about ...


2

Testing is not an individual function on a scrum team. The concept that developers develop and testers test (I coded it I am done, you test it) is a waterfall practice. The team is responsible for a feature getting into a "done" state. Testers with SQA experience or as their professional discipline bring value in their understanding of how to test and how ...


2

I don't have time to do all the documentation, test cases, strategy, test plan, etc. I almost always recommend producing the minimum necessary documentation. Call it lean documentation, minimum viable documentation, whatever. You want just enough that helps plan and guide the testing you need to do. Anything more starts to lose value very quickly. ...


2

Actually, we're doing this exact thing you mention. Testing in the same three weeks as development is nefarious for testing time and quality overall, as you seem to have experienced. So, we're testing for two or three weeks after the development sprint has finished. By delaying testing for a few weeks, you'll be working on a fully delivered sprint ...


2

Having done 23 years of performance tests including trouble shooting, correction, and rerun I can agree with testerab on long reports full of nice graphs that remained unread (and even if scanned certainly not understood). Of course if you are a paid for third party, or even expendable employee, that report might be the only way you can justify your costs ...


2

I have served as QA lead for multiple Scrum teams. Any release might have multiple teams releasing at the same time. I was responsible for the overall QA sign-off and test summary. What we provided as a summary document: What user stories were included from each group Any documented defects that were not fixed and therefore constituted a release risk ...


2

The best advice I can give you is to ask the other team what information they need to be successful. I've been in the opposite position where I'm supposed to automate tests others have made. Aside from this being a bad practice, creating too detailed documents or creating the wrong details will only waste both of your teams time. Send over what you have ...


1

First, I want to echo milinpatel17 's answer. If they are not cooperating NOW, at the start of the process when people should be psyched about it (see http://www.1000advices.com/guru/project_mgmt_7phases.html ), how would they be a few month into the project? Specifically to your question: If you give them the scripts you now run manually, you will get an ...


1

You think it's impossible! Not really. Here is how to accomplish this. Short and sweet. QAs are involved in pointing the stories. You decide in sprint planning/refinement if any automation needs to be done on the story. Everyone including QAs know the effort it's going to take. So, you point them keeping that in mind. And, you mention that as an acceptance ...


1

You need to redefine what the definition of "done" is for a ticket. A ticket is not complete until manual testing, documentation, and automation are done. Project Managers might get upset at first but it's not hard to win an argument when you tell them the increase quality means.


1

If your management is so focused on short time returns that it will not invest in increasing your skills to improve your productivity - you should do it anyway in your own free time. All tools and documentation are free, you just invest your time. Of course your progress would be slower, but after some time you should be able to show some results, proving ...


1

In all of the agile projects I have participated in, we have used the same mechanism to track defects as we did stories. In many, but not all of the agile projects I worked in, we did not track defects for stories in the current iteration, instead we would note the defects in the story and push it back to developing. If we found a defect outside of the ...


1

Janet Gregory most famously known for writing one of the go to books of our time on Agile Testing, Agile Testing: A Practical Guide for Testers and Agile Teams, Defined the Agile Testing process in a presentation i recently watched found here on skills matter. Project Initiation: Get an understanding of the project(business) Release/Project Planning: ...


1

This all feels like a great waste of time, because there is a very big chance no-one will read them ever. I hear you on this one. I have wasted far too many hours of my life producing documents that nobody ever read - enough so that at one point, I devised Anna's Chocolate Bar Test. (Somewhere in the last half of the document, you state that you have ...


1

I do not know what documentation you currently has or what tools you use. So I do not know is all of the following possible for you. But maybe you found some helpful ideas. Defect Overview How many defects was created. How many defects was fixed/closed. How many defects of the ceated/fixed/closed has a low, medium or high priority. (Maybe you has more ...



Only top voted, non community-wiki answers of a minimum length are eligible