Developers and Testers: Two people from two different planets working together to deliver a quality product to an “Alien”! Funny isn’t it?! The story is more or less the same in every software firm. A developer works hard to develop a product, which he handles with so much care and gentleness; a tester works hard to break this code handling it in the worst possible cases and scenarios to test its defects, resistance power, and strength.
So, when a developer finally hands over his much-nurtured sprint to the merciless team of testers, ready to execute the ‘out of the box’ testing, this is what happens:
o User Interface element alignment? Off!
o Inputting special characters instead of string? Unknown result!
o Putting 01 for a range from 1-10? Crash!
o Entering a date in the past? Crash!
o Working with special characters in names like, Neil ’O? Nope!
And there they silently demolish the code….
Sandpapers scrape and scratch, but to create polished surfaces!
So, there is this formidable wall between developers and testers most of the time, which stops them from having a sustained smooth association. There are many reasons attributed to this silent difference in opinions. For instance, developers are often seen to possess parental attachment to the stuff they create. It’s more like; “I know my kid, he wouldn’t do that”, when the reality is, the kid actually did just that! It might sound silly, but a good programmer should learn to be more objective and accept the fact that they have to do terrible things to their code. Because, if they don’t, others will!
Another problem is, developers have little or no idea how their code is going to be handled at the other end of the boundary wall, and thus they aren’t ready for the million bugs that testers backfire at them. Being in the developing environment, which usually revolves around positive scenarios of how to make things work efficiently, they often lack the ability to switch to ‘what can go wrong’ mind state.
Programmers are pros at breaking down complex scenarios into small programmable chunks; ‘The Computers’! – What can be a better example to support that statement! Can you imagine, the computers do all their work with just 0 & 1, the binary numbers and some operations on these, like OR, AND, NOR, NAND, NOT, XOR and XNOR! On the other hand, testers are experts in finding complex scenarios, where they can probably uncover a glitch to break the system!
Thus, the million justifications, silent cursing, and muted murmurs before finally reaching “The end product”! Though these are the situations, the product keeps gaining value from the combined efforts of programmers and testers. And that is how self-resistant codes are born; after all, testers care for their end product, you see! And it’s for developers to realize how their application can flunk in million ways, any time!
Developers with Testers- the perfect wedding!
Though organizations often make efforts to improve the communication between developers and testers, this is often not enough. If only their thoughts cross these barriers and start thinking somewhat within the same boundaries, can we expect super conflict-free Apps! (Pun intended)
It’s always a good idea for programmers to sit through some training/seminars that test engineers attend. A Developer who has attended such seminars is found to avoid making silly (yet common) errors and is often more vigilant. Moreover, a programmer’s awareness of testing tools, methods and processes goes a long way in enabling smooth and fast testing practices. He learns to stand in tester’s shoes while writing codes, to understand what in his code can probably be a tester’s target, what changes he makes will give testers a tough time and what makes it easy, thus making the entire process productive. For instance, any coder might not find it an issue to change a button label from, say, “Clear” to Reset”, but a developer who has sat through the testers’ seminar/ training can probably understand why this silly button label change affects the testing and how it can be frustrating to his colleagues in Testing.
The developer can thus create applications keeping in mind the worst cases that his code can go through, or gets tested in. He will eventually learn to make discipline around testing (or breaking) his own creation- his own code, which indeed makes him a better programmer. So an out of the box thinking is always good! Also, testers need to understand that everything changes with time, and so are the cases with software development too. It doesn’t make sense to change/ rebuild the code every time there’s a change, but the efficient solution is to encourage programmers to make wise changes in their code than to frequently change it.
One team- One goal
In hybrid agile development environment like ours, we handpick Engineers from departments, to form a dedicated team working together throughout the lifecycle of a particular project, with the single goal- the final release! I say ‘Engineers’ and not testers, designers or Business Analysts (BAs), because everyone in this team is a developer, and contributes to the development. This ensures that there are no separate groups (like developing group, testing group, BA, etc.) coming into play at various stages of developing a product, but a single team dedicated to every phase of the product development- from day 1, Sprint 0 to the Release of the End Product! This practice guarantees that the resources and their time are fully and efficiently utilized at every phase.
For instance, with the beginning of a new project, from day one, that is, the initial product backlog creation stage, you have a team in place, consisting of testers, QA experts, developers, UI designers, DBAs and analysts gathering at every SCRUM meetings, to discuss and contribute to everything they may not be directly involved in. Even before the development of the product starts, that is, at the programming estimation phase, testers start writing test cases, estimations etc. for features that will be developed, BAs do the requirement analysis and stuff, Developers plan and decide on features, and so on. At each SCRUM meeting, the team determines how it shall accomplish the work that needs to be done. This way, not only everyone has tasks throughout the sprint, but also knows and understands the roles, responsibilities, hard work and effort taken by each member. Thus, they learn to respect, understand and get on well together to work as a REAL POWERFUL TEAM!
Ultimately, we know the entire team has one single goal- “A Quality product”! It’s just that the developers and testers take entirely different paths to get there, just as in the much-admired Love stories!
Many a time, we have come across chief business managers and executives who have had a tough time deciding on the kind of approach to adopt while developing a mobile application. That is, whether to go for a native application or a hybrid application. In order to help them make better and more informed decisions, we had put together the major features of both and some factors to consider while choosing a method of development on one of our previous articles – NATIVE Vs. HYBRID: Things to Know Before Building Your Next Mobile Application.
Here we discuss some important points on the development aspect of native as well as hybrid applications.
It is often much easier to develop a hybrid application than a native application and there are several reasons for that. Hybrid apps can also be developed a lot faster than native applications for the same reasons. These are the main development aspects of native and hybrid apps:
Programming languages used
In the case of native apps, there are specific languages used for specific Operating Systems or platforms. That is, Java is the language used for programming an Android app, Objective-C or Swift are the languages used for iOS apps and C# is the language for Windows Operating system. All of these have their own standard Software Development Kits (SDKs), which provide the necessary tools and interface elements for development. Native apps have full access to device capabilities like the camera, the contacts, the accelerometer etc. Hence, they perform better.
In the case of hybrid apps, the languages used depend on the type of hybrid technology that is used for development. Some of the most widely used hybrid technologies that are used today are PhoneGap, Flex, Corona, and Xamarin, although the latest and most popular ones are PhoneGap and Xamarin. The programming languages used for these technologies are as follows:
Flex – Actionscript for Flash
Corona – Lua
Xamarin – C#
The application is developed using these technologies, coded in their respective languages and is then hosted inside a native application’s web view. This enables them to have access to device-specific features like the camera and contacts.
In the case of native apps, the code has to be written from scratch. That is, each time an application is developed for a particular platform, the code for its programming has to be written from the beginning. For example, if a native mobile application has to be developed for both iOS and Android platforms, the coding has to be done wholly and separately for each platform. That is why, it requires more time and effort. Separate development teams have to be employed for both platforms and separate SDKs will have to be used with separate interface elements like text boxes and buttons, all of which add to the cost of the application.
On the other hand, in the case of hybrid apps, coding is a lot easier. Most of the code written to program an application to work in a particular platform can be reused for the same application to work in another platform. For example, if a hybrid mobile application has to be developed for iOS and Android platforms, most of the coding done for that application to work in iOS can be used as such while programming it for Android as well. It basically means that the coding need not be done from scratch, unlike native apps. It is for this reason that hybrid apps take much lesser time and effort. Since a single development team can be employed for the application, the cost also is fairly lesser when compared to native apps. Along with the programming code, plug-ins also need to be coded in the respective native language for hybrid apps, in order to enable hardware capabilities access.
User Interface (UI) Frameworks
In the case of native apps, just like programming languages, the UI frameworks used for the development of each application vary with the kind of platform. UI frameworks basically provide the user interface elements like buttons, radio buttons, checkboxes and textboxes and also contribute to the visual aspects of the app. They are responsible for the look and feel of the app. For example, IONIC is a UI framework that is used to build the interface of mobile applications mostly native. It is used with Cordova when developing applications and uses the language AngularJS. Similarly, Android apps use the framework bootstrap.
In case of hybrid apps, Intel XDK provides UI elements and allows you to build apps on any platform.
Integrated Development Environments (IDEs)
IDEs provide the facilities required for mobile app development. Most IDEs consist of a source code editor, building and automation tools and a debugger. They differ with the platform in case of native apps as follows:
iOS – XCode
Android – Eclipse
Windows – Visual Studio
In case of hybrid apps, the IDE used is part of the technologies that are used like PhoneGap and Xamarin.
Dependencies arise only in the case of hybrid apps since they make use of plug-ins coded using native language depending on the kind of platform. Plug-ins have to be coded in order to enable access to the device’s hardware capabilities as mentioned before. That way, they need code to program the app as well as for its plug-ins. In the case of native apps there are no such dependencies as they are coded entirely using their respective language according to the platform. Since they already have access to device capabilities, they do not need plug-ins.
These were the differences in the development aspect of native and hybrid apps. Even though native apps take a longer time and effort for development, they are better in terms of performance when compared to hybrid apps. Since native apps can use device features without the use of plug-ins, they are more accurate and much faster than hybrid apps.