Do Testers and Programmers have Conflicting of Interests?

Testers test the applications which are developed by developers belonging the output of the analysts. Analysis - Development - Test is trivet for software development projects and absence of one or not ideally running one of these steps can lead software project to fail. However, in high level thinking we may characterize analysts as solver, developers as producer, and testers as destructor because the major tasks of each role need these kinds of abilities. As a consequence, developers and testers have different abilities and different tasks, which may be concluded that they have opposite tasks such as one is to develop and one is to destruct the software; so they may have seen as having conflict of interest. In this post, I want to explain why the testers needs to search a way to destruct the software product which developers have already made an effort on it.

The testing stage, for me not a stage it is a groups of activities from beginning to the end of software development life cycle (SDLC), covers if system under test (SUT) is developed as what user wanted and, if the SUT reaches the standards. By testing, we may sometimes need to search how the application behave un-expected way. To accomplish this task, we need to think beyond the analyts, because we learn the application during test and can make an assumption about the point which is error-prone. Actually this is the base of exploratory testing, but it is more than this and it requires a well-trained testing knowledge and experience

There some important key factors affects the degree of the quality perceived by the people who work together to produce a software product. This can be listed as test strategy, test approach, risk, maturity of production environment and test environment, experience of the people, system reqıirement, number of user, profile of the users, domain, and ect. The most important one may be test strategy. Test strategy is a defined rules which everyone has knowledge about how to test the SUT and if any defect found, everyone can be estimate how the defect can be classified and know the procedure for resolution of the defect, more about test strategy read this. Therefore, test strategy is a common knowledge for the organisation and can be applied if any controversy has been occurred. This is important because it can be pro-active approach for this case: sometimes testers may test more than what the organisation want and requires more time than expected or developers may submit less quality product for testing than expected also re-work cycle can be longer than expected.

To sum up, testers should find a way to destruct the SUT so that it can be reach to aimed quality level and the developers should also know this and it helps to tester for finding defect by explaining the structure of the codes. This requires wisdom. Sure this is a feature of a good development environment, but the un-smart development organisation may not have this. To remember what a smart which is defined by Ivar Jacobson: 

Unsmart with Testing – having two classes of people – developers and testers. Unsmart projects testers are “the cleaners in the software world” – picking up the mess left by the developer.

Smart with Testing – the whole team is jointly responsible for quality and testers are first-class citizens



Popular posts from this blog

Selenium Error "Element is not currently interactable and may not be manipulated"

Performance Testing on CI: Locust is running on Jenkins

Change Default Timeout and Wait Time of Capybara

Getting the text of elements in Espresso

How to Set Shared Preferences in Espresso Test for Kotlin and Java