Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
What qualities should a good Agile tester have?
Network:6864



A good Agile tester should have?
Sort By:
Page: 1 2 next>
Network:13892



They should probably know the different techniques such as TDD (Test Driven Development), ATDD (Acceptance Test Driven Development), BDD (Behavior Driven Development), pair programming, refactoring etc. They should also be cross-functional, so not just a "tester" but some kind of development expert in one or more disciplines/languages, be collaborative, transparent, and a team player.
...
1 reply by Kevin Drake
May 29, 2018 7:03 PM
Kevin Drake
...
how about communication? how far it is important here
Network:1873



Kevin, I side with Sante all software and development methodology based on communication between the business customers, the developers, and the testers. ATDD ...etc good points also he has to know the differences for example;-

TDD is rather a paradigm than a process. It describes the cycle of writing a test first, and application code afterwards – followed by an optional refactoring. But it doesn’t make any statements about: Where do I begin to develop? What exactly should I test? How should tests be structured and named? .When your development is Behavior-Driven, you always start with the piece of functionality that’s most important to your user.

TDD and BDD have language differences, BDD tests are written in an English-like language.

BDD focuses on the behavioral aspect of the system unlike TDD that focuses on the implementation aspect of the system.

ATDD focuses on capturing requirements in acceptance tests and uses them to drive the development. (Does the system do what it is required to do?)

BDD is customer-focused while ATDD leans towards the developer-focused side of things like [Unit]TDD does. This allows much easier collaboration with non-techie stakeholders, than TDD
TDD tools and techniques are usually much more techie in nature, requiring that you become familiar with the detailed object model (or in fact create the object model in the process, if doing true test-first canonical TDD). The typical non-programming executive stakeholder would be utterly lost trying to follow along with TDD.

BDD gives a clearer understanding as to what the system should do from the perspective of the developer and the customer.

TDD allows a good and robust design, still, your tests can be very far away of the users requirements. BDD is a way to ensure consistency between requirements and the developer tests.
...
1 reply by Kevin Drake
May 29, 2018 7:04 PM
Kevin Drake
...
Very informative mo3lem
Network:6864



May 29, 2018 5:57 PM
Replying to Sante Vergini
...
They should probably know the different techniques such as TDD (Test Driven Development), ATDD (Acceptance Test Driven Development), BDD (Behavior Driven Development), pair programming, refactoring etc. They should also be cross-functional, so not just a "tester" but some kind of development expert in one or more disciplines/languages, be collaborative, transparent, and a team player.
how about communication? how far it is important here
...
1 reply by Sante Vergini
May 29, 2018 9:22 PM
Sante Vergini
...
True, I guess I throw that in the Collaboration bag.
Network:6864



May 29, 2018 6:42 PM
Replying to Riyadh Salih
...
Kevin, I side with Sante all software and development methodology based on communication between the business customers, the developers, and the testers. ATDD ...etc good points also he has to know the differences for example;-

TDD is rather a paradigm than a process. It describes the cycle of writing a test first, and application code afterwards – followed by an optional refactoring. But it doesn’t make any statements about: Where do I begin to develop? What exactly should I test? How should tests be structured and named? .When your development is Behavior-Driven, you always start with the piece of functionality that’s most important to your user.

TDD and BDD have language differences, BDD tests are written in an English-like language.

BDD focuses on the behavioral aspect of the system unlike TDD that focuses on the implementation aspect of the system.

ATDD focuses on capturing requirements in acceptance tests and uses them to drive the development. (Does the system do what it is required to do?)

BDD is customer-focused while ATDD leans towards the developer-focused side of things like [Unit]TDD does. This allows much easier collaboration with non-techie stakeholders, than TDD
TDD tools and techniques are usually much more techie in nature, requiring that you become familiar with the detailed object model (or in fact create the object model in the process, if doing true test-first canonical TDD). The typical non-programming executive stakeholder would be utterly lost trying to follow along with TDD.

BDD gives a clearer understanding as to what the system should do from the perspective of the developer and the customer.

TDD allows a good and robust design, still, your tests can be very far away of the users requirements. BDD is a way to ensure consistency between requirements and the developer tests.
Very informative mo3lem
Network:13892



May 29, 2018 7:03 PM
Replying to Kevin Drake
...
how about communication? how far it is important here
True, I guess I throw that in the Collaboration bag.
...
1 reply by Kevin Drake
May 29, 2018 9:50 PM
Kevin Drake
...
Do you remember my 5 C?
Network:6864



May 29, 2018 9:22 PM
Replying to Sante Vergini
...
True, I guess I throw that in the Collaboration bag.
Do you remember my 5 C?
...
1 reply by Sante Vergini
May 29, 2018 9:54 PM
Sante Vergini
...
No, but I remember your 6 C's ;-)
Network:13892



May 29, 2018 9:50 PM
Replying to Kevin Drake
...
Do you remember my 5 C?
No, but I remember your 6 C's ;-)
...
1 reply by Riyadh Salih
May 29, 2018 11:12 PM
Riyadh Salih
...
LOL now we're talking politics :)
Network:1873



May 29, 2018 9:54 PM
Replying to Sante Vergini
...
No, but I remember your 6 C's ;-)
LOL now we're talking politics :)
...
1 reply by Kevin Drake
May 30, 2018 7:21 AM
Kevin Drake
...
I have many 6Cs and 5Cs
Network:1056



Kevin -

Aside from the technical knowledge of QA, a good tester should also embrace an agile mindset by leaning out his/her processes. A good example of this is formally documenting defects - if a defect will fall outside of the current sprint or iteration, it might add value to document it and add it to the backlog. On the other hand, if the defect can be resolved and re-tested within the sprint through verbal communication with the associated developer, why incur the additional overhead in documenting it?

We'd also want testers, like all other team members, to move from being I-skilled to being T-skilled. That implies not only some versatility but also willingness to take on other activities if it benefits the team.

Kiron
...
1 reply by Kevin Drake
May 30, 2018 7:23 AM
Kevin Drake
...
Thank you so much Kiron, your inputs is always like the icing on the cake
Network:6864



May 29, 2018 11:12 PM
Replying to Riyadh Salih
...
LOL now we're talking politics :)
I have many 6Cs and 5Cs
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"If you can dream it, you can do it."

- Walt Disney

ADVERTISEMENT

Sponsors