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
Fibonacci series is just one example for estimation efforts. Some teams also use series as below:
1, 2, 5, 8, 20, 40, 100, ....
1, 2, 4, 8, 16, 32, 64, ....
The idea is to use an exponential scale for estimating efforts.
The reason is the larger the story point, the more uncertainty there is around it and the less accurate the estimate will be.
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 ...
They reflect that the degree of uncertainty grows as you look further out and at bigger tasks with more dependencies.
For example, today you can be reasonably confident about how much effort is needed for a small task. You may be highly confident that you can finish it within a day, and, critically there is little uncertainty about the factors involved. So ...
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 ...
A good starting point is to define what quality means in your context. And then find out ways how to measure it. It seems you want to measure something without saying what that something is.
Having said that, we can hardly tell you that here, but perhaps we can give you some starting points that you might use in discussions with your teams and other people ...
For starters, Agile is not an actor.
One doesn't "work with Agile", "uses Agile", or things of this sort. Also, Agile doesn't act, it "doesn't do/make things".
Agile is a mindset described in the Agile Manifesto and other documents.
By reading your short description, it seems that before you used to work in a manner closer to the Agile Manifesto than now.
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 ...
It can work both ways, it depends on the situation
In some companies Agile is bunch of buzzwords used to cover the fact that waterfall and command and control are really what's going on.
In other companies Agile is used in an empowering model giving more voice and input to all folks including QA.
My experience is that the former approach is what exists in ...
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 ...
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 ...
Without being flippant, this sounds like you've got a serious communication problem in the team.
Given the limited timeframe, here's a few things to consider:
everyone in the team needs to know what a good bug report looks like
everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...
As testing is a never ending process we can never assume that 100 % test cases have been prepared, we can only minimize the risk of shipping the product to a client.
Complete testing is impossible for several reasons:
We can’t test all the inputs to the program.
We can’t test all the combinations of inputs to the program.
We can’t test all the paths ...
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.
It depends, and there are no industry standards.
Seriously. Any metric can be gamed (and will be, if you use it for assessment). I'm not aware of any standard approaches, not least because the teams are - or should be - evaluating themselves regularly and looking for ways to improve their own processes (if they aren't then they're probably using SCRUM-but......
Latent Bug : A latent bug is a bug which is present in the system from previous iterations or release (in your scenario Sprint 1). They are either low priority bugs, which either went undetected or were not reported.
Here is a good description : What is a latent bug?
Golden Bug : If a bug happens to appear, in every iteration or release, affecting the ...
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, ...
The TDD cycle is more a development cycle for a developer, to quote James Shore, The Art of Agile, Test-Driven Development chapter:
Programmers new to TDD are often surprised at how small each increment
can be. Although you might think that only beginners need to work in
small steps, my experience is the reverse: the more TDD experience you
have, the ...
I really like this question, it's something I've thought about a lot. Validation response codes and a JSON body is a good start, but like you said, there's a lot more that can be done.
I built an API testing tool Assertible (https://assertible.com), and have written a few blogs on approaching different ways to test/validate a REST API, these are some of the ...
I'm always on the lookout for grammar and spelling errors - purely because we're here to assure quality, and typo's aren't professional.
It's usually not the developer's fault because they just copy + paste it from a requirements document or something similar, and testers are more likely to catch it.
As a consumer - if a company can't spell properly, I won'...
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 ...
The short version: regardless of the development methodology, your role is to provide information about the overall quality of the application. You do that via testing anything that isn't included in the developer-maintained automation, and reviewing the developer-maintained automation.
The long version: This question and its answers is a good starting ...