Hot answers tagged

59

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


40

Some opinionated points from my experience, doing mostly development and operations with only a bit of QA and support, for the past few decades. Make of them as you will. I don't think it matters if bugs are picked up during formal QA, or by developers doing other work, or even customers or consultants. They should be treated, mostly, the same. My opinion is ...


33

No. Requirements should be originated from a single point. Your developers might misunderstand something so that you'll be testing not what your stakeholders require but what your developers implemented (effect of a broken phone). Asking your product owner will let you catch the gaps between what the business expects vs what your team actually implemented.


27

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


27

Get the whole team to work on the problem. Given the arrangement you've discussed clearly the team needs to look at options to resolve this. The problem itself seems fairly endemic in all of the organizations I have worked with. It seems inevitable given the setup unless proactive steps are taken to address it. A frequent issue is that there is no 'one ...


20

Maybe you do and maybe you don't. First determine what you want to accomplish, then decide on how you are going to do it. Blanket statements saying YES or NO are useless. It really depends on the project, people, company and expectations. My opinion is that if test cases help in actual testing, then yes, write them. If they are written 'just because', then ...


19

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


19

There is a third way, a middle of a road way, if you wish: don't polute the backlog with many low priority bugs, but group them in an epic or a story that might hold them. So, instead of having 20 low priority front end (for example) hot fixes that take 10 minutes coding each but you don't want to build a vesion for each of them, you can have a dedicated ...


14

Tl;DR: Yes, it should if you practice technical excellence. Sadly often it doesn't. The current most popular Agile framework Scrum mainly focuses on process quality and project communication. If you get yourself a project manager transitioning to Scrum Master you will be in trouble, because they have no clue about internal or structural quality and why this ...


14

A generic answer is: It's contextual; the team and stakeholders (which is who understand better the context) should work towards finding a good way - and periodically analysis its efficacy and improve on it. However, I see three major approaches. E.g.: 1 - The team defines strict rules for labels: High: The user cannot use some feature Medium: The user ...


13

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


13

From my experience - Faster feedback and more testing (in the form of automated tests ideally). If behaviour doesn't change but code is refactored often, then behaviour of system should be covered by automated checks. We have unit tests, integration tests and ui tests that are run after every commit. If requirements and behaviour changes often, then ...


13

I go with reject and move-on. The downside is that other folks and new folks will keep discovering the bug 'anew' and have to remember them in their head. Which sounds like a huge problem. In practice I have found that the fear is worse than the reality. Also consider that in many systems the number of bugs based on the combination of different devices, ...


13

You deal with them the same way as any other bug report. Review the bug and decide what (if anything) to do about it. If you decide to do nothing, tag it in the bug database with "won't fix" and add a description of a work-round, if available. That doesn't "pollute" your backlog. When you have decided not to fix them they are no longer in ...


10

There is no single "correct" answer here, but there are several things your team can do to deal with this situation. I'm going to assume that you have no problems with the estimation and sprint cycle aspect, and your main concern is that you don't want to be blocked when changes to the software you're testing break your existing tests. Leave a maintenance ...


9

The difference between Waterfall methodology and an iterative methodology (agile, Scrum, etc.) is that Waterfall requires each step of a defined process be performed to completion in a particular sequence. In an iterative methodology you complete small slices of the problem at a time by gathering just a few requirements and coding each one to completion, ...


9

Yes, in agile we do need test cases. Based on stories, we create test scenarios, and based on test scenarios, we create test cases. Because at the end of the sprint, we have to perform our test closure activities, where we want to show our test artifacts (test cases and test scenarios). So answer is yes, and it should start as soon as you get the stories.


9

Before answering this question, I would like to explain Why requirements are changing continuously in any Development Cycles: People change their minds for many reasons and do so on a regular basis. This happens because: They missed a requirement: A stakeholder will be working with an existing system and realize that it's missing a feature. They ...


8

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


8

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


8

There are a few questions to unpack in there. First, when to start testing in a 2-week sprint: as soon as possible. Many experienced Scrum teams focus on getting one or two backlog items to a testable state before moving on to others so that testers can get working on those. This creates a better flow of work through testing so that it doesn't all pile up ...


8

Great Communication Brings Great Results Being last in line, QAs keep facing this repetitively. QA should proactively communicate delays and respective risks to stakeholders. I’ve never seen any agile project where every sprint came in on time. Start with finding the reason what is causing the delay. There can be multiple reasons for the delay: Estimates ...


7

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


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


7

First, Agile projects, in general, has no defined phases like "Explore"or "Adapt". I suppose these terms come from some specific flavor of agile. In ideal Agile world, UAT will happen immediately after each small piece of functionality is developed: it will happen soon and often. In practice, this is often loosened into doing several testing sessions during ...


7

Personally, I ask the other team members if such and such a problem is something we even want to deal with. If we agree it's not, I don't bother opening a new bug because obviously no one cares and I don't like doing work that's considered useless. I think what's important is that the team, the customer, or whoever decides what quality is with a concrete ...


7

I suggested this in the comments but figure it works just as well as an answer: Keep the low priority bugs around, especially things that aren't hard to fix in principle. Use them as onboarding exercises for new people. They'll be just as good for learning codebases and team processes as anything else; delays from lack of experience won't disrupt anything ...


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

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


6

Agile: Understand, Agile is methodology which defines the ways and activities to be carried out for software development It does not eliminate the core step of development and testing process Surely it will add more productivity through less hurdle in traditional process and interlinkage of each step to other Due to interlinkage one will work and dependent ...


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