Join us at TNW Conference 2022 for insights into the future of tech →

The heart of tech

This article was published on February 9, 2014

    Smoke-testing your apps 101: A guide for the non-techie co-founder

    Smoke-testing your apps 101: A guide for the non-techie co-founder
    Denis Duvauchelle
    Story by

    Denis Duvauchelle

    Denis Duvauchelle is the CEO and co-founder of Twoodo, the hashtag language that lets you organize anything and everything. Focus on what yo Denis Duvauchelle is the CEO and co-founder of Twoodo, the hashtag language that lets you organize anything and everything. Focus on what you really need to get done with our beautifully simple system. It's a way of life.

    Denis Duvauchelle is CEO and co-founder of Twoodo, helping you organize everything and anything using #hashtags.

    It’s doubtful that if our team collaboration startup had as many bugs as iOS7 did that the reaction would be to write a nice article on Lifehacker explaining how to solve the problems yourself.

    What an amazing achievement for a company, when you think about it! Any lesser technology company would have customers, dare I say, dropping like flies…

    iOS 7's Most Common Bugs  and How to Fix Them

    Simple bugs can be fatal to your website – especially if you are a SaaS company like we are. If a user arrives on your website and can’t carry out a simple task like log in or reset his forgotten password, you could lose that user forever.

    We learned this the hard way. Sure, having people from your team test the tool and look for bugs is important, but it’s not consistent or thorough enough. Here, we are going to introduce all you non-techies to the world of smoke tests.

    Smoke-testing was originally coined to explain how electronic engineers checked to see if their gadget worked – plug it in, and if smoke comes out…

    Wait – so how does this apply to apps?

    The importance (and cost effectiveness) of the smoke test is typically unknown to non-techie managers and co-founders. Regular smoke tests can be considered an integral part of growth hacking. It minimizes the chance that your web app or phone app will fail – and as we all know, it it only takes one fault to lose a customer forever.

    This is an introductory guide to what it is, how it can be done, resources for conducting it and examples to guide readers.

    Smoke tests exist to check basic functionalities and should be a consistent part of your testing process. This can include something as simple as “can I log in?”

    A smoke test will ensure that none of the most basic and obvious failings are left to chance. A deeper test should not be performed until you have cleared a smoke test 100 percent so that it clears the software of fundamental flaws.

    Step 1: Decide what to test

    Look at what your application is trying to achieve. What are the most obvious baby steps that are required to get there? What are the minimum vital requirements, and in what logical order can you put them in?

    Create a test suite. A test suite is when you group a set of test cases that are linked in some way (eg. link by function).

    A smoke test will not include variables, or “what ifs.” They are about yes/no answers that critically need a “yes” before you start more advanced testing (also known as “test cases”).

    Let’s take the example of creating an online forum. In order for this to work I need to:

    a) log in

    b) create a username

    c) have an avatar

    d) post a message

    e) reply to a message

    Step 2: Record in a spreadsheet

    Light smoke test

    The image above is an example from our team. You can find the template here. It’s essential to keep a record of what has and hasn’t worked – basic organization saves tons of time later on. We divided our success into pass, partial and fail.

    • Pass: everything functioned perfectly
    • Partial: you may not initially realize that an action could be subdivided even more, and part will work, part not.
    • Fail: did not work

    We described the precise action we wanted to test, and then added a brief description of how it should happen in the next column. Example:



    Post using a new team name

    Check post is added with expected headers

    Step 3: Automate the smoke test

    It is super important not to assume that once an action has passed a smoke test that it will always pass. Smoke tests allow you to constantly check that these basic functions have not been affected over time or broken down over time.

    Do not stop smoke-testing. Ever.

    When your test suite of smoke tests are at a 100 percent clearance rate, think of automating it, but do not get complacent. The recommended frequency of smoke tests is daily test if your company does development every day.

    At the absolute minimum, conduct a smoke test before every release and after every patch.

    A rule of thumb for smoke tests:

    • Minimum time: 30mins
    • Maximum time: 60mins

    In the long run, automating a smoke test is time saving, but do do it manually every now and again because the human eye can pick up on details that machines can’t.

    Resources for testing:

    After the smoke test? The Sanity Test!


    Do you have other smoke testing tips that works for you? Share them below.