[David Moss] Hi my name is David Moss and I'm a
Senior Consultant here at QA Consultants in Toronto. I would like to take the next few
minutes to chat a bit about the concept of 'Shift Left'. What is Shift Left? Shift Left is an approach
to bringing in testing earlier in the software development life-cycle. By
definition it means, it's an approach to bringing in the testing earlier in
the, in the process that is moving it to the left in the project timeline and
earlier. It's the first half of a maxim test often and test early. How can this be done before there's code? Obviously at
the beginning of a development project we don't have an application to test.
There's no software application. It's not there yet. At that point we perform a
Quality Assurance function by participating in requirements reviews
and design reviews in the hope of driving out defects earlier in the
process and by defects not just system defects but gaps in requirements, unclear
requirements, issues with the design. How are reviews valuable? I believe that everyone understands that
the earlier we fix a defect or clear up a misconception, the better the outcome
is for the whole project schedule therefore costs and the delivery of a
quality product. That way we need to be able to have the senior testers and
senior developers involved in requirements, reviews, the same way that
we have senior BAs and testers involved with the
development reviews and the BAs and developers join in and attend the test
case reviews. Everyone looks at a document and a development process
differently the BAs look at a document to say is this reflecting what the
client wants what the business needs, developer looks at it and says is this
something that I can code accurately and the tester looks at it to say can I test
this and also can I test it it works and can I break it. Let me give you an
example, I worked at a large banking client and they had a reasonably strong
software development life-cycle, so participating in the business
requirements documents reviews, I pointed out there were several cases of unclear
terminology words like 'would', 'should', 'could', 'may' and those can lead to you
know misinterpretation and misunderstanding. Also there were gaps
without line fit if this happens that happens, but what if this other scenario
happens, what if this other, this or that happens.
If it isn't documented we're not going to be sure what to do. The developers
also contributed by saying things like, "we cannot produce the error message the
way you have an outlined". So by having all three views of the same document and
reviewing it earlier and then revising the document at the end of the day we
all get on the same page and the same understanding as to what the client is
looking for and what we're going to be able to deliver. How else is Shift Left useful? The more we know about
the application the better we can do it. You know, better we can plan, we can
estimate efforts, testing is often estimated upfront through rules of thumb
or estimating tools but as we get involved, in the requirements and the
design we get a much better picture of how complicated or how simple the
application is, and we can do a better job of planning and staffing accordingly
and as well as early you know it's early on us we can get involved that means we
can get started with our test preparation activities.
Test case design, test data acquisition, getting the environment set up and all
that can be done in parallel with the development activities. Whats the best way clients can prepare? My message to clients is to please
engage the test team early. The earlier we get involved the more we can
collaborate with the BA, the developers, the project managers and everyone else
on the team to help facilitate and ensure that we have a quality delivery
on time and on budget.
