Category: White Paper
Quality Engineering – The Driver of Your Agile TransformationDevOps & Agile Scaled Agile
This white paper explains how the Scaled Agile CoE structure can drive the agile process.
Analyzing RequirementsQA Optimization
In this article, I have attempted to bring together ideas on inspecting and analyzing requirements based on reading techniques as procedural approaches encompassing common checklist methods to achieve better defect detection rates as early as possible in the development lifecycle.
Behavior-Driven DevelopmentScaled Agile
Behavior Driven Development is an Agile software development technique focused on improving a key factor in the successful development of any software product: Communication. It is a technique devised by Dan North as a response to the issues he encountered whilst teaching Test Driven Development. Eric Evans describes it this way in his book Domain Driven Design: "A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design... Across this linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand."
Considering Test Estimation and NegotiationQA Optimization
Test estimation is a forecast of the projected cost and duration of testing which is agreed upon between the testers and enterprise which requires testing. It is a means for discerning information which will need to be fed back in to the business. It is often said that testing is a Risk Mitigation exercise, but as the testing process itself cannot mitigate risk, it would be a truer statement to describe the testing function as a tool by which the business gleans information enough to mitigate risk. It’s likely that most of those reading this white paper will fall into the bracket of estimating in accordance with what should be done as a set of testing tasks. This is not incorrect; however, to only consider testing estimation against what one believes to be the correct list of testing tasks and depth of testing is an incorrect way of approaching test estimation.
Extending the Test Basis – Let’s look at the usersQA Optimization
When we discuss test analysis, we do so in reference to the test basis that collection of documents, standards, and attitudes that we use to guide our testing. Unfortunately, it seems that for some testers the test basis begins and ends with the requirements as captured by a business analyst or a requirements analyst. Many testers seem reluctant to push back on the requirements, to look beyond what is written down. This is understandable, as many project managers are even more reluctant to extend project scope and many developers are wary of what they see as tester-driven development; we are not all used to having our opinions listened to and respected.
Is PRINCE 2 Still Valuable in an Agile Environment?Scaled Agile
Over the years, many organizations have invested heavily in creating or deploying project management frameworks. PRINCE 2 is a widely-adopted project management methodology, which was developed by a UK government agency and is used extensively within the UK as the management standard for its public projects. The origins of PRINCE 2 began when the sequential “waterfall” method for delivering software projects was the dominant paradigm. However, regular revolution and increasing competition in the IT industry results in organizations seeking a more flexible management method; some of them already turned to Agile practices in an effort to improve their response to business changes. Well, do the traditional project management techniques like PRINCE 2 add value to an Agile environment? Is there any way we could combine these two methodologies to work together.
Managing International Distributed Test Teams in ScrumScaled Agile
This article provides examples of how we, as a test team, dealt with the problems and describes mistakes we made and lessons learned. Obviously, there are many more ways to deal with problems. Where relevant, we will share with you the different thoughts we had before making a decision.
Requirements vs. DesignQA Optimization
Some people say that requirements are about what you build, and design is about how you build it. This simplistic statement may sound right, but there are two potential problems with condensing the matter in this way. First, it makes it sound like there should be a sharp boundary between requirements and design, when that’s not really the case. In reality, the region between the two is actually very grey and foggy, not a crisp line at all. I prefer to say that requirements should concentrate on what and design should concentrate on how. It is important to explore possible designs that might satisfy certain requirements; a valuable method for assessing the clarity, correctness, completeness, and feasibility of these is through prototyping. Getting customer feedback on prototypes helps ensure you’re on the right track.
Requirements: Into the Mind of the AuthorQA Optimization
It seems well-accepted that it is cheaper to find defects earlier in the software development lifecycle than during dynamic testing or in live operation. I don’t need to include a graph of the cost escalation curve here; we’ve all seen it before. This rule can be applied to all walks of life – putting up a garden shed, building a house, buying a car, running a marathon – you name it and the adage “find problems early to save pain and aggravation later” always applies.
Results Based TestingProject-Based Testing QA Optimization
Results Based Testing (RBT) is a new software testing pricing model that sets forth the expected value to be delivered by the Testing Teams. Imagine your testing provider making a commitment to find 97% of the defects in the system. Can that be measured? What would that be worth? What would be the impact on the customer-provider relationships and accountability? How can you bind that commitment? This white paper will attempt to answer those questions.