How to get developers to willingly spend roughly half their time testing, and get the customer to see the economic benefit of this!
Cresta was an innovative company of testers. Their core business was testing and test consulting, not software development, although many of Cresta’s consultants were technical test automation specialists and some were ex-developers. The decision makers in the company were well aware of the need to develop tools to support the business and to improve the quality of project delivery. Rather than outsource this work, it made sense to do it internally, as it made use of thetechnical skills in the company and provided an excellent internal “laboratory” for research and innovation in software quality techniques. In 2004 they initiated a project to build a quality metrics dashboard, which would be called TestStrategist.
Developers and Customer
I was to be the lead software designer, but I was also doing programming, so it was important to have a customer (in the XP sense)from the business, someone who was ultimately going to be responsible for helping teams use the product and to sell it to clients. This was to be Edgar, a director and founding member of Cresta. “Pure” XP recommends a full-time customer in the team, but because the system we were building was based on an existing process that I had designed, a lot of the business knowledge was already in the team, and we relied on our customer mostly to take decisions regarding priority, so we could live with the fact that Edgar was not full-time on the team.
We also needed a good technical guy who could handle our hardware and network issues, as well as cut code–Scott was someone I knew and trusted and, although he was new to the agile way, I felt confident he would pick it up. As well as being a fine developer, he was a naturally organized team member who did the important job of setting up our team collaboration site and tooling to enable remote working.
For our main development resource we took on Monique, an external developer whose coding skill was known to us from previous dealings. When we interviewed Monique prior to joining the project we described the process we were intending to use and mentioned XP practices such as close customer collaboration, test-driven development, collective code ownership, and pair programming. She was clearly skeptical and showed classic developer defensiveness, especially at the idea of making “her” code so open to the scrutiny of others. She went home and told her husband of the extremely strange development practices that had been suggested to her, adding that we acted like we were asking her to join some sort of cult. Fortunately for us, she needed the work, and she agreed to join the team.
Initially, it was just the three of us, all developers, as full-time members of the team. We did not assign any full-time testers since, as a testing company, we knew there would be an ample supply of those as we needed them. The strategy was to rotate test consultants through the team on a “tour of duty” to give them experience of testing in an agile environment and avoid losing a “billable” resource for the whole duration of the project. Before we could do that we needed to bed down our own process and that meant taking responsibility for all testing ourselves. This, after all, was not in any way inconsistent with accepted XP theory, which says that developers and customer are jointly responsible for testing. (The reality of most agile projects of nontrivial size is that dedicated testers add great value, since neither the developers nor the customer have sufficient bandwidth or experience to include all testing).
Good testing intentions are not enough, and our challenge was to ensure we could “drink our own champagne” and show that we were a quality-oriented development team, as dedicated to testing as we were to development. We were well aware of the risk to the company’s reputation of releasing a product that was not of the highest standard of quality. We also had to get to grips withhe new concept of test-driven development(TDD). This is a challenge for developers who might not think that testing–especially at the levels required by TDD– s a productive use of their time. It is also a challenge for management, who may take the naive view that development time on all tasks is going to double.
We were all climbing a new hill and starting from the bottom. What we had on our side is that we worked well as a team:there was mutual respect from the outset and an eagerness to learn from each other’s experience.
Agile Testing Related Interview Questions
|ETL Testing Interview Questions||Manual Testing Interview Questions|
|Selenium Interview Questions||Database Testing Interview Questions|
|Automation Testing Interview Questions||Software testing Interview Questions|
|Performance Testing Interview Questions||Embedded Testing Interview Questions|
|A/B Testing Interview Questions||Hadoop Testing Interview Questions|
Agile Testing Tutorial
Old-school Development And Testing
Agile Development And Testing
From Waterfall To Evolutionary Development And Test
How To Test A System That Is Never Finished
Implementing An Agile Testing Approach
Agile Testing In A Remote Or Virtual Desktop Environment
Testing A Derivatives Trading System In An Uncooperative Environment
A Mixed Approach To System Development And Testing: Parallel Agile And Waterfall Approach Streams Within A Single Project
Agile Migration And Testing Of A Large-scale Financial System
Agile Testing With Mock Objects: A Cast-based Approach
Agile Testing – Learning From Your Own Mistakes
Agile: The Emperor’s New Test Plan?
The Power Of Continuous Integration Builds And Agile Deve- Lopment
The Payoffs And Perils Of Offshored Agile Projects
The Basic Rules Of Quality And Management Still Apply To Agile
Test-infecting A Development Team
Agile Success Through Test Automation: An Extreme Approach
Talking, Saying, And Listening: Communication In Agile Teams
Very-small-scale Agile Development And Testing Of A Wiki
Agile Special Tactics: Soa Projects
The Agile Test-driven Methodology Experiment
When Is A Scrum Not A Scrum?
Analysis Of The Case Studies
My Agile Process
The Roll-out And Adoption Of My Agile Process
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.