Hiring Tools

Quality Assurance is more than just finding bugs in an application. The QA team focuses on delivering a quality product that is developed by a developer,within a deadline. The QA team’s primary task is to eliminate the issues that may affect the way the product works and thereby hampering the user experience.

When we approach testing in a project, irrespective of how small or big a project is, we always strive to achieve the testing pyramid. If you have never come across this model then go and look it up, it’s on the list of being a badass!

“Quality is not an act, it is a habit.”— Aristotle

Here is the pyramid,

Why Quality Assurance (QA) is a must in software development?

The longer a bug goes undetected, more expensive it is to fix. A simple cost vs. benefits analysis overwhelmingly shows that the benefits of employing a QA test engineer to validate the code far outweighs the costs.Most importantly, it also influences your product’s reputation!

Here is why the QA process is important in software development:

• An extensive QA process is performed to eliminate avoidable defects or bugs before a site is made live.
• QA is done to make the website credible and easy to operate.
• What if the search button of a search engine like Google, which is used by millions of people every single day, doesn’t work? It might require a simple fix, which can be done by a developer in a jiffy. However,this defect will encourage users to use a different search engine,which leads to a loss in users
• A proper QA process will help you find defects that can be fixed before the website goes live.
• When a product is launched, it is a must for the product to have undergone the complete QA process. What if the product is launched and the users find that something is not working as expected? The company will lose its credibility, reputation, and resolving the issue will become expensive and time-consuming
• The QA process is not just for delivering stable products there is a higher purpose. The purpose is to make users and customers believe that the company is credible, retain the number of users, provide the users a great experience.

If you are still skeptical, look at these stats!

• In April 26 1994, China Airlines Airbus A300 crashed due to a software bug killing 264 passengers.
• In April 1999, a software bug caused the failure of a $1.2 billion military satellite launch, one of the most expensive accidents in history.
• In May 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US dollars.

The QA process can be a lifesaver sometimes, can’t it?

How is the QA process performed?

Method

Courtesy:Jack Sheppard

The QA should be aware of the stack, the frameworks, the business purpose of the feature, and most importantly understand the customer’s and user’s pain! This is where the QA process starts and this is where you should begin!

We believe that the QA then enters into the Design Phase and starts its transformation from then on. Having a pre-design QA assessment is even better. Once the company decides to build a product, the PM schedules a meeting with the developers, QA engineers, and designers.

During this meeting, the PM explains the purpose, need, and user requirements that will be used when the product is built.This clarifies information about design, engineering, stack, and other engineering requirements. During this time the QA engineer will understand and clarify information about the origination of the requirement.From there on, QA becomes an integral part of every process till and after the delivery of the product

The following processes must be followed for an effective QA process:

Design QA

Once the design is completed, there should obviously be the obvious design QA. The QA engineer has a discussion with all the members of the software development team.

In this informal discussion table,the features in the product would be explained to the entire team,which they will soon be starting to develop.Then we start the design QA, in which the QA team will go through the entire design to check about functionality, feature, enhancements, user requirements, business purpose validation, potential issues, foresee complexities that may exist and are briefly made aware on the drawing board to the devs during the design QA process.

Create the test scenario document

After the design QA is done, the QA team starts designing a test scenario document (sample template), which is a hybrid of use case and test case documents.

This document will be used throughout the testing phase. It contains a list of all the possible scenarios that are identified for testing in the product based on the design. Once the testing begins, the scenarios will be iteratively added during the Executing phase.

Documentation review

Documentation review is a critical step in the QA process.This review decides the direction of the testing process and direction is very important.

This review is done by developers or the PM before the execution phase starts. In this step, either the developer or the PM goes through the test scenario document that was created by the QA team and checks whether all the scenarios have been covered.

If a scenario is missing, it is the shared responsibility of the PM, developers, and QA engineer to ensure that it is added. It is recommended that you do not start testing until all the scenarios have been added to the document.

Execution

Execution is the phase where the real testing happens. The testing process is started when 75% of the product has been developed thus avoiding rework by the time the development reaches 95%.

Rework is mitigated by the test scenario document which was created during the test scenario phase. If you take up QA earlier, then you will not have the appropriate QA and test coverage. If you do QA after the product or feature has been fully developed, then you will have to deal with a lot of demotivation among the developers due to rework.

You must test all the scenarios which are covered in the test scenario document along with the scenarios which you come across while testing the actual product. Add the new scenarios to the document while testing.

The execution phase takes its own time.There will not be any compromise on the time for QA. The results of the execution will be noted in the test scenario document and the same will be shared with the developers who have developed the product.

During the execution phase, not only the scenarios are just covered but the user experience would be tested too.The way the product behaves,all the functionalities,features,UI would also be tested.If a scenario fails.We would add the explanation of it along with the screenshot,URL,steps to reproduce.

Defect reporting

As Joel says in his blog,

“A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being than a La Marzocco Linea espresso machine to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it’s depressing to be a programmer.”

During a sprint ,the defects that are found should be noted in the a defect summary sheet (sample defect summary) of a test scenario document (sample template).This helps the developer to view the defect along with the explanation, screenshot, URL, and steps to reproduce the defect.

The developer then fixes the defects. If a defect is not valid, then it will be classified as one of the following:

• Feature
• Bug that cannot be fixed for various reasons or requires a design change.

Otherwise, the defect is marked as fixed in the relevant column of the test scenario document and also updates the Maniphest log. The defects can be related to the functionality, features, UI, or anything that affects the way the product works.

Maniphest

Maniphest is one of the defect-management tools that is used during the QA process. It helps to manage the entire bug life-cycle. As tests are executed, you may find bugs in the existing flow or may feel there is scope for a few enhancements. You should immediately, create a task in Maniphest and assign it to the relevant developer.

Based on the priority, bugs will be fixed. Once the bug is fixed, the author of the bug i.e. the relevant QA engineer will receive an email notification.This helps the QA engineer to retest the bug and change the status accordingly.

Retesting

Once the issue is marked as fixed by the developer in the test scenario document, the retesting of the specific defect is the responsibility of the QA engineer who reported the issue. The results of the retesting should also be recorded in the test scenario document.

The Testing phase ends with this step. Retesting will be done at the end of the Execution phase because execution is usually done on a fully developed product—the most stable version of the product.

Test closure

This is the step where the QA team prepares the release notes of the testing process.

Release notes contain the following information:

• Description of the product that was tested
• Time taken
• Approach followed
• Reference links
• Test results
• Type of testing that was done

After the release notes are sent to the whole team, the QA process ends.

Types of testing at HackerEarth

Automation testing

While there is plenty of room for improving the QA process at HackerEarth, we are now trying to put an emphasis on building automated tests so that we can let people do what people are good at and have computers do what computers are good at. That doesn’t mean that we never do manual testing or drop out of the pyramid. Instead we do the “right” amount of manual testing with more human-oriented focus (e.g. exploratory testing) and try to ensure that we never do repetitive manual testing.

Performance testing

Performance testing is an important type of testing which is a must before deploying any new change. Performance testing is performed to determine the behavior of a system under both normal and expected peak-load conditions. It helps to identify the maximum operating capacity of an application.We use New Relic for the performance testing.

“An application can work fine for a single user but may break when multiple users use it simultaneously.”

We use JMeter to perform load testing.

JMeter creates realistic & accurate scenarios, sends requests to appropriate servers which show the performance of an appropriate server/application via tables, graphs etc.

Environments used for testing

We have an environment that is a replica of the production environment. It is called the ‘staging environment’.We use this staging environment for the testing process.

The developers develop an application in their local environment and push it to staging where the QA engineer will test the application. All the testing takes place in the staging environment.

We would never have been able to get this far and achieve an effective QA process without a dedicated grassroots effort from everyone in the team. This effort would have failed if it hadn’t been combined with huge improvements in our testing tool, processes, and mind shift along with the business and developers.

“QA is hard!! If it was easy, anyone could have done it. The ‘hard’ part is what makes QA important!”

We have taken a serious and pragmatic approach to establish a definite QA process. The important thing about this process is that QA at HackerEarth has evolved into a multi-dimensional process. We have formulated this QA process collaboratively and improved it over time.

Wondering what is the best way to introduce QA process in your team? Just get started! Good luck!

Fintech is the application of technologies to disrupt existing processes or bring in new paradigms in the financial industry. Be it banking or insurance or digital payment, fintech is currently revolutionizing the world.

Fintech has disrupted all aspects of the industry. Rapid innovation is the key in sectors like lending, financial inclusion, financial advisory, personal finance, security, and digital payments. Fintech, on one hand made services like Net Banking a given in today’s world. On the other hand, it has made names of startups like PayTM a common word in the vocabulary of the laymen.

Fintech companies are more customer centric than traditional financial companies. They believe in rapid innovation. The fact that many of the early adopters are low-age groups with disposable incomes has made fintech one of the hottest trends in technology.

What are the companies in fintech?

There are mainly four types of companies that are interested in fintech.

1. Major banks that have traditionally been associated with finance and look at technology and fintech as the next level, for example, any large bank that has technology offerings
2. Well-established tech players that are also looking for business opportunities in the financial services space although they are not traditionally financial companies, for example, we now have the Google wallet and the Apple pay.
3. Companies that provide infrastructure and services which enable other fintech players to operate in the financial space; examples include PayUmoney that acts as a payments gateway, or MasterCard, which processes payments between banks of merchants when the merchants use the cards that are issued by the banks

Disruptors that are fast-moving companies and startups; these companies generally focus on a single business innovation or process. For example take SoFi, it is a San Francisco based company that focuses on high-earning recent graduates and tries to refinance their student loans. Or take the case of PayTM, which focuses on the Indian payments ecosystem.

What are the major fintech areas that are driving innovation?

Lending: Lending is the space where the biggest innovations in fintech are coming from. Traditionally, lenders have given more money to people who already have money. Fintech companies are doing away with the traditional credit history-based scoring system and coming up with lending solutions even for the unbanked. For example, Lending Club operates an online lending platform that helps borrowers get a loan and investors purchase notes backed by payments made on loans. Others like Biz2Credit are using social profiling tools to access the credit worthiness of individuals and small businesses.

Financial Inclusion: Experts believe that fintech is the key behind financial inclusion. For example, M-Pesa reached 80% of households in Kenya in 4 years[source]. Fintech companies achieve financial inclusion through various methods. One of them can be by leveraging existing low-cost solutions, like M-Pesa doing transactions through SMS. One other example is Kobocoin, which is giving an existing technology, blockchain in this case, a more local flavor so that it reflects the needs of the masses.

Even for developed countries, companies that focus on financial inclusion have the potential to make social security programs more effective. For example, in various parts of the world like Japan and India, public benefits are directly paid to the bank accounts of the recipients and the process is tracked through a Unique Identification Number like Aadhar Card in India or the My number(??????) system in Japan.

Financial Advisory: Fintech companies have generally relied on automation to provide services and this is the strategy being applied to traditional advisory services like M&A transactions, restructuring, raising capital, and forensic investigations. There can be a common platform where the users can engage with the experts as in BankerBhai.com. One more example is Elliptic, which provides services like identifying illicit activity on the Bitcoin blockchain.

Personal Finance: Through the use of fintech, there is a lot of scope to have more efficient processes. Many organisations are building companies by automating the acts of personal finance like individual or family budgeting, insurance, savings, and retirement planning. For example, Wealthfront provides online money management. Paytm tries to keep all your different payments under one portal.

Blockchain and distributed ledgers: Blockchain, which is the technology behind the famous bitcoin, is an open source distributed database using state-of-the-art cryptography. Currencies that use blockchain enable us to do transactions without a powerful third party like a bank or the government. There are various companies that are operating in the space of blockchain, either by using bitcoin, the largest blockchain, like Blockchain.info or Unocoin, or by having their own blockchain cryptocurrency like Kobocoin.

Security: Fintech is only projected to grow in the future and since this domain primarily deals in finance and financial products, customers will have high expectations in terms of security from fintech products. Also, fintech companies will always be a lucrative target for people with malicious intent. For example, there was the JP Morgan Chase data breach in 2014[source] which affected 83 million customers accounts. For this reason, heavy investment is being done in security. and we have a lot of companies in the field. For example, VKey focuses on user security. Tranwall is a Hong Kong startup that focuses on providing increased levels of security to the cardholders of the customer banks.

What is the future in fintech

The rise in fintech has led to growth in both customer awareness and customer expectations, and this acts both as a challenge and as an opportunity. This has resulted in financial incumbents, those who are already established financial services players, taking bold steps and engaging with emerging innovations. Also, new start-ups have found greater acceptance with the population. Following graphs show the amount of investment the fintech companies have received globally.

Image: the growth of global investment in the fintech sector from 2011 to 2016

Source: Business Insider

Users are also spending more time on various apps and doing a greater part of their financial transactions through the apps.

User activity on various payments apps
Source: Nielson

If you think that these trends are astonishing, remember that this will only grow in the coming years.

References:

techstory: lending market in india
letstalkpayments: 22 fintech companies in africa

fintech is the key driver of financial inclusion
fintech and financial inclusion
how fintech security helps foster innovation
fintech companies in fraud prevention
how banks are leveraging developer community

step 6: Determine centers of the neurons using KMeans.

K_cent= 8

km= KMeans(n_clusters= K_cent, max_iter= 100)

km.fit(X_train)

cent= km.cluster_centers_

step 7: Determine the value of [latex]\sigma[/latex]

max=0 

for i in range(K_cent):

	for j in range(K_cent):

		d= numpy.linalg.norm(cent[i]-cent[j])

		if(d> max):

			max= d

d= max



sigma= d/math.sqrt(2*K_cent)

step 8: Set up matrix G.

shape= X_train.shape

row= shape[0]

column= K_cent

G= numpy.empty((row,column), dtype= float)

for i in range(row):

    for j in range(column):

        dist= numpy.linalg.norm(X_train[i]-cent[j])

        G[i][j]= math.exp(-math.pow(dist,2)/math.pow(2*sigma,2))

step 9: Find weight matrix W to train the network.

GTG= numpy.dot(G.T,G)

GTG_inv= numpy.linalg.inv(GTG)

fac= numpy.dot(GTG_inv,G.T)

W= numpy.dot(fac,Y_train)

step 10: Set up matrix G for the test set.

row= X_test.shape[0]

column= K_cent

G_test= numpy.empty((row,column), dtype= float)

for i in range(row):

	for j in range(column):

		dist= numpy.linalg.norm(X_test[i]-cent[j])

		G_test[i][j]= math.exp(-math.pow(dist,2)/math.pow(2*sigma,2))

step 11: Analyze the accuracy of prediction on test set

prediction= numpy.dot(G_test,W)

prediction= 0.5*(numpy.sign(prediction-0.5)+1)



score= accuracy_score(prediction,Y_test)

print score.mean()

With an RBF network, a prediction with an accuracy of 88% is achieved and so is the cause with MLP. However, the computational cost of training an MLP is much higher as compared to RBF; hence, here it's better to use RBF network instead of MLP.

Guest Post Blogging Guidelines

As a guest contributor, you agree to allow HackerEarth to publish original articles written by you on HackerEarth’s website.The content HackerEarth accepts must: comprehensively cover a topic, be presented from a neutral and unbiased position, and provide informative and educational content for our readers.Example topics include:

• industry best practices
• tech hiring trends & updates
• hiring biases and information for recruiters
• diversity and inclusion
• coding insights for developers
• personal insights/opinions on the tech hiring process to the extent that it doesn’t defame or libel

These are just some of the topic ideas you can write about. We are open to your suggestions if they meet the criteria above and serve our primary goal; to support recruiters and hiring managers in staying up to date on advanced recruiting insights, trends, and best practices.When writing your article, please keep in mind the guidelines below to ensure your article will be accepted and published.

Guidelines for the content within the article

1. We require you to send an outline for the approved topic. You can begin writing the draft once the outline is approved.

2. Submissions should be kept between 1500 – 2000 words. We use American English in our posts.

3. Formatting of the blog: The blog title should be in the Title case. All headers should be in sentence case, not title case. This means all headers should be lowercase except for the first word of the header and any proper nouns or acronyms.

Title case: A simple example would be Lord Of The Flies, where the first letter in each word is capitalized.

Sentence case: A simple example would be Lord of the flies, where only the first letter in the first word is capitalized.

4. Tone of voice: You must write in second-person, not first-person. This means the content should be written in the “you/your” voice, not the “I/me/my/mine” voice. The article must remain completely non-promotional. Additionally, we prefer an informal, conversational tone. Use contractions and list out all acronyms you write.

5. Readability: Please ensure no paragraph is longer than 4 sentences. Use short sentences and keep the sentence length to less than 20 words. Write in Active voice.

6. Please run a thorough Grammarly check and make sure the score is above 95.

7. Please provide a meta description of 140-160 characters explaining your article.8. How to email your guest post to us:

• The completed post must be a Google doc
• Send your posts to blog@hackerearth.com

9. The blog post/article must be your own original work that has not been published on any other website, forum, chat, or social media network.10. Plagiarism or copyright infringement is not permitted. When quoting others, please make sure to cite your source properly.11. All blog posts are reviewed and approved by HackerEarth before posting. HackerEarth reserves the right to edit blog posts where necessary.12. All content must be completely vendor-neutral. If a blog post submission is inappropriate or needs improvements, a HackerEarth representative will let you know and offer suggestions so that it may be published later.

Guidelines for SEO

13. The primary keyword should have a 1000 monthly search volume & 5 secondary keywords must have a 500 monthly search volume, which must be shared along with the outline.14. We accept 2 external links (do-follow) + 1 external link (no-follow) within the article. Links to any third-party site must be relevant to the topic and approved by HackerEarth.15. The target external link should have more than 30 DA and 40 DR.16. Anchor text for backlinks should not be related to our core business keywords.17. Links should not be in the first paragraph of the blog article.18. The target URL must be a blog article, product pages for the target URL are not allowed.19. All search engine optimization ("SEO") information, such as anchor text or alt tags, will be reviewed and subject to inclusion at the discretion of HackerEarth.

Guidelines for Author Bio

20. [IMPORTANT] Blog post writers may submit a short bio statement (no more than 50 words). Please also send in a square headshot (at least 200x200) to be used on your profile.21. Blog post writers will be allowed to have one link to their website and one link to their social profile within the author acknowledgment.

Guidelines for distribution on social media

22. We ask that you ensure to share the guest article on all relevant social media platforms like LinkedIn, Instagram, and Twitter. Post that, we will do the same on our official company social media.23. Additionally, we can discuss a newsletter swap if you have a newsletter with a sizeable number of subscribers.

Additional guidelines for the overall collaboration

24. Once the post has been submitted to HackerEarth, you may not publish it anywhere online, in part or in whole, including your own website or blog, without the consent of HackerEarth.25. HackerEarth will share and promote the blog post but does not guarantee any site or audience reach.26. If HackerEarth uses your guest post, you may promote it on your own website, Facebook, Twitter, or other social media forums. Promoting does not mean you post the entire article on these forums. You may include a link to your guest post and a short explanation of the article.27. Posts will acknowledge your authorship but will be the property of HackerEarth.28. Affiliate links shall not be included in guest post submissions. HackerEarth reserves the right to add its own affiliate links where appropriate.29. Excessive links or links that appear to be affiliated or spam-related will be removed at the discretion of HackerEarth.30. We do not pay for submissions. If you decide to submit a post to our site, you do so with the knowledge that you shall not be entitled to any compensation for writing the post or for any other compensation related to the post.31. HackerEarth reserves the right to refuse publication or remove a blog post without prior notice to the blog post writer.32. By providing a blog post to HackerEarth, you agree that you are in no way becoming a part of the website or company, nor shall you hold yourself out to be a member of the HackerEarth website or company.33. We expect to receive all submissions on time. If you miss your deadline, your post will not be published. If you need an extension to your deadline, please let us know ahead of time.

In 2011, Lucy Zhang, Ben Davenport and Jon Perlow joined Facebook and started building the Facebook messenger. A major hurdle in their endeavor was long latency when sending a message. The method that they were using to send messages was reliable but slow. They were also able to optimize it to a certain extent. A few weeks before the launch, they explored the Messaging Queuing Telemetry Transport (MQTT) protocol. With the help of MQTT, Lucy Zhang and team were able to establish and maintain a persistent connection with the Facebook servers without reducing the battery life.

So, what is MQTT protocol?

Created in 1999 by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom, MQTT is a lightweight messaging protocol on top of TCP/IP protocol. MQTT is designed for constrained devices (devices with low memory and network bandwidth) and wireless networks with varying levels of latency due to unreliable connection.

MQTT protocol is a client-server, publisher/subscriber, open, and light-weight messaging transport protocol. At the heart of MQTT is the central communication point known as MQTT broker. It is responsible for dispersing messages to rightful clients.

Each client which publishes a message to the MQTT broker includes the routing information, known as topic. Clients may subscribe to multiple topics and broker all the messages published matching the topic. The clients don't have to know each other to receive information; they just have to subscribe to relevant topics.

For instance, imagine a simple network of three clients, i.e A, B and C, where each is connected to a broker via a TCP connection. Client-B and Client-C subscribe to topic: temperature.

Client-A publishes 34.5 for topic temperature. The broker identifies this and forwards this message to all the subscribers, which in this case are Client-B and Client-C.

The publisher-subscriber architecture of MQTT makes it a highly scalable solution, without creating dependencies between data producers and consumers.

Message format of MQTT protocol

All the messages of MQTT have a small code footprint, hence it is popular as a lightweight messaging protocol. Each MQTT message consists of the following:

• Fixed header (2 bytes)
• Optional variable header
• Message payload (<= 256MB)
• Quality of Service (QoS) level

MQTT supports one-to-one, one-to-many, and many-to-many communication.

By lowering the amount of data transmitted, MQTT makes itself a perfect protocol for constrained IoT devices.

Message payloads are encoded in binary. In an open network where the recipient is from a different manufacturer will face issues decoding it as there is no information of how message payload is encoded.

Quality of Service (QoS) level for MQTT protocol

The quality of service levels determines how the content is managed. MQTT uses three different QoS levels. It is important to choose the right QoS level for every message because it determines how the client and server communicate to deliver the message. The QoS levels of MQTT are as follows:

• QoS 0 : Messages delivered per the best efforts of the operating environment, but message loss can occur
• QoS 1 : Messages delivery assured but duplicates can be created
• QoS 2 : Message to deliver exactly once

MQTT provides us with an option to set the appropriate QoS level, but remember, higher the QoS, lower the performance.

Security of MQTT protocol

MQTT allows you to pass username and password as an MQTT packet. Encryption of a message across the network can be handled independently of MQTT with Secure Sockets Layer (SSL). It has a minimal authentication feature built in. Username and password are sent as clear text. To make it secure, Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) must be employed, but SSL/TLS is not a lightweight protocol.

Many industry experts believe MQTT will play a major role in IoT by contributing to fields such as inventory tracking, and medical IoT..