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 ...
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.
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
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 ...
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 ...
This is very common.
There are basically 3 parts to the problem:
Track stats to know when the backlog is getting worse or improving, week to week
Figure out what things you need to change to stop making it worse week to week
Clean up the backlog you created, bit by bit
I'll focus on part 3 - the cleanup - but ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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, ...
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 ...
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 ...
It reads to me as though your organization is using the SM role in a somewhat different way than classic Scrum, so my suggestions could be way off-target here.
Classically, the SM role is to facilitate progress by finding ways to clear or work around any impediments that arise during a sprint, to lead meetings, to ensure that meetings stay on-topic and stay ...
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 ...
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.
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.
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 ...
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 ...
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, ...
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 ...
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 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?
Test first. Make ...
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 showing ...
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 ...
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 ...
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 ...
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 ...