Agile Testing Myths

Almost every existing process comes with it’s own share of understanding at individual level. Software Testing itself has always been a debatable topic. It is surrounded by many myths all of which have counter facts associated with them. Head on to the post – Software Testing Myths and Factsto read some of such misconceptions. Therefore, Agile Testing Myths are there out in open aswell.
Agile Testing Myths
Coming back to Agile Testing, below are common assumptions many teams have:

Agile means

ZERO documentation
Documentation is a critical process project teams run away from. With Agile in force, it is a generic response to get that – “Since we are following Agile, there is no documentation of requirements and other details”. Actually, If followed sincerely, The end result of an Agile project would result in much better and detailed documentation which would be well structured, easy to read and follow.
No planning
Ask an agile team for their project plan, the maximum they would be able to provide is the current or current + next sprint backlog. On the contrary, Agile process insist on having the sprint backlogs ready for current along with upcoming 2 sprints along with all the estimates and acceptance criteria. Thus, in practice, planning in agile projects is more rigorous.

Unit testing

Is sufficient and thus remove the need for manual testing
It is a common misconception that if Unit Testing is performed effectively, testing activities may be skipped. While it is true that unit tests play a significant role in reducing bugs, the fact that they cater to specific and limited scope must be considered as well.
Can be built into regression suite
In continuation to the point above, creating a regression suite from unit tests is also seen as a practice in some teams. Projects must understand that Regression Testing is altogether a separate activity with it’s own scope. While some of the unit tests would always be common to both regular test cases as well as Regression Test Cases, compiling all the unit tests in one place and calling it a regression suite is a complete no-no!


Is impossible
Test Automation in Agile development projects is sometimes considered an impossible task! The main reason for the same is lack of time. But then, I think, the remedy to this points to the very first myth – “Agile means No Planning”. The need of Test Automation and scope for the same must be a part of planning process from the very beginning.
Remove the need for manual tests
With automation in place, projects tend to avoid manual tests in respect of time and resources. Since, It is not possible to cover each and every case in automation, Manual Testing can never be replaced by Automation Testing. Even if the tests show 100% coverage in reports, exploratory testing generally done unintentionally as a part of manual testing would be at loss.

Testing is not a part of ‘Done’

It is quite typical with the development teams to mark a story done after implementation from their end even before it is tested. Sometimes, to get the burndown chart right, teams even move the user story to “Done” state if it has a bug associated with it. The explanation given is that the bug thus raised is already in backlog, so the user story should not move forward.
In ideal practice, any story is not “Done” until is has been tested successfully with no pending bugs associated with it.
More Topics in this series:
Testing in Agile
Approach to Agile in Testing
Challenges for Testing in Agile
Advantages of Testing in Agile
Principles of Agile Testing
Best Practices in Agile Testing
Agile Testing Myths

Software Testing – Myths and Facts

“Software Testing is relatively new” – I get irritated whenever I hear or read this. As if before the term, software’s being developed were not tested. Oh, I used the relatively new word again – checked for their expected behaviour.

Image source:
So, when we talk about myths about software testing, the above stands on top. There are few more I have tried to jot down in no particular order. Let’s see if you agree.

1.  Software Testing is relatively New
I do not need to write anything for this. We get to hear this ironic term at all places – big or small.

Fact:  It has been existing ever since first piece of code was written.

2.  Testing is boring
Testing being a monotonous activity is reflected very frequently at almost every platform. People have a misconception that testers keep on doing the same old clicks and data entry without any creativity.

Fact: A statement somewhere on internet says it all – “Testing is like sex. If it’s not fun, then you are not doing it right.”

3.  Testing is easy/No formal training is required
Testing being an easy job is another big misconception. There are arguments all over the world that since users keep on finding bugs, it’s no big deal being a tester. Sometimes, a proper planned formal training for the same is also neglected.

Fact: Many times testing proves to be more complex and tedious than development as its difficult to analyze the behavior without code (I am not saying that developers have an easy job, but access to code gives an edge on analyzing the behavior), Testers require a deep understanding of testing methods, business requirements and the development process.
Formal training and experience makes a good tester with solid skills or we can say a valued resource.

4.  Anyone can test
I cannot forget the statement by one of my managers – “Amita, don’t fell offended, but the fact is that testing can be done by anyone. I mean, you need special skills and technology knowledge to develop the software, but testing can be performed by developers as well.”

Fact: If that was the case, no company would have paid a dollar to testers. There would have been no companies that specialize in only testing services. This is the trap management falls into.

5.   A tester’s job is to find “ALL” bugs
100% test coverage is one of the top goals of most of the testers. This is the most common myth which clients, Project Managers and the management team believe in.
Fact: This is the trap management fall into. The very first principle of software testing states that – “Testing shows presence of defects”. Testing shows that defects are present, but cannot prove that there are no defects. Even if no defects are found, it is not a proof of correctness.
6.   Automated Scripts replace manual testing
Whenever I give a POC for automation, people have an impression – “Wow! Just click and all done!” Statements like – “So, if you create the scripts once, we can just run them for next releases”. This is the most common misunderstanding that automated tests are equivalent to manual tests. The worst is that there are testers and test managers who actually believe it.

Fact: No test automation tools can ever replicate human feelings or emotions.
For example, a tool can test the fonts, color and layout of a screen is as per the test script but it can never analyze if a screen is user friendly.
7.    Software Testing is “time consuming” and “expensive”.
I personally get the emails to revise our estimates for testing efforts very frequently. Sometimes, I hate to justify the minute details of my estimates. The considered myth that its too much effort – “time consuming” automatically generates the next one – “Expensive”.

Fact: Software testing principle 3 – Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
One cannot expect the testers to be magician and test the code overnight when they have no idea of background.
Decide – Pay during development or pay latter for production issues and reputation.
8.  Software Testing is same as Quality Control
I can bet that almost 90% people confuse testing with quality control. Software Testing, Quality Assurance and Quality Control are the terms used almost interchangeability.

Fact: Testing is just a component of software quality control, wherein a tester identifies the bugs for the stakeholders. Quality Control include many other activities like Reviews – Self review, peer review and structured walk through

9.  No changes – Regression testing is not needed
Regression Testing is skipped many times to save efforts. There has been no change in this code is the most common excuse to that.

Fact: Even if the module was not touched, spending some bucks on re-verifying the results may save the cost of an unidentified bug or scenario.

10. Software Testing is the career choice for failures
Fresher’s dread the software testing field. They think that it does not offer career growth and is a low profile job.

Fact: Think again. Facebook, Microsoft etc. pay millions to find a bug.

These are the most common myths I have faced during my career. If you have any additions, or faced similar experiences, please feel free to comment or share. This does not do not welcome general like/dislike comments. I love them the most… 🙂