Agile Tester vs Traditional Tester...........?

Question

What is the Difference in Role of a Traditional Manual Tester, who works in a waterfall based Project and that of an Agile tester, who works in an Agile based Project?

My project has started to follow Agile practices , but i don't know, that should i as a QA/Tester change my working style or approach? What should i do differently now?

Should i change the way i design test case, execute them or find bugs? should i do more exploratory testing or use new techniques? im confused!

Kindly help. Thanks!

Answer 1

I'd suggest you start by taking a look at some of the related questions and their answers, particularly this one and this one.

Also, if you don't have Crispin and Gregory's Agile Testing, get it.

Some things that I've found helpful include:

• Test plans will still happen - but they tend to be much more lightweight and built as you test. Some tools support this much better than others.
• Test cases also get lighter: if you've been creating test cases at a detailed "click this link, enter that text, click this button" level, you can (thankfully!) stop doing that and look more towards a lighter style.
• Generally speaking, test cases come from the user stories and acceptance tests: as an example, an acceptance test might be "As a logged in user, I expect to see a list of all my orders and their current status when I navigate to the order management page". This could produce test cases that look a bit like this:
  • If the user is logged in, there is a link to the order management page on the main page.
  • If the user is not logged in, there is no link to the order management page.
  • The order management page lists all orders for the logged in user, sorted by date from the most recent to the oldest, and shows the status of each order.
• If your team is creating unit tests, you should be familiar with what they are testing because this simplifies your testing: good unit tests will cover business logic and allow your manual testing to focus on end-to-end scenarios
• Test the happy path/steel thread first. This is the minimum necessary functionality to satisfy the user story/acceptance tests/use case.
• Exploratory testing sessions should be documented and time-boxed ("Spend an hour exploring the behavior of the order management page").
• Often it's easier not to report issues in a formal sense, especially if your team isn't running a mini-waterfall inside an iteration - my method was to check with the developer when I found something odd, and if they were already working on it or they could have a fix to me within a day, that was all that happened. I'd report something to go into the backlog and be prioritized only if I couldn't get the fix within a day - which cut down the amount of time I spent creating bug reports by a significant margin.

These are all things that I found myself doing during agile transitions, and it's not a complete list. The key thing is that the actual testing doesn't change: what changes is how it's documented, when in the process it happens, and - hopefully - how much of it gets automated (automated tests that become regression tests save a massive amount of work in the long run, if done well).

Answer 2

Agile testing generally means the practice of testing software within the context of an agile workflow.

When testing in an Agile way, there are few, if any, rigid adherence's to requirements documents and checklists. The goal, instead, is to simply do whatever is necessary at any moment to satisfy a customer’s requests, replacing documentation with in-person meetings and replacing siloed functions with unified, self-organizing project teams.

In an Agile company culture, everyone is expected to work closely together, no matter his or her role, to achieve a single goal: a high-quality software product that fulfills all of the essential specifications a client or designer requires with each iteration. Software developers, testers, and quality-assurance personnel wear each others hats from time to time, and while there may be a select group of people running most of the tests, the notion of a separate testing team disappears entirely for many product teams, and disappears within the core development cycle for those organizations who are required by external agencies (or even by law) to have formal and/or external release candidate testing. Even in these cases, this separate release candidate “testing” isn’t testing for the purpose of finding problems or improving the product, it’s an exercise in verification, regulatory compliance, and/or audit trail completion.

Answer 3

To me an Agile Tester is someone who does not work in a phase. The goal of the Agile framework is cohesion among the team. Everyone is involved in communication and tackle problems as they arise.

Example the QA analyst finds a bug, notifies a dev member of the issue, if the bug is not verified as previously existing they work together to implement a solution. The process is much quicker, hands on, and direct. It takes away the need for formal bug reports that can take up more time. It also doesn't push the resolution toward the end of the testing cycle allowing the detection of other bugs to be found much earlier in the process and saves the development team time from possible refactoring and saves the company money. The later in the development cycle a bug is detected the more money essentially it will cost the company in time and labor.

In a waterfall environment typically there is a testing phase that happens after development is done and is pushed towards the later stage of development. This of course does not mean all companies should immediately switch to Agile as some teams/projects work better in that type of environment but is just some of the pros/cons between the two.

Answer 4

I know that is a really old thread but just in case somebody comes here from a recent search maybe it's useful these slides about Agile Testing http://es.slideshare.net/abagmar/what-is-agile-testing-how-does-automation-help