Give Your Software Testing Practice an Automation Advantage

Tweet

We see a lot many IT services being provided in a conventional manner, software testing being one of them. This is happening due to lack of exposure to the latest technologies, new methods and benefits attached with them.

In software testing space, there is a buzz about test automation everywhere. However, several companies being new to this are interrogating its capabilities to cater to complete requirements for delivering right software testing services to clients. Some expectations of companies in terms of software testing

• Provide a parallel testing environment to keep pace with the rapid application development framework
• Short software release lifecycles and timely sign-offs
• Test & Regress as much as possible 
• Ability to test on multiple environments such as QA, staging and production 
• Up-to-date availability of documents for every process, defect or activity 

Test Automation has an ability to cater to all these aspects over and above overcoming the drawbacks of manual testing such as time consuming workflows, tedious testing cycle, heavy investments in human resources, etc. Since automation testing is all about executing test cases using automation tool without human intervention, it is faster and error-free. It also ensures consistency, provides re-usability of test cases and gives reliable results. Companies still deliberating for adopting automation testing can count on the following grounds

1. Time saver – Automation testing is surely a time saver since it can run a number of test cases simultaneously 
2. Easy Learning Curve – One can learn to perform automated testing in no time. Testers who are reluctant to invest time in learning before they get labeled as a productive test engineer can certainly opt for automation testing 
3. Zero Coding – Automation testing requires no programming skills or code development experience
4. Scalable – Test automation provides highly re-usable script architecture with simple editing capability 
5. Efficiency – Provides increased efficiency by reducing human errors
6. Economical – Concluding factor as the initial cost of ownership and further infrastructure requirements always counted

How to Become a Resourceful Agile Tester?

Tweet

Simply put, testing is about making sure that the end product is worth the client’s money and meets the requirements. This usually holds good in a traditional project where the requirements are constant and decided at the beginning of a project. However in an agile environment, where requirements are constantly changing and refactored, testing gets complicated.

Traditional Tester	Agile Tester
Traditional testers get a specification document detailing the expectation from the product.	Agile testers use their probing and communication skills to understand the requirements.
Traditional testers begin testing only after the development cycle is completed.	Agile testers need to do testing side by side with the development team and give quick feedbacks.
Traditional testers get adequate time and resources to write detailed test cases/scripts.	Test cases/scripts take a back seat as testing starts early in the product lifecycle.
Traditional testers focus on validating and verifying the end product.	Agile testers also identify faults with design documents, test cases etc.

Challenges for Agile Testers

• Disregarding the traditional testing techniques.
• Lack of proper, detailed and solid documents.
• Short deadlines and demand for quick feedback.
• Effective communication and collaboration with other team members and teams.
• Test coverage may sometimes be overlooked.
• Domain and technical competency cannot be compromised.

Traits of Good Agile Testers

• Good agile testers don't rely on documents, but use their questioning skills to understand a feature.
• It is important and crucial to have adequate domain knowledge of the product under test.
• Some technical competency can help communicate better with the developers.
• Agile testers are expected to evaluate the quality of the product throughout its Lifecycle.
• Testers must have a result-oriented goals, rather than individual ones.  
• Testers give importance to customer value and satisfaction.
• They cooperate with developers in delivering a high-quality product, rather than viewing them as opposition.
• It is crucial to learn new tools, methodologies and techniques that can be implemented in the testing.
• Since time is an important factor, agile testers need to have good time management skills.
• Understand the importance of automating test cases for regression, functional tests and integration tests. Manual testing is more suitable for usability tests and user acceptance tests.
• Agile testers make use of exploratory testing to discover hidden and elusive bugs.
• Agile testers do not just test, but they also question, gather information and make suggestions.

Conclusion

Agile testers become better with experience and practice. However, analytical skills and eagerness to learn are two important qualities that all agile testers must possess in order to succeed. Any traditional tester with an attitude to learn, question, suggest and contribute can become a good agile tester. 

How can Exploratory Testing be Effectively Implemented in an Agile Environment?

Tweet

While Exploratory Testing is not an uncommon methodology used for discovering bugs, rarely it is convened as a comprehensive testing approach. In this article, we have discussed some methods on how to effectively utilize this testing approach in agile environments.

Overview

Though some testers may use the term adhoc testing instead of Exploratory Testing, it is not right to do so. Ad hoc testing, in most cases, means shabby and unorganized testing but Exploratory Testing is far from that.

The concept of Exploratory Testing can be summed up as: simultaneous learning, test design and test execution. So, in this type of testing - a tester interacts with the application, designs/writes test cases, executes them and uses the information/feedback to design next test cases with more clarity.

In exploratory testing, functionalities are checked in a random manner, as opposed to structured testing. A tester investigates and studies the system to coin out the test cases rather than relying on the requirements provided by the business.

Exploratory Testing in Agile Environment

When development cycles are short and requirements are constantly changing, exploratory testing may help save precious time and deliver a high-quality product. In an agile environment, testers may find it useless to design/write test cases as tests may soon become obsolete. Also, testers will need to take out time to manage and rewrite such test cases that will subsequently lengthen the testing cycle.

Agile projects need an adaptable testing technique, which will lessen the work that goes into producing artifacts, and increase the actual relevant feedback or information obtained from the system/process. With Exploratory Testing, testers experiment with the application, rather than blindly following the requirements document. A tester can discover how the system behaves, and why/when it crashes to design better and significant test cases.

Making Exploratory Testing better

It cannot be generally said that Exploratory Testing always wins, hands down. It has its own pros and cons. However, when one understands the pitfalls and treads carefully so as to avoid them, Exploratory Testing does become beneficial and crucial.

• Skilled Tester – Exploratory Testing will be a success only if the tester is skilled and experienced. The tester must be creative and ready to explore beyond the obvious. The tester must also be a quick learner so as to study and understand the system’s behavior.
• Keen Observation – The tester must keenly observe the system and understand its functionalities. It is best to note down the outcome of every experiment (test) so it can be used in designing test cases in future. This helps to rightly assess a product’s quality.
• Short Iteration – This testing approach is best suited when iterations are short and there are several changing requirements. When a requirements document is not in place or business analysts are not available to answer questions about a system, exploratory testing can prove quite useful.
• Scripting – A project may demand automation and scripting for repeatability and efficiency in which case, Exploratory Testing cannot replace scripting. It is important to balance both approaches and implement them as and when the need arises. 

Finally, it is most important to keep track of what has been experimented, tested and learnt during Exploratory Testing so as it make it a success. 

BDD and ATDD – Exploring the Differences

Tweet

Now that we have discussed Test Driven Development in detail, it is a good idea to explore Behavior Driven Development and Acceptance Test Driven Development methods next. This post will help you understand how are these two development strategies different from TDD and each other.

The Basics

Behavior Driven Development is a variation of TDD methodology, where in the main focus is on behavioral specifications of the product or application.  When BDD is adapted in a project, the technical nitty-gritty aspects of the requirements and implementation are outlined in a business-oriented language.

Acceptance Test Driven Development is a methodology that focuses on the overall collaboration between different stakeholders in a project. It encourages the whole team of developers, QA and business analysts to define the acceptance criteria of an application prior to commencing it’s development.

The Differences

Though the above definitions provide us with a brief understanding of these methodologies, their differences need more exploration.

While TDD is about writing tests to satisfy system requirements as outlined in the BRD, BDD encourages developers to write tests such that they reflect the behavioral expectations from the system of the stakeholders, and not just the functional aspects.  BDD uses Ubiquitous language that can be understood by the developers and stakeholders.

ATDD works on the similar lines with subtle differences. In ATDD, the tests are written together with/by developers, testers and customers. Instead of writing up a test case, here, an executable specification is created that can later be run to test the code.

Benefits of BDD

1. The tests, and consequently, the code focus on the behavior of a feature thus making customers happy and content.
2. BDD helps developers concentrate on designing robust solutions.
3. Technical language is given a rest to pave way for better communication and understanding between various parties involved in a project.
4. BDD tools such as Cucumber and SpecFlow can be used to generate test scripts from the written test cases.

Benefits of ATDD

1. One can create executable specification in line with the requirement the can be refined and run at a later date.
2. Testing is moved to the beginning of the cycle thus reducing defects and bug fixing effort as project progresses.
3. Testers, developers and business analysts can work together to better understand what is required from the system.
4. The focus is on the ‘What’ and not the ‘How’ thus making it easier to meet customers’ requirements.

Conclusion

These three methodologies are closely related to each other. But neither can replace the other one as each one has its own merits and demerits. But many teams have successfully used a combination of these methodologies to DO IT RIGHT.

One common advantage of such development techniques is the availability of fast feedback to inspire better development and aid in quick release. The overall concept of ‘write-test case-first and then ‘write-code’ gives the development life cycle a stronger foundation and a stable end product. 

Does Test-Driven Development (TDD) help in Defect Reduction?

Tweet

Rather than following the conventional method of application development by following the flow -> requirements study, analysis, design, development, implement, test and bug fixing, TDD uses a slightly varied methodology.

The TDD Methodology

The series of steps in TDD to be followed by a developer are:

1. Study the new feature/functionality.
2. Write a simple automated test case to test the new functionality.
3. Run the new test case, result should be FAIL.
4. Change the code to implement the new functionality.
5. Run the test case again, result should be PASS.
6. Run a regression suite to uncover any regression defects. (This step can be carried out before every release or at reasonable periodic intervals.)

The most important condition for TDD to be a success is correct understanding of a requirement by the developer. If the developer misunderstands a requirement, the test script and consequently the code will be wrong.

Benefits of TDD

There have been discussions on whether and how TDD can prove beneficial when applied to the software industry. Right from improving a developer’s confidence to defect reduction, when adopted appropriately, TDD can help handle complicated software development challenges.

• Requirements Coverage – The developer writes a test case to test each feature so there is one-to-one mapping which helps the developer ensure that no features are left out.
• Structured Design – When the developer begins by writing a test case, the focus in on how the end user uses the feature and the kind of interface that must be provided. It is not just about fulfilling the functional requirement.
• Defect Reduction – The developer can instantly catch a bug once the new code is added to the code base. Bug fixing is considerably easy as the source is isolated and known. Also, regression bugs can be reduced to a large extent thus enabling a smooth integration of new code with the existing one.
• Early time-to market – Since the developers test and fix the code almost instantly, the overall application development time is reduced. Furthermore, this approach eliminates the chance of a major code break, (when multiple developers are working) thus encouraging developers to make code changes at a faster pace. 
• Futuristic Use – The test scripts created by developers are exhaustive and focused and can be used for regression testing later in the project lifecycle.
• Developer’s confidence – Once the practice of test-first-code-then sets in, developers get a better understanding of what is needed, consequently helping them code better and with confidence.

TDD and defect reduction

There have been studies and researches to find out whether TDD actually helps in defect reduction, and it can be safely said yes, it does. However, depending upon the nature of the application and frequency of changing requirements, other methods such as code inspection can prove more effective in defect reduction.

The cost of investment and benefits of these methods must be studied with respect to a project to understand the best defect-reduction technique. In some projects, a combination of different methods can be implemented to improvise software quality.