Tag Info

Hot answers tagged

11

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


9

What value is "yesterday, today, blocking" to this team of testers? Presumably they have similar scrums where they present the same information to the functional team they are assigned to. So you may be asking them to repeat what they have just said, or will soon say. Perhaps you instead want to focus your meeting on "what is important for other testers ...


8

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


7

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 regressions? 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? Some ideas: Test first. Make ...


7

What you have described so far is something I'd call 'scrummerfall', but given how it often turns out, could be spelled scrummerFAIL instead. I see several issues that need to be addressed. @Aruna covered several in their answer, which gets high marks from me. To what they have said I would add the following. 1) the team doesn't understand what 'DONE' ...


7

In agile environment the distinction between a tester and a developer is blurred. Testers are not the solely responsible or even the primary owner of quality. Quality is a shared responsibility of the whole team. Individuals in an agile team may specialise in a particular role but will take on different roles depending on the context. Testers who are out of ...


6

Tracebility matrix is a tool. It doesn't have any inheritent value, but it might be easiest way of mapping certain kind of relations between tests and requirements. As with any other tool, if it seems to work well, use it. If something else fits better, use that. If the tool nearly fits your need, modify it to give what information you need. If testing is ...


6

In my opinion, there aren't any extra skills need to test a stable system. What tends to happen once the system is stable and not under continuous development is that the proportion of time spent on exploratory testing drops compared to the proportion of time spent on regression and checking. I'm assuming here that by "stable" you mean that the requirements ...


6

I wrote something recently that might help you out concerning using QA resources in an agile team. In essence, what you need to do is allow for your team to provide continuous feedback by making sure development is able to be continuously integrated and deployed to an environment where QA can run their test cases. You may have heard of a "Daily Build" ...


5

Use your testing skills to help the team define each story more concretely. This shifts your contribution from one of strictly detecting problems to one where also help to prevent them. As stories are being prepared for the next planning meeting, work with the product owner and developers to clarify the boundary of each feature. Use your well-developed ...


4

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


4

Well, firstly I hope you've been building up a decent test library as you've been going else there's a lot of work in re-building a regression test pack. Better still, I'd hope that while working with the Dev's you built up an automation framework (or at least 'bunches of scripts' that could be used in a future framework) per sprint. Not doing this ...


4

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


3

It sounds rather like you have the typical "agile-but..." implementation going. There are ways around it that avoid the overhead and issues that go along with GUI-based automation (which can be done without record/playback - the things I'm doing with Microsoft's CodedUI right now were probably never considered when they devised the tool). A few thoughts ...


3

The Assumption "Agile is iterative and many test-last tools are record and playback-style" is incorrect Tools are developed / adopted for managing repetitive tests, reusuable tests The feature developed might be in iterative phases, In such cases automation need to be developed for stable feature Automation has its own resource allocation, planning and ...


3

There are several factors that allows our testers to manually test effectively during a sprint cycle: Small, functionally testable stories Build/deployment automation: to me, this is the most important, builds need to be automated tested and deployed quickly if they are going to be manually tested quickly. Test automation: automating the checks supply fast ...


3

Congratulations! Here's a list I used last time I took a new position: http://www.allthingsquality.com/2010/04/qa-leaders-checklist.html It's pretty hard to know what you should expect, since every situation is different. Instead of anticipating, try to determine how you will go about learning what you have actually gotten into.


3

Even though an answer was already accepted I felt to offer another perspective: You should not run a scrum for the testers only. Effective scrum teams rely on their ability to self govern and self organize. So each team will handle things in their own way. If a tester has an issue, he/she should bring it to the scrum master and work it out in the team. ...


3

Given that a scrum meeting should be really quick, how much support will this actually give the testers ! Why are you calling it a scrum, can't it just be a meeting ? Also, if you are 'managing' the testers then it seems to more of a meeting than a self-organized scrum.... Not saying your idea is wrong, not sure that calling it a scrum is the best ...


3

I have never seen such a matrix and never heard of it before :-(. Your goal: Which requirements is almost never tested, and which is tested extremely often? can be achived by agile/technical means: Using Behavior driven development bdd as automated test for a userstory to verify that it is complete and still working. There are code coverage tools ...


3

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


2

In this software development environment, testing should progress with the development. As the features are being planned, you should be getting boundaries. As the features are being implemented, you should be making scenarios form the boundaries. As the features are finished, or at least working, you should be running the scenarios; manually or through ...


2

I wrote an article sometime for the Agile record magazine (Lessons learnt in agile testing) specifically highlighting some pain points and the learnings we had while transitioning to agile. here is the link. hope it helps http://agilerecord.com/agilerecord_04.pdf (page 73 – 76)


2

As Suchit said, it depends a lot on the nature of the update. I've seen a one-line code change trigger a full regression because that one line happened to be in one of the core calculation engines. My suggestion for any development process, whether agile or not, is to have multiple suites of automated regression tests running on at minimum a daily basis. ...


2

User Stories are the highest-level requirement artifacts in the software development lifecycle. Here are some examples of User Stories: As an application user attempting to save the document, I want to see a warning if the desired document name already exists; The warning should allow me to choose whether to overwrite an existing one; As an Web site ...


2

There is a very relevant whitepaper here that you should read. It raises some excellent points. Whilst I don't want to be negative, or scare you, your situation will be VERY challenging as you have to contend with the following: Learning your new role and your lack of testing experience. Communication with and governance of the offshore team. Working in ...


1

I write automation code with Robot Framework in an agile development environment. So long as you have an idea of the implementation of the code in test, you can write automation scripts before the code is deployed. This should be an exercise in logic and workflow. Once the code is live you can update your script with specific identifiers for each keyword. ...


1

It really depends on what the small update is. It might be a small change but it affects a lot of parts of the system e.g. Updating something in the db. The testing shouldn't be tied to whether it is a small update or a big one, however defined. It should be tied to how much you think is the effect of the given update. A small but critical update may ...


1

Having done 23 years of performance tests including trouble shooting, correction, and rerun I can agree with testerab on long reports full of nice graphs that remained unread (and even if scanned certainly not understood). Of course if you are a paid for third party, or even expendable employee, that report might be the only way you can justify your costs ...



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