What will happen if we start testing only after development?

Question

It has become increasingly common for groups to want to start testing as soon as possible because the cost of fixing a potential bugs in design level is much cheaper than fixing a bug later.

But, beside the "Cost of fixing it", what are other disadvantages of testing after development?

Answer 1

I find, in my work, that waiting until code is deployed can make it difficult to get the coders attention back onto the feature / issue I am testing.

They have checked in code & moved on to the next task/story/bug they have on their to-do list. So if I find an issue in something they worked on several days ago it is challenging to get them to shift focus back to it.

And I've been told by devs I work with that context shifting back to something they thought was finished is challenging. It can be hard to get back into that mindset and then it slows down their work on the current task they had started.

So from a workflow perspective, keeping the work together lets the team work more efficiently & avoid unnecessary context shifting.

Answer 2

It is better to test early ('shift left') because it is cheaper to do so and it also:

• Enables greater speed of change which is increasingly critical for many companies
• Enables faster fixes because the context is more recent for the programmer
• Enables higher quality because the context is more recent for the programmer
• Helps brings a testing mindset to developers which improves quality
• Encourages automation - the closer it is to programmers the more they will want to automate
• Encourages conversations up front about design and testing*

Perhaps most critically of all you will *miss out on the benefits of BDD (Behavior Driven Development) and TDD (Test Driven Development).
The advantage of these techniques is NOT just that you have tests that cover your code. The true advantage is that

Tests drive the development of easily testable, high quality application code

A mature developer will have learned over time that when you write the tests first it really affects the application code you then write and you actually end up with application code that is different - for one thing, it's written to be tested and addresses the most common problem with application code - "it's not written to be tested !"

* I've seen weeks of work saved by a 10 minute 'up-front' conversation about testing

Answer 3

Below is a basic outline of SDLC stages for the water fall model:

Even if we use agile , devops or what ever, the basic stages remains the same

Problem with above waterfall approach:

Waiting for system implementation for testing to start eventually wastes the efforts of prior stages.

For instance,

assume a "travel blog app" development where one of the requirement was to be able to upload photos to the app. The developers made the implementation and moved for usability testing. But, in usability testing it was found that user wants to add multiple images in one go , but the app supports only single upload. Now the development should be refactored to include multiple upload and resize the frame accordingly.

This results in waste of time, money , and time to market.

On the other hand, if a experienced usability tester was involved during requirement gathering, UX design , and in each stage. Then multiple image upload use case would have been in initial requirement list only.

This results in more focused,fast and quality product

Best practice:

Have QA involved in all stages and levels like Requirement gathering, UX design ,unit test,integration test etc.

This allows to find defects in design or requirement itself, and there by avoids developing products with designs that had weaknesses in the first place and wasting time refactoring it

Answer 4

If you continuously test, you always have a fragment of the application that can be potentially released. It may not have the features you wanted, but it can still be a useful and successful application. You can prioritise the features that are important, and drop features that turn out not to be all that great (or cheap).

If you test at the end, you're already committed. You've spent a year writing a year's worth of features, and now you have to test a year's worth of features. Until you test and fix all the issues, you can't release anything. Even if it would be advantageous to cut half of the features, you can't really afford to do that during the testing phase, since any such cut introduces large changes of breaking the things that do work.

This usually means that continous testing gives you:

• Shorter time to market
• Better ability to respond to changes in the market (less inertia)
• Higher quality product, since you avoid the rush to get things tested and fixed at the very end, likely not quite accounted for by the management

There's also other benefits, some of which you mentioned already:

• The earlier you fix a problem, the cheaper it's likely going to be. Fixing a thing in design is faster than fixing it in dev, which is faster than fixing it a the end of the development cycle. You'll need to change more code, make more compromises, and you probably don't remember all that well how and why you did things, and how to properly fix them.
• It encourages a more continual interaction between dev and testing, which may mean less of the "I'm done with my work, now it's your job, QA guy" attitude. It encourages people to think of a task as being done only after it's actually verified to be done. Individual developers are more aware of the time wasted by things that should have been done right in the first place. One of the wonderful cautionary tales comes from the development of MS Word - developers implementing methods like GetLineHeight() => 6;. It's obviously broken, but you don't have the time to implementing things right, and you'll get feedback from QA in three months, so you bought yourself some time.
• It makes code ownership more valuable, since it allows you to relatively easily track any issues that crop up in a task with the people responsible for the changes. Sending a thing you know is broken to QA doesn't help you any. This also means that schedules are more predictable and flexible.

Answer 5

Regarding your question "what other disadvantages are when testing is done after deployment?"

• The question which you raised fits good to James Bachs blog question Should Developers test the product first? James is saying that he wants to get the product as soon as is exists for testing, also to avoid barriers between testing and programming. I think starting as soon as possible (also before product is testable) is good for tester since with every look or understanding at the user story / requirement, helps us to get better ideas for our testing scope
• Interesting is also the sentence from James "Sometimes the product is completely inoperable. Even then, I want to have it. Just by looking at its files and structures. I might begin to get better ideas for testing it" >>> means starting testing soon as possible helps us to get ideas about creating possible test scenarios /test cases
• Furthermore with early communication you get well know with the Product Owner, Requirements manager, developer...you know the person who are responsible for it and in case of questions you can raise your hand instead of sending e-mails in a "ping-pong" way just to ask questions. This experience is what we made in our project. When the requirement was written (during that time we didn't introduced the agile way e.g. uster stories) we tried to imagine visually how the button could look like. This helped us to estimate our future testing scope. Furthermore we get to know with the developers and requirement managers and they appreciated our work since we also detected some bugs in early phase. A good link is also from Lisa Crispin What can testers and developers learn from each other?
• beside that, staring as soon as possible with testing activities makes your tester "visible". This was also a problem which we are facing in our company. The testers are not visible. When getting involved to meetings (e.g. requirements, stand up and so on) you make testing activities visible and people know you better

Hope I could help with the links.