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


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

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.


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


22

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


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


18

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


17

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


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

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


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

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


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

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


9

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


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

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


8

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


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

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


8

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


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

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


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

There are an awful lot of variables to consider here. But here are some points all the same. Manual Testing vs Automated Testing This point alone is probably worthy of a book and is one of the most frequent questions I see. E.g. I'm new to a project, what should I automate? Things to consider here are... Does take a long time to execute the manual test?...


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