How to Do Software Testing in Scrum Environment?

06 Nov, 2015
Xebia Background Header Wave

Software development has evolved over the past several decades perfecting itself each time, to become more and more scientific in its approach and predictability. However, there is a strong artistic side to software development that gets manifested in the areas of design and architecture.

Creativity and innovation play an important role in developing high quality software that solves the users’ problems and provides a smooth user experience. The quality aspect of software is a direct output of the rigorous testing process adopted during the design and development stages. The field of software testing in scrum environment too can borrow from the guiding principles of art.

Robust code branching

Fundamental to the success of a software product release is configuration management, particularly in how the branching of code in planned. An ever moving trunk, a highly unstable sprint/feature branch and a stable release branch form the quintessential demarcations of code. Testing is the quality check that is imposed on these branches as a requirement for synchronization with each other. For instance the measure of stability of trunk is a successful execution of regression test. Stability of sprint branch is the successful completion of system test. Stability of the release branch is the success of acceptance test.

Rule of thirds

The principle of “rule of thirds” seems to apply ‘naturally’ to the process of software testing in an agile development environment. The rule of thirds refers to an imaginary grid drawn across a canvas area that breaks it into nine equal squares. The most interesting points for subjects are at the intersection of these lines. Placing the important elements on these point/lines results in a balanced composition that gains instant approval of the eye.

Similarly software testing interactions done at one third time intervals of the development lifecycle (iteration /sprint) yield the best results. While agile prescribes continuous interactions through the development lifecycle, in reality this is left for the team to determine and execute leading to a customized, personalized process. However as a rule of thumb, interactions at one third intervals can be productive for the developer and tester in three important ways.

Automated regressions

An automated regression test suite is a must have to cope with the frequent validations that are needed. That is easier said than done and in practice, failures in this approach have led to skepticism on the fitment of test phase in scrum environment. The best way to work around this is to consider automation a serious investment and therefore, run it as a full-fledged project with the sponsorship of the stakeholders. Again, within automation, separation of user-interface automation and functional automation goes a long way in organizing these tests better, especially with respect to the choice of automation tools.

For instance, Selenium, an open source tool, could be used for UI flow testing while for the input-output web service request-responses; a SOAP UI kind of a tool would execute the tests in the background. An automation suite running on a nightly build ensures what is working has remained undisturbed after the code change too – ssentially regression tested. Automated regression can be done at various levels, namely – the unit level, functional level and the system level regression. While the unit level of regression is a part of the developer quality assurance, the functional and system level regression tests are core for the overall success of the product quality assurance.

Error: Contact form not found.

Anirban Guha
Software Engineer at coMakeIT

Get in touch with us to learn more about the subject and related solutions

Explore related posts