<http://schema.org/articleBody>
"Denis Duvauchelle is CEO and co-founder of Twoodo, helping you organize everything and anything using #hashtags.\r\n\r\n\r\n\r\nIt\u2019s 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.\r\nWhat an amazing achievement for a company, when you think about it! Any lesser technology company would have customers, dare I say, dropping like flies\u2026\r\n\r\nSimple 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\u2019t carry out a simple task like log in or reset his forgotten password, you could lose that user forever.\r\nWe learned this the hard way. Sure, having people from your team test the tool and look for bugs is important, but it\u2019s not consistent or thorough enough. Here, we are going to introduce all you non-techies to the world of smoke tests.\r\nSmoke-testing was originally coined to explain how electronic engineers checked to see if their gadget worked - plug it in, and if smoke comes out\u2026\r\n\r\nWait - so how does this apply to apps?\r\nThe 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.\r\nThis is an introductory guide to what it is, how it can be done, resources for conducting it and examples to guide readers.\r\nSmoke tests exist to check basic functionalities and should be a consistent part of your testing process. This can include something as simple as \u201Ccan I log in?\u201D\r\nA 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.\r\n\r\nStep 1: Decide what to test\r\nLook 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?\r\nCreate 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).\r\nA smoke test will not include variables, or \u201Cwhat ifs.\u201D They are about yes/no answers that critically need a \u201Cyes\u201D before you start more advanced testing (also known as \u201Ctest cases\u201D).\r\nLet\u2019s take the example of creating an online forum. In order for this to work I need to:\r\na) log in\r\nb) create a username\r\nc) have an avatar\r\nd) post a message\r\ne) reply to a message\r\n\r\nStep 2: Record in a spreadsheet\r\n\r\nThe image above is an example from our team. You can find the template here. It\u2019s essential to keep a record of what has and hasn\u2019t worked - basic organization saves tons of time later on. We divided our success into pass, partial and fail.\r\n\r\n\r\n\tPass: everything functioned perfectly\r\n\tPartial: you may not initially realize that an action could be subdivided even more, and part will work, part not.\r\n\tFail: did not work\r\n\r\nWe described the precise action we wanted to test, and then added a brief description of how it should happen in the next column. Example:\r\n\r\n  \r\n\r\n\r\n\r\nAction\r\n\r\n\r\nExpected\r\n\r\n\r\n\r\n\r\nPost using a new team name\r\n\r\n\r\nCheck post is added with expected headers\r\n\r\n\r\n\r\n\r\n\r\nStep 3: Automate the smoke test\r\nIt 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.\r\nDo not stop smoke-testing. Ever.\r\nWhen 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.\r\nAt the absolute minimum, conduct a smoke test before every release and after every patch.\r\nA rule of thumb for smoke tests:\r\n\r\n\r\n\tMinimum time: 30mins\r\n\tMaximum time: 60mins\r\n\r\nIn 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\u2019t.\r\n\r\nResources for testing:\r\n\r\n\tTestManagement (when your company grows bigger)\r\n\tInflectra\r\n\tSeleniumHQ (Web apps)\r\n\tOur template\r\n\r\nAfter the smoke test? The Sanity Test!\r\n \r\n\r\nDo you have other smoke testing tips that works for you? Share them below."^^<http://www.w3.org/2001/XMLSchema#string>
<http://thenextweb.com/dd/2014/02/09/smoke-testing-101-guide-non-techie-co-founder/>