In the last episode Rob talked about the main challenges of testing, and not only for the acceptance tester but all the roles who are responsible for the quality of the product and that's actually everybody.
No Risk- No Test… what needs to be tested, when there is no business risk there is no reason to test, no reason to make unit tests by the developer, no reason to make regression tests and no reason to do acceptance testing. But when there is a risk every role has the goal of making that risk as small as possible. There is a joined effort in execution of tests to prove that the risk is minimized or solved. The development testers, system integration testers and acceptance testers together have to make a strategy on how to test.
Application Lifecycle Management
When talking about Application Lifecycle Management [ALM] terms like accountability, governance and compliance are used. All of them refer back to “working together”, how do we work together during the application lifecycle. ALM is not about tools, it’s about working together. Working together seamless and flexible while staying in control, being measurable and responsible. All the roles in the application lifecycle have a part in this collaboration effort. Tools can help but isn’t’ the core driver.
There are lots of examples of wrong interpreted business requirements, miss communication between development en test [Rob describes a very real example], applications which won’t run in production, operations who don’t understand the applications. All of them resulting in more work, more faults, more costs or even only costs and no application because the project was unplugged. Most of these projects faults, these extra costs are a slip in communication.
Having a strategy how people have to collaborate within the lifecycle is one important piece of Application Lifecycle Management. Most organizational parts have already some kind of process / methodology in place. Having an approach how to share information and share ideas from their own role point of view through the other roles is a key success factor for lowering the costs and raise the business value of IT investments.
Tools can help with this goal. Having gear in place which supports and stimulates collaboration is a driver for a successful Application Lifecycle Management. But without a plan, how people should collaborate and communicate, tools are useless.
In the early ages, the waterfall ages, nobody talked about Application Lifecycle Management. Software development was still in his youth, experimenting with proven processes from the industrial age. The era where Taylor educated managers controlled the workforce. Business people writing down what they want [not knowing what they need] and throwing their needs over the wall to the workforce.
There was no communication between the guy who needed the software and the guy who implemented the software, a massive brick wall separated them. All the roles in the Application Lifecycle did their job between walls. People where used to this formal way of working, not arguing, not discussing about the solution, be doing their job as optimal as possible.
It doesn’t need any explanation that this Taylor way of work didn’t work for software development. Some software projects succeeded but many more failed to reach the goal. The main reason why all those projects fail: there was no sharing of ideas, ideas how to achieve business value. Everybody was working in his own domain with their own specific tools, as shown in the picture below, everybody on his own island with his own specific tools, practices and methodologies.
Software development is way different than producing products [Taylor’s theory is about optimizing the work force, something Ford did very well]. Software development needs a shared effort, a shared effort by all the roles in the lifecycle. From the people who have the business ideas and knowledge to the people who have to implement, test and maintain the final solution. Everybody in the lifecycle needs to collaborate with each other. Everybody needs to add their specific knowledge to the solution, that's not the same as adding parts to a car.
It’s interesting to notice that when there are no guidelines / structure in place, and nothing is done to stimulate collaboration. People and groups of same interest starting building their own walls, building their own kingdoms, protecting their environment. So, if we want to change this cubicle way of working, management buy-in needs to be in place, groups aren’t going to collaborate automatically.
Nowadays, everybody understands that communication is king. Roles in the lifecycle need to communicate, need to listen to each other and share ideas about their view on the solution. The Agile methodology gives guidelines and structure , with valuable principles like:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- The best architectures, requirements, and designs emerge from self-organizing teams.
Tooling starts to support these principles [and the other 17] adopting a new way of communicative work around the Application Lifecycle. In 2005 Visual Studio Team System starts to support these principles. The integrated development environment got supported by Team Foundation Server with workitems, process templates and reports, helping to get roles in the lifecycle to communicate in a more efficient manner. Integrated in one tool people can share their workload and workprocesses, giving the project leader and for sure the other roles the ability to have more control over the process of software development, by knowing what the other one is doing.
Telling each other what you are doing is challenging. It’s challenging within a group of people with the same interest, it’s even more challenging between groups of different interests. It’s a culture challenge to get it working. Everybody knows it’s valuable, but most don’t want to give someone else a look in his kitchen. It’s valuable because it give transparency, agreements are known, even if someone is working according to this agreement and people can more easily get in sync. Everybody gets the focus on the business target.
[A dependency diagram of RUP’s process components.]
That people need to work together on a process and workitem level isn’t that strange when we look at the above image. This is a visualization of the degree of coupling between different process elements in the RUP methodology. …A Rational Unified Process (RUP) Plug-in To Support Requirements Quality Assurance [pdf]
The figure shows, that there is a very high coupling for approximately one third of all process components. 21 process components have a coupling less than 25%, 8 process components have a coupling of more than 25% and 3 process components more than 40%.
It’s interesting to notice that the adoption of workitems and processtemplates, although they are valuable, within companies fail. The main reason is the culture of the organization and management which doesn’t fully supports communication. This cultural aspect of communication between different roles, different social groups, should have a main focus while implementing Visual Studio Team System, otherwise success isn’t guaranteed.
This is also recognized by agile gurus like Scott Ambler who is writing in his blog:
Your existing culture and organization can really hinder your ability to scale agile approaches,
In his book “Agile Database techniques” he talks about The Cultural Impedance Mismatch between Data Professionals and Application Developers, discussing the cultural problems according to the communication between database people and code ‘object oriented’ people.
Overcoming the cultural impedance mismatch is much more difficult than overcoming the technical impedance mismatch. [The Cultural Impedance Mismatch Between Data Professionals and Application Developers]
The collaboration starts
While VSTS 2005 and 2008 support communication at a workitem level, the 2010 version of Visual Studio is going to support collaboration at artifact level. Different roles in the lifecycle work together on artifacts. Each of them adds their knowledge, vision and ideas to the solution from their view point. These artifacts are accessible by every role in every phase of the project, adding value throughout the lifecycle.
People are enabled to collaborate, making applications together, and not only by telling what they are doing but most important by working seamless together on the application.
While working together with all the roles and having these ‘ALM’ artifacts accessible for every role, collaboration in the application lifecycle will rise to the next level. People with different social and cultural characters start discussing solutions, trigger each other to improve and being innovative with their view on the application and all within the constraints of their role.
VSTS 2010 enables people to collaborate on artifacts in the Application Lifecycle. While the 2005 and 2008 versions mainly focus on communicating about work [workitems , processes and reports]. With VSTS 2010 the focus moves on to collaboration on artifacts. The main reason this is going to be possible is the investment by Microsoft in the Architecture Edition and Test Edition, widening the scope from developer to more roles in the lifecycle.
Not only development artifacts like source code can be saved to a repository but also test artifacts like test cases and test results. they can also be saved to the same repository, creating the possibility to work together on these artifacts from the same repository.
Testing in the Lifecycle
To figure out how this all works with testing we need a deep dive in the different test roles, what they do, what way they work together with the other team members and what kind of capabilities they need from the tools they use. Rob already talked about the different test roles “developers who are testing, specialist testers during system testing or generalist testers during the final acceptance test”. How do all these test roles work together with for example the business to capture risks of the system?
In the next episodes we will discuss these different test practices what they patterns are and the capabilities the need from tools.