Hot answers tagged

25

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


7

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


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


6

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


6

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


4

Point of testing units and components before whole system is to localize bugs BEFORE they damaged some unrelated part of the system, causing confusing red herring error. If you mock the surroundings of a component, you eliminated moving parts - and localized the bug. Of course you need to weight the effort to mock: because it is code, it will have bugs and ...


4

I'm going to answer the first two points because I think the other two should be put as separate questions instead. What are the types of testing that can be conducted on first build which was released in first sprint in agile development model? There is no specific check-list. It depends solely on the architecture and complexity of the project. Team ...


4

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


4

Agile teams are cross-functional teams. They estimate the work from design to delivery often on a story based level. This includes the testing work, since testing should be part of the definition of done. Story points are the relative size of the complexity of the task at hand. Read more about estimating with relative sizes in this blog. I as a tester part ...


4

Project Management Institute is one of the most well-known. More at https://www.pmi.org/certification/agile-management-acp.aspx Another leader is: https://www.scrumalliance.org/certifications which breaks out various roles including developer A personal note is that in my experience this certifications will make you entry-level and only a year or two in ...


3

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


3

Anybody can be the Scrum Master, just make sure the Scrum Master has no other conflict of interest roles as Product Owner, Manager or Stakeholder. Personally I think testers have the potential to be great Scrum Masters, because: Testers discover problems/defects, but often do not demand a certain solution. Its up-to the owners of the issue to find the ...


3

As Agile teams need to be cross-functional, its handy if the team members itself are also cross-functional in their Agile skills including testing. One thing you want to prevent is having a mini-waterfall within a sprint. This leads to all the testing to be pushed into the end of the sprint, which could in turn bring your sprint commitments in danger. ...


2

I don't have time to do all the documentation, test cases, strategy, test plan, etc. I almost always recommend producing the minimum necessary documentation. Call it lean documentation, minimum viable documentation, whatever. You want just enough that helps plan and guide the testing you need to do. Anything more starts to lose value very quickly. ...


2

Actually, we're doing this exact thing you mention. Testing in the same three weeks as development is nefarious for testing time and quality overall, as you seem to have experienced. So, we're testing for two or three weeks after the development sprint has finished. By delaying testing for a few weeks, you'll be working on a fully delivered sprint ...


2

You seem to be focused on the technical aspects of doing software QA. I would say your background is good for doing test automation and finding bugs that are results of technical obstacles. However, it takes a strong will to put up with the amount of animosity you may have to control. I find troubling is that no one is bringing up the intense social ...


2

You have a very good background to apply, depending of the company maybe you have to learn something more than you know but just like everything in this life, nobody's born knowing everything. As Nike says Just do it! Finally want to share a very interesting article about QA role in agile teams ...


2

I was given this webpage to read, by my QA Manager: tips for quality testing. It really tells you what testers need to do to be a good tester. A few pointers I have learnt from reading such material, is: Find quality bugs and not quantity of bugs Prepare your documents early, as in create your documents / test scripts early before you start actual testing ...


2

It really depends on how you write your test plans. In that specific case, you can at least do preparatory work, with structure, without details, like "create a customer, enter an invalid age, checke there is an error message, enter a valid age, check the creation works". If you happen to need more detail in your test plan(really depends on the shop), ...


2

The best advice I can give you is to ask the other team what information they need to be successful. I've been in the opposite position where I'm supposed to automate tests others have made. Aside from this being a bad practice, creating too detailed documents or creating the wrong details will only waste both of your teams time. Send over what you have ...


2

Yes, it is an "opinion" based question but I think that there is not a standard answer because in the Agile world the time is divided into sprints and each sprint contains one or more user stories. The point is that the US of a sprint sometimes are more focused on the back end of the product and sometimes are focused on the front end so the effort of testers ...


2

It does depend quite a lot on the user story, but there are some general guidelines, with more or less the following order of priority: Essential Tests Acceptance Tests - By definition, the user story can't be accepted if it doesn't pass acceptance testing. The exact form the acceptance tests take will depend on the user story: for back end focused user ...


2

I would like to propose that you consider what is needed to support an opinion that the quality of what is being delivered is "Good Enough". In as much as we try to develop systems in general with the end user in mind, asking this question helps you to design the type of data you need to collect. I have found that the generic answers that we would ...


1

In Agile QA I focus on the testing quadrants I focus on my developers doing a good job in Q1 I work to write good automated UI tests in selenium and capybara for Q2 Exploratory testing is essential and is represented in Q3 Performance and load in Q4 For exploratory testing (Q3) this is where I cover those 'hard to cover',. 'not worth automating', ...


1

The correct way for you to answer would be something like "I'm new to Agile, so I don't really know." If you have non-Agile experience, you could expand on your answer and talk about the number of test cycles on the projects you tested. And if you have read enough about Agile to feel confident that your reading applies to this particular context, then you ...


1

First, I want to echo milinpatel17 's answer. If they are not cooperating NOW, at the start of the process when people should be psyched about it (see http://www.1000advices.com/guru/project_mgmt_7phases.html ), how would they be a few month into the project? Specifically to your question: If you give them the scripts you now run manually, you will get an ...


1

This might help: http://www.allthingsquality.com/2010/04/what-do-qaers-and-testers-do.html Every company is different. But here are some of the things my QA Teams do, in no particular order. Review and respond to requirements Participate in design reviews Participate in architecture reviews Create and maintain Test Cases Execute Test Cases Exploratory ...


1

If you are trying to look for full coverage it seems theirs a gap between automated testing and then the manual type of exploratory testing (Which...maybe I'm wrong, but it feels almost like smoke testing but you don't really have a specific test "plan" for it). Okay, from this description, I think the problem may be that you are limiting your ...


1

ANY test CAN be automated, given enough resources (time and manpower) - but for many tests such effort does not make sense. If user interface or functionality is under constant churn, you are better off do just manual tests, because developing automated test (programs) takes more time, so may not be able to keep up with development (unless you have as many ...


1

I would suggest possibly assigning some "free play" time with a minimum number of participants, specific classes of player or levels of experience and with a number of objectives and/or story points from the core functionality and from the latest couple of sprints to try to achieve within the time period. This could be followed by a structured feedback ...



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