View this email in your browser
 
Sponsored by MABL -Test Every Release, At Scale.

Testing for Failure: You're Doing it All Wrong

 
        


Despite the scorn that the tech community harbors for Thomas Alva Edison (Viva la Tesla), there's a wonderful quote attributed to him:
 

"I have not failed. I've just found 10,000 ways that won't work."


Software developers and Entrepreneurs need to ingrain this mentality within themselves. Let's stop cringing every time we discover a bug.

In our own case, at Hacker Noon, we recently stopped using Medium as our CMS and decided to develop our own. And believe us when we say this - it's been three months now and we still test for failure.

Every Day. Monday through Sunday.

Do we find bugs that just about break our hearts - Almost every week.

Do we face brickbats on Twitter - almost daily.

But, we come out better, battle-hardened and more agile, each passing day.

Try this for a month - Test for Failure Every Day.

If it helps you improve, let us know by tagging us on Twitter. It'll make us happy.

Thus, in the spirit of Testing for Failure, we've compiled our best stories on this subject. There are ways to even automate the entire process.

For example, MABL, our newsletter sponsor this week, has complete solutions catering to just this - Test every release, at scale, on a single platform, with no infrastructure to manage.

Without further ado, let's get to the stories.

JavaScript Testing Tools Survey 2018: The Results Are In

I recently ran a survey to learn more about developer preferences and experiences with JavaScript testing. The tyranny of choice, typical for the whole ecosystem, was quite obvious. With 683 survey responses, there were more than fifty distinct entries for test automation frameworks.

With such a smorgasbord, nobody has the time to investigate all choices. Yet, such a big menu also begs the question whether there’s something much better out there than the tools we’re using at the moment. So how should people choose the right tools for an ecosystem that changes so frequently?

Read full article or {TWEET THIS} by Gojko Adzic
 

Common Excuses Why Developers Don’t Test Their Software

Once upon a time I hated testing software. It wasn’t important to me. I didn’t see the purpose. It seemed like a huge waste of everybody’s time and money.

Throughout my career I was never taught how, or why, I should be testing my software. I made lots of excuses for not wanting to learn. I spoke with many developers who also made excuses for not wanting to learn. They still make the same excuses today. I eventually learned, they didn’t.

Throughout my time working with others I’ve came across many different opposing views to software testing..


Read full article or {TWEET THIS} by James Jeffery
 

3 Things Your Manager Should Know About You As Tester

During the years I have dealt with many typologies of managers. From ones seeing the testing activity as part of the development process, understanding what software testing is and what is not to the ones seeing software testing as some additional thing to do after you finish the development, some kind of checking that the door is closed.

You can easily spot which ones I prefer, don’t you? But we don’t have the possibility to choose, not every time, that’s why we need to adapt.

Read full article or {TWEET THIS} by Mihaela Sfat
 

The Guilt of Not Testing Everything

The guilt comes when I say things like: “I’ve tested the new feature”, or “the tests are passing”. In the back of my mind, I know there are hundreds of thousands of combinations I didn’t test for.

We must give ourselves a break and remember that exhaustive testing is usually not possible. One must reconcile the cost/reward balance sheet of testing… Especially when you start thinking about negative tests.

Read full article or {TWEET THISby Joseph Jung
 

Love Selenium? It may be cheating on you

OK, so I picked a dramatic heading to get a reaction, but here’s the thing. Most of my friends from CTO down to junior developers feel that Selenium gives a good enough automation coverage and they feel comfortable pushing changes to prod if the automated tests pass. But after I bring up my points about Selenium, after about 5 minutes I see their eyes open up, their confidence take a hit and their mind start racing for solutions.

The truth is that WebDriver API is not capable of verifying half of the problems that a human can spot instantly, and even a well-coded Selenium test typically verifies less than 10% of the user interface. A passing Selenium test gives you an illusion of safety, when in reality you have to use manual testers to ensure that users don’t get shipped crap. Have I got your attention now?

Read full article or {TWEET THIS} by Michael Tomara
 

QA Engineering Roles: Skills, Tools, and Responsibilities in a Testing Team

Despite having a strong tendency towards automation testing today, some test scenarios are either more time- and cost-efficient to run manually, or they are just not possible to automate, like real user interactions. Besides that, manual testing is used as an initial step in developing automated tests.

When there’s a shortage of time, manual testing is a go-to option as it’s less about planning and more about test execution. Relying on human skills is better for usability testing. An app’s user-friendliness can be properly evaluated only by human observation — a manual test helps find UI and usability issues, which automation tests are unable to identify.

QA Engineers apply automated testing to run repetitive and regression tests after implementing frequent code changes. Automation testing is also preferred for load tests, helping to verify a system’s performance under load conditions. Although initially expenses, automation testing is much faster and less prone to errors than manual testing. Moreover, automated tests are reusable and easy to run on different machines.

Read full article or {TWEET THIS} by AltexSoft Inc
 

The Two pillars of Automated Testing

In our experience, QA is one of the slowest moving disciplines across the development landscape. This goes for both the supply side and the demand side of the market. It’s rare for new testing technology to reach the market in the first place.

And equally, it’s not so common for product teams to have the capacity, time, and will to look for new tools. This is not surprising since many QA teams have a corpus of test libraries that they can’t simply forget about.

Read full article or {TWEET THIS} by Iflexion
 

GraphQL & Jest: snapshot testing

How it works is pretty simple: I send a query to a graphql server as it is meant to work but with only one difference — I mock resolvers function. I specify what data I want to get for a query. Basically, it’s a data’s snapshot I created manually. If somebody changes something in the schema the graphql server is going to return a different response from what’s written inside a mock.

Let’s write some code. It’s going to be javascript but you can apply the same idea to any language you prefer.

I decided to not run any server locally, I use an express middleware, so for me, it’s just a function which takes schema, request, response and set json object in the response object a.k.a unit test. For the same query input, we always expect the same output.


Read full article or {TWEET THIS} by Ven Korolyov
 

11 Reasons Why Software Testing Has a Better Future Than Development

There has always been a clash between the two prevalent roads in software science – software development and software testing. People are often left confused while selecting either of them for their career.

The reason; there are many misconceptions based on both these career options that over weigh one another.

Generally, software testing is overlooked as compared to software development. Many college dropouts and freshers consider it as an unworthy job and do not value it as the job of a software developer. Well, this confusion would not last long if you get to know that software testing is just another world if mastered.

Read full article or {TWEET THIS} by Lorenzo Gutierrez
 

It’s (been) Time to Use Machine Learning to Fix End to End Testing

As Sundar Pichai discussed at IO 2017, Google is revamping all of its products to be AI first — given the advancements in computer vision, voice recognition, and machine learning. We’ve already seen the advancements Google has delivered from a consumer perspective for years, from self-learning thermostats, to traffic navigation, to speech recognition.

The next step for Google is applying AI for business use cases, which it’s already doing within Google Cloud. At mabl, we agree with Google. Specifically, we believe ML could have a profound impact on improving the lives of developers, allowing them to spend more time building great products and less time on repetitive tasks.

Read full article or {TWEET THIS} by mabl
 

Have a great weekend,
Utsav from Hacker Noon 👨‍💻

Sponsored by MABL - Test Every Release, At Scale.
Want to customise what kind of emails you get from us? 

Manage your topic preferences
Twitter
Facebook
Website
Copyright © 2019 Hacker Noon. All rights reserved.

Our mailing address is:
PO Box 2206, Edwards CO, 81632, U.S.A.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.