Hot answers tagged

25

I've seen TDD/BDD/ATDD used interchangeably with Scrum/Kanban/Agile, so the confusion is understandable. Here's my take on the differences: Waterfall is a software development methodology where each kind of development activity happens in a separate phase (requirements gathering, design, development, testing...). Typically, waterfall projects work best ...


17

This is very common. There are basically 3 parts to the problem: Measure. Track stats to know when the backlog is getting worse or improving, week to week Identify. Figure out what things you need to change to stop making it worse week to week Cleanup. Clean up the backlog you created, bit by bit I'll focus on part 3 - the cleanup - ...


16

Define a definition of done that includes testing. Define which testing effort is minimal needed to get the work done. Time boxed exploratory testing session for each story, just after coding is done or even during the coding sessions, pair with developers to test their work Good balance of UI-, Service- and unit-tests, read about the test pyramid ...


13

An answer - as Phil implied, is that you take every record and playback tool you can find, and burn them in a fiery pit of despair. I probably got myself a down vote for that, so I'll try to earn it back. Good Agile teams test constantly - not just at the end. If you include test design as part of feature design (and consider how the feature will be tested ...


12

In addition to Michael Durrant's excellent answer and the equally good comments, I'd suggest you consider a few things: If you have not already done so, devote some time to analysis of your bug backlog. You will probably find some combination of the following things: The bugs cluster in certain areas of the application. These will typically be the areas ...


10

What value is "yesterday, today, blocking" to this team of testers? Presumably they have similar scrums where they present the same information to the functional team they are assigned to. So you may be asking them to repeat what they have just said, or will soon say. Perhaps you instead want to focus your meeting on "what is important for other testers ...


9

I second (third?) the congratulations! While I'm nowhere near as experienced as Joe or Bruce, I can offer a few tips from experience: Communication is critical - you absolutely must have at least an instant messaging application to talk real-time with your team. That application should also be something your development team is using since you want your ...


8

What you have described so far is something I'd call 'scrummerfall', but given how it often turns out, could be spelled scrummerFAIL instead. I see several issues that need to be addressed. @Aruna covered several in their answer, which gets high marks from me. To what they have said I would add the following. 1) the team doesn't understand what 'DONE' ...


7

It really depends on what you're trying to achieve with your automated tests. The answer should drive your approach. Are you trying to: reduce regressions? reduce the amount of repetitive manual checking your testers have to do? (This may be the same thing as reducing regressions.) please a manager with some magic numbers? Some ideas: Test first. Make ...


7

In agile environment the distinction between a tester and a developer is blurred. Testers are not the solely responsible or even the primary owner of quality. Quality is a shared responsibility of the whole team. Individuals in an agile team may specialise in a particular role but will take on different roles depending on the context. Testers who are out of ...


7

When working with agile (or any methodology) I would suggest making your testers part of the team, rather having a separate QA team which is isolated from all the work. (This also means sitting the testers with the developers if you are in the same office.) In your points above you have listed a lot of tasks, these tasks are not the sole responsibility of ...


6

Tracebility matrix is a tool. It doesn't have any inheritent value, but it might be easiest way of mapping certain kind of relations between tests and requirements. As with any other tool, if it seems to work well, use it. If something else fits better, use that. If the tool nearly fits your need, modify it to give what information you need. If testing is ...


6

I wrote something recently that might help you out concerning using QA resources in an agile team. In essence, what you need to do is allow for your team to provide continuous feedback by making sure development is able to be continuously integrated and deployed to an environment where QA can run their test cases. You may have heard of a "Daily Build" site,...


6

In my opinion, there aren't any extra skills need to test a stable system. What tends to happen once the system is stable and not under continuous development is that the proportion of time spent on exploratory testing drops compared to the proportion of time spent on regression and checking. I'm assuming here that by "stable" you mean that the requirements ...


6

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 ...


6

Kanban and Scrum are Agile process frameworks and therefor have short iterative development cycles as compared to the longer separate phases of waterfall projects. Agile projects focus on getting a working product in short iterations, each iteration should deliver a piece of deploy-able product. BDD, TDD and ATDD are not development methodologies and can be ...


5

Use your testing skills to help the team define each story more concretely. This shifts your contribution from one of strictly detecting problems to one where also help to prevent them. As stories are being prepared for the next planning meeting, work with the product owner and developers to clarify the boundary of each feature. Use your well-developed ...


4

A simple test strategy can only guarantee a simple assessment of quality. According to James Bach: The purpose of a test strategy is to clarify the major tasks and challenges of the test project. You can (and probably should) expand "tasks and challenges" to mean "goals, activities, deliverables, constraints, risks, and dependencies." Given that, your ...


4

Even though an answer was already accepted I felt to offer another perspective: You should not run a scrum for the testers only. Effective scrum teams rely on their ability to self govern and self organize. So each team will handle things in their own way. If a tester has an issue, he/she should bring it to the scrum master and work it out in the team. ...


4

Well, firstly I hope you've been building up a decent test library as you've been going else there's a lot of work in re-building a regression test pack. Better still, I'd hope that while working with the Dev's you built up an automation framework (or at least 'bunches of scripts' that could be used in a future framework) per sprint. Not doing this ...


4

Congratulations! Here's a list I used last time I took a new position: http://www.allthingsquality.com/2010/04/qa-leaders-checklist.html It's pretty hard to know what you should expect, since every situation is different. Instead of anticipating, try to determine how you will go about learning what you have actually gotten into.


4

As ByteBuster indicated, user stories are a very high level description of a goal an actor or customer wants to achieve with the product, but doesn't detail exactly how that goal is going to be achieved. Developers often break user stories down into discrete development focused tasks that are necessary to achieve that goal. Developers should also be ...


4

The short version: If you're trying to measure productivity on an individual basis you're doing software development wrong. The longer version: Productivity, especially on an individual level, is something that can only apply to a situation where what's being produced is fundamentally similar. No two software projects are the same, and with Agile ...


4

Kate's answer is great, but I want to throw in my 2 cents for differentiating TDD/BDD/ATDD. TDD is writing tests first and letting those tests drive the development of your application. This introduces the idea of Red/Green/Refactor. The basic process is to: Write a failing test Make the test pass with application code Refactor the application code for ...


4

Agile teams are cross-functional teams. They estimate the work from design to delivery often on a story based level. This includes the testing work, since testing should be part of the definition of done. Story points are the relative size of the complexity of the task at hand. Read more about estimating with relative sizes in this blog. I as a tester part ...


4

My team struggles with a similar issue having multiple input streams, that are running on different iteration/sprint cycles into a common product. We tried testing in the dev int area for each team for a while and then marking items done at that point, but we quickly discovered that was too early in the process. We could verify that new functionality was ...


3

It sounds rather like you have the typical "agile-but..." implementation going. There are ways around it that avoid the overhead and issues that go along with GUI-based automation (which can be done without record/playback - the things I'm doing with Microsoft's CodedUI right now were probably never considered when they devised the tool). A few thoughts ...


3

The Assumption "Agile is iterative and many test-last tools are record and playback-style" is incorrect Tools are developed / adopted for managing repetitive tests, reusuable tests The feature developed might be in iterative phases, In such cases automation need to be developed for stable feature Automation has its own resource allocation, planning and ...


3

As the other answers have said, you will probably not test the user stories directly. The method I've used in the past works like this: Each user story will have one or more acceptance tests. These tests typically cover a high level test scenario (such as "Given that I am logged in as a customer, then clicking the link 'My Orders' takes me to a page ...



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