The Agile Testing Manifesto. Part 2
The Agile Testing Manifesto. Part 2
In this article we will continue our analysis of the Testing Manifesto written by Samantha Laing and Karen Greaves with the next principle:
17 Jul 2017
5213
Other articles
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Last Modified technique?
How to implement Slowly Changing Dimensions(SCD) Type 2 in Spark?
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Append technique?
Why MongoDB don't fetch all the matching documents for the query fired
How to solve the issue of full disk utilization in HDFS Namenode
Can We Use HDFS as Back-up Storage?
How to do Indexing in MongoDB with Elastic Search? Part 1
How to do Indexing in MongoDB with Elastic Search? Part 2
How to store data on browser using NoSQL IndexedDB?
How to Apply MBTI in HR: Motivation for every day. Groups of People & their Motivations
In this article we will continue our analysis of the Testing Manifesto written by Samantha Laing and Karen Greaves with the next principle:
We value building the best system over breaking the system.
I’m reminded of the joke below when I read the principle above:
A tester comes to a job interview.
When he enters the room, the interviewers point to a chair and say, “Sit down, please.”
The tester sits down on the chair, and it breaks under him.
“You are hired!”
The anecdote might be funny, but it is far from reality. Although there is a common belief that testers are exclusively engaged in destruction, it is only half true.
Positive testing is no less (or even more) important than negative testing. Sometimes, testers, especially beginners, are too enthusiastic about complex negative tests: What if you enter 15 fraction digits? What if you enter a string of 5000 symbols? What if you send a message consisting of all special characters, like that: "~!@#$%^&*()_+{}:;'`"?><[]"? All that is very fascinating, but one should remember the main goal – to create a product that has a certain value and performs its functions as intended. That is why simple positive tests such as reproducing a users’ actual actions are of top priority.
We value team responsibility for quality over the tester's responsibility.
Generally speaking, the entire team’s responsibility for quality is a fundamental principle of Agile.
But how many team members feel that shared responsibility? When some problems arise, what do you and other members of your team do? Try to prove that someone else is to blame, or you think, “What could I have done to prevent or correct it?”
If there is a problem with quality, do they blame testers alone or do all team members share the responsibility?
Victoria Slinyavchuk
Consultant on Software Testing
We value building the best system over breaking the system.
I’m reminded of the joke below when I read the principle above:
A tester comes to a job interview.
When he enters the room, the interviewers point to a chair and say, “Sit down, please.”
The tester sits down on the chair, and it breaks under him.
“You are hired!”
The anecdote might be funny, but it is far from reality. Although there is a common belief that testers are exclusively engaged in destruction, it is only half true.
Positive testing is no less (or even more) important than negative testing. Sometimes, testers, especially beginners, are too enthusiastic about complex negative tests: What if you enter 15 fraction digits? What if you enter a string of 5000 symbols? What if you send a message consisting of all special characters, like that: "~!@#$%^&*()_+{}:;'`"?><[]"? All that is very fascinating, but one should remember the main goal – to create a product that has a certain value and performs its functions as intended. That is why simple positive tests such as reproducing a users’ actual actions are of top priority.
We value team responsibility for quality over the tester's responsibility.
Generally speaking, the entire team’s responsibility for quality is a fundamental principle of Agile.
But how many team members feel that shared responsibility? When some problems arise, what do you and other members of your team do? Try to prove that someone else is to blame, or you think, “What could I have done to prevent or correct it?”
If there is a problem with quality, do they blame testers alone or do all team members share the responsibility?
Victoria Slinyavchuk
Consultant on Software Testing