basic flows, alternate flows, use case include, generalization and extension. This makes applying use case specifications challenging for some people and user stories overtake in terms of popularity. If you have attempted user stories, I would suggest adding the constructs for achieving effective separation of concerns. This will help you organize and increase the longevity of your product documentation and your tests. (I will discuss this in a separate article.).
Let’s get back to putting yourselves in the shoes of real users. Do consider the context in which the users are using the system, what he is trying to achieve, what information does he has, what kind of skill level does he have.
I have seen developers who build the product, only use or test those parts they are responsible for. It is necessary to look at the product with a new pair of eyes. This is not just the problem with developers or testers. I have seen many projects where the people responsible for the product (I mean product planning, marketing, and the like) who have never even use the product before until a product demonstration (and even that is conducted by someone else). The consequence is that there is nobody in the product development team who has an overall understanding of the products features, constraints and assumptions. This is very dangerous.
Stay close to your real users. This can mean physically close to the real users, but it means more about really understanding how they truly use your product. Developers and testers who views the application day in and day out might be immune to the user's pain. So, understand the user’s pain. If they (users) just put them on the shelves, do understand why. If they feel something is cumbersome, understand why. If they feel some features are great, understand why too. Where possible, get members of your team to sit together with the real users and see how they use the product. If it were even possible, allow the developers to use the product in a real environment. I am not saying all developers in your organization need to do this, but at least some must.
Now, here is another catch. If you want to listen to your customers, then be prepared to act on their feedback. Your customers are usually not unreasonable, and you would recognize the difference between a real need and just a long shot.
7. It Is Not Easy, but You Have No Choice
So, what development approach are you using? Are you doing:
- extreme programming or excuse programming,
- agile development or fragile development
- lean development or lame development
Are you and your team treating quality as non-negotiable? What does it take to come to this conclusion? Does it require a product recall, or an embarrassed executive?
Achieving high quality is not easy. It involves, not just focusing on testing, but also a focus on requirements and architecture. It requires changes in individual habits and a team’s way of working. It takes hard work. It takes a fresh pair of eyes. It does not come for free. If you feel you are expending a lot of energy/effort without getting the desired effect, then perhaps you are venturing in the wrong direction. Perhaps you need a change of mindset. Again, achieving high quality is not easy. But you need to start somewhere and some time. There is no better time than now. The earlier you start the better.
I hope the mindsets articulated in this article helps guide you and your team to start thinking differently about the interconnection and interdependency between quality