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
it makes the higher ups really happy to see results, and the winning
QA members get lunch.
Since you have set the system up so that there are "winners" and "losers" based on bug count, it's not much of a surprise that testers are trying to find a way to win. You are focusing on the wrong goal. You have basically told them that the goal is not improved ...
I would suggest that you go back and do those unit tests when you are required to refactor that area of legacy code. The approach for do this is described in this question.
When you are working with legacy code with no unit tests, its the same principle and techniques to add them regardless if you are doing TDD or not.
I highly recommend Working ...
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 ...
Ideally, the DoD for each user story should mean all tests for that user story are passing, and all automation is completed, running as part of the overall automation (as opposed to on one person's machine), and running with no errors.
Real world usually means compromises, since there's rarely enough time or resource to cover all the potential implications ...
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 ...
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 ...
Bug hunts should be fun and productive for the entire team, and a little professional competition can go a long way to improve moral of the entire team and help them grow.
This is a rare case that I slightly disagree with Joe. I also like the idea of a point system.
But would expand to include:
Everyone is involved in the bug hunt; not just testers. ...
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 ...
After reading your account, I have a few questions. They might sound harsh at first, but your account sounds to me like you're in an organization that has to consider some harsh realities.
1) Is it the complexity that's a problem here, or is it your reaction to the complexity? (Along with your organization's apparent lack of reaction to the complexity?)
Craig, I have been working in a similar environment for 6 years. DEVs and QA are on the same box, using the same code which is constantly in flux. DEVs check out a program(s), update & re-compile while I am in the middle of testing. At first, I was very frustrated as you are. When possible I do create my own "sandbox" (db only, not actual program) but ...
I've been the first tester on a team before and seen how they've tested their software before (usually doing a very good job of it as well). For as small as you are, I think that you're on the right track for the most part.
Creating automated tests as you go is great. You may find some benefit to some TDD approaches which ask you to create the tests ...
Welcome to SQA, FJFG. As Bruce McLeod once wrote, "There are no 'best practices', there are only good practices in context." A good practice for you will depend upon your context. I will suggest some contextual considerations. You may be aware of others.
Your primary job, or at least your initial job, is to own and convey business requirements. Those ...
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 ...
Answering your second question first: yes, you absolutely need test case design standards. They don't have to be monsters. As with all things agile, they need to be enough.
For your first question there's no "right" answer, but I can give a few guidelines. Your standards should be based around a kind of test case triage: first priority is being able to set ...
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......
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
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.
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 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 ...
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 ...
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 ...
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 ...