Talk:Smoke testing (mechanical)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Software usage (0)[edit]

It would be really great if someone knowlegdable could add to the definition for the computer programming context which is not there yet. —The preceding unsigned comment was added by Dykstranet (talkcontribs) , and edited by 206.213.251.31

Software usage[edit]

Hi there; I'm not familiar with "Smoke testing" although many people in the Open Source programming movement seem to use it. It sounds like it might be the same thing as "Regression testing" combined with "Integration testing". What do you think? OrangUtanUK 12:18, 10 August 2006 (UTC)[reply]

No, the two kinds of testing you have mentioned are different from Smoke testing. The idea behind Smoke test is that it's a basic quick test - which would show up major problems but is not normally as exhaustive as "real" testing. Regression testing checks whether known fixed bugs have reappeared. Integration testing checks that individual modules work after being put together (i.e. without re-testing the functionality covered by individual module test, aka unit test). It may help if you think of the electrical engineering smoke test - plugging in the system and seeing no smoke tells you that it's not so broken that it burns up, but doesn't really verify whether the circuit actually works. --Romanski 19:27, 15 August 2006 (UTC)[reply]
Smoke testing is the same as load testing. A considerable load, created by the maximum number of simulated users, or database connections are created in order to "hammer" the software with the a large load. It's an effort to make the software breakdown/lockup/freeze or "smoke", as in "go up in smoke" (burn). If I was going to smoke test a server or a server application, I would attach a test harness (application) like Load Runner and run a series of tests overnight or over a weekend, and check on the server in the morning and see how the tests went. I've seen software testers run Microsoft Mail Storm (discontinued) on mail servers to see how they would react to millions of emails over a period of hours. I would consider this a smoke test.

Brianjester (talk) 17:25, 23 March 2012 (UTC)[reply]

No you're just flat-out wrong. They are not even close to the same. --Walter Görlitz (talk) 19:18, 23 March 2012 (UTC)[reply]
I agree with you that smoke testing and load testing are different. However, it might help to explain why they're different (which I will do for you). Smoke testing is supposed to be VERY quick (minutes or even seconds) so you can move the build into further testing. It's basically saying, "The application starts and appears to be working." A smoke test on a web server would involve booting the server and opening a browser to make sure the home page loads. That's about it.
A load test would simulate typical user activity, including anticipated peaks, to ensure it works in the field as long as the user stays within spec. What your describing is actually a stress test, which is more extreme than a load test and is usually used to find a failure point for documentation purposes (or possibly to raise the limit in the spec to reflect reality). The difference between a load test and a stress test is that a failure in a load test usually requires a fix since the failure is within spec. A failure in a stress test usually doesn't since it's an extreme use case that falls outside of spec. Twhoffman (talk) 17:55, 10 January 2013 (UTC)[reply]

I'm familiar with the use of terms, but I think of this usage of terms is a passing fad. I don't think there is a canonical term for this type of test. Also, the claim that it is cost-effective is an opinion. Microsoft is not the only authority. ISO might be a more neutral source. I didn't find a canonical term there for 'smoke testing'. Dagostinelli (talk) 20:21, 5 January 2010 (UTC)[reply]

I doubt it's a "passing fad." When I first started doing SQA (about twenty years ago), we had a "smoke test" that would quickly test a build to make sure it's ready to move into testing. If it's been around since then, it's going to be around for awhile.
It is cost-effective since it's a simple test that costs next to nothing to add to an automation suite. Imagine having an automated BVT with 500 test cases in it. Each test case has a timeout of 60 seconds. If the build doesn't even run, the BVT will happily plug along and attempt each use case. 500 minutes later, you get the report stating that every single feature failed. The next morning, you see the report, load the build manually, see that it doesn't even start, and send it back to development. You've just wasted a day of testing (or more if your development team is in a different time zone).
On the other hand, if the BVT first runs a smoke test and sees a failure, it aborts. A minute later, you have a report stating the build is unusable and development gets instant feedback. Twhoffman (talk) 18:20, 10 January 2013 (UTC)[reply]

Plumbing with electronics and software?[edit]

Does it make any sense to have the plumbing article included with the electronics and software articles? This sounds like really there should be two articles: plumbing smoke tests and electronics smoke tests, with the latter including a short note on the software usage. —The preceding unsigned comment was added by 82.193.2.136 (talkcontribs) .

Speaking as an electrical engineer/software engineer and a homeowner who has done some plumbing, I'd say that the concept of the "smoke test" is sufficiently general to be discussed the way the article is doing it today; I wouldn't support the splitting of the article.
Atlant 13:57, 27 November 2006 (UTC)[reply]
The articles should be split. There are no general statements made about "smoke testing" that apply to smoke testing that cannot apply to almost any kind of "testing". I.e. there is almost nothing in common with electrical, software and woodwind smoke testing other than the name. Woodwind and plumbing (and automotive) are the only ones that actually use the same methodology and can have general statements made. This should be split into at least 3 articles. —Pengo 12:28, 4 February 2008 (UTC)[reply]
I don't think any purpose would be served by splitting the article. The software usage is arguably derived from all the others (though mostly electronics).  Randall Bart   Talk  19:51, 5 February 2008 (UTC)[reply]


I agree in that the concept of "smoke testing" is general enough to be used also for quick testing of electronics and software products even if there is no actual smoke involved (just as the metaphor of "bug" is applied to software errors).

I wonder about the following sentence: "In electronics, a smoke test is the first time a circuit is attached to power, which will sometimes produce actual smoke if a design or wiring mistake has been made." Is really the fact that sometimes a smoke test of an electronic device produce actual smoke part of the reason why the test is called "smoke test", or it is just a coincidence?

I am an electronics engineer, designing systems of less then 1 watt. Even 0.5 watt can already produce this smoke with small-sized resistors. So 30watts is not required. Placing the variac in series can even make problems worse in case of electronics... —Preceding unsigned comment added by 81.207.67.97 (talk) 20:02, 27 September 2008 (UTC)[reply]

--Dhinojosa (talk) 17:52, 30 July 2008 (UTC)[reply]

Splitting the article would help to categorize it better. 167.107.191.217 (talk) 21:18, 20 January 2010 (UTC)[reply]

Article cleanup[edit]

I merged the list of short descriptions for 'smoke tests' in various fields into the longer description of each field, and put all of the descriptions into H3 headers. Hopefully this helps us have a more clear and understandable intro section, and makes the article easier to read. I have also added and cleaned up the references. Since the term 'smoke test' originates with electronics and hardware testing I have moved that section to the top. Feedback is welcome. --Culix (talk) 21:15, 20 November 2010 (UTC)[reply]

Proposal: merge BVT into Smoke Test[edit]

Both Microsoft's MSDN article "How to: Configure and Run Build Verification Tests (BVTs)" and the book "Lessons Learned in Software Testing" say that smoke tests are the same thing as Build Verification Tests. I suppose you could argue that BVTs might test more broadly and have more scope. But since we have two references from good sources I propose we merge the article Build_verification_test into this article on smoke testing.

Agree or disagree? I'll leave this proposal up for a few days for feedback. --Culix (talk) 21:18, 20 November 2010 (UTC)[reply]

  • 'Support The other article should not have been created. Redirect it here. --Walter Görlitz (talk) 21:39, 20 November 2010 (UTC)[reply]
  • Disagree The level of detail about software build testing in this article is about right. But there could be much more detail in the other one. Leaving them separate gives the other one room to grow. Stevage 05:12, 5 October 2011 (UTC)[reply]
Comment: Room to grow? It's the same thing as a smoke test. There is no room to grow. --Walter Görlitz (talk) 05:23, 5 October 2011 (UTC)[reply]
  • Disagree — Preceding unsigned comment added by Ashleshakadam1 (talkcontribs) 15:05, 23 February 2012 (UTC)[reply]
  • Disagree The Microsoft article doesn't even contain the word "smoke," let alone the phrase "smoke test." The only way that you can say the MS article says that BVT is the same as smoke testing is by coming to that conclusion after reading it, which is original research. As such, you can't consider it a source to support your opinion. Besides that, they're not the same despite many claims that they are. If you look at the history of the phrase, a smoke test is more of a test case than a testing method. A good automated BVT will run a quick "smoke test" to make sure the application actually starts. If it fails, the entire BVT is aborted since there's no way to test the remaining cases. Without a smoke test, it will attempt to run all test cases, wasting precious time (consider having 100 test cases, each taking at least 60 seconds to timeout and fail). Of course, a manual BVT won't need a smoke test since the tester won't try the test cases if it doesn't even load (unless you're dealing with a test monkey who goes through the list anyway). Twhoffman (talk) 18:15, 10 January 2013 (UTC)[reply]

Not functional?[edit]

My personal understanding is that while the article calls smoke tests a type of "functional testing", in fact, smoke tests are generic in nature and not focused on the functionality itself. Therefore, the classification "functional test" is probably misleading to downright wrong. A BVT may be too narrow, as a smoke test might include parameters of the installation which are not part of the build itself. Example: Environment parameters, interface accessibility etc. 193.254.155.48 (talk) 11:26, 18 February 2011 (UTC)[reply]

This is a distinction between functional testing vs. non-functional testing. I don't have any idea what you're talking about. --Walter Görlitz (talk) 14:54, 18 February 2011 (UTC)[reply]

Plumbing usage is very, very old[edit]

In searching Google Books for the phrase "smoke test", there are some early 20th and even late 19th century references, clearly in a plumbing context. For example. I think there's a strong possibility that someone in early electronics development was familiar with this usage and made up a joke about letting smoke out in an electronics context. --Rpresser 23:24, 17 June 2011 (UTC)[reply]

The first literature example I came across was in Sherlock Holmes, A Scandal in Bohemia, when Holmes took, "a long cigar-shaped roll from his pocket. 'It is an ordinary plumber's smoke-rocket, fitted with a cap at either end to make it self-lighting.'" Brianjester (talk) 17:18, 23 March 2012 (UTC)[reply]

Smoke testing in software engineering[edit]

I've just undone your undos, because the article smoke testing describes "physical tests made to closed systems of pipes to test for leaks". Even though the names are the same, smoke testing in software usually does not involve actual smoke, so there's no need to cover it in the smoke testing article. Qwertyus (talk) 22:19, 12 March 2013 (UTC)[reply]

You'll have to tell that to the industry then. Google "Smoke test", with the quotes. The majority of the links are related to software development. The majority of the software testing industry calls it a smoke test while a minority call it a "build verification test". I was at a conference in Portland, Oregon in 1999 where the latter term was used and the presenter had to say, "it's like a smoke test" so the attendees would understand. They're not the same thing. Unless you can find a reference to state that they are then these two should remain as is. See WP:BRD. You were bold, I reverted and now it's time to discuss. Walter Görlitz (talk) 22:31, 12 March 2013 (UTC)[reply]
Further. StickyMinds.com is the one of the best sources for testing and software development information. Site searches show that the industry uses the term Smoke Test as opposed to Build Verification Test.
So I'm not sure why you're insisting on moving the term out of here to an article that isn't related. If anything, that article should be redirecting here. Walter Görlitz (talk) 22:42, 12 March 2013 (UTC)[reply]
As you already indicate yourself, the two are related. My point is that the information about smoke testing in software does not belong in this page, which is primarily about running smoke through pipes.
The reasonable thing to do is rename build verification test to smoke testing (software) (maybe rename this article as well and introduce a DP), move the SE-related stuff there and describe BVT as a special case of smoke testing. Qwertyus (talk) 22:48, 12 March 2013 (UTC)[reply]
Your point is wrong though. It's not more correct that it's the same process in electronics as in plumbing. Case in point, in electronics, smoke isn't blown into the system as it is in plumbing. So if we move the one out, we have to move both out. The article has survived for five years without having the ideas separated. I'm not sure why it needs to happen now either. Walter Görlitz (talk) 22:57, 12 March 2013 (UTC)[reply]
That doesn't contradict my point at all; I considered moving the electronics section out as well, but was too lazy to do it. As for Wikipedia articles surviving for five years despite flaws, there have been worse examples of that. I was looking for an article about smoke testing in software and had to plow through a lot of unrelated info before finally finding the info I wanted, and I wanted that fixed. Qwertyus (talk) 23:02, 12 March 2013 (UTC)[reply]

I would agree that this article should be disambiguated. It would be nice to have a clean page for SLDC smoke testing references. [1] Marxchuck (talk) 01:59, 2 May 2013 (UTC)[reply]

I think the problem here is actually with the opening paragraph of the article. The article is actually about the concept of smoke testing, both physically and metaphorically, it's historic origins and contemporary applications. The first sentence gives the impression that the article is primarily about physically testing pipes with smoke. If that were the case then I would support software smoke testing being moved to an entirely different article. However it seems to me that the intended content of this article is broad enough to encompass at least a summary of software "smoke tests" and usage in other fields. — Preceding unsigned comment added by 210.55.2.11 (talk) 02:48, 19 August 2013 (UTC)[reply]

I agree with the IP, the article is about all uses of the term and not just pipe testing. Op47 (talk) 22:44, 19 December 2013 (UTC)[reply]
That violates WP:DICDEF. Articles are about concepts, not terms. QVVERTYVS (hm?) 01:10, 20 December 2013 (UTC)[reply]

Ok, so I've been bold again, and Walter Görlitz reverted, and now we have an article Smoke testing (software) that duplicates content from this one. Before we get into deletion wars, let me reiterate my point:

  • Smoke testing in software is different from smoke testing in other domains. No smoke is blown through any pipes.
  • The conceptual link between the various types of smoke testing is not established. This article cites a book on software testing, which gives a different etymology ("If you see smoke coming from the board, turn off the power") and adds that "Later [the original] usage seems to have been forgotten", without citing a source for that; the section "History of the term" has been tagged with {{synthesis}} for this reason since more than a year ago.
  • The fact that two concepts have the same name is no reason for them to be discussed by the same article; this is explicitly stated in WP:DICDEF#Major differences: "[homographs] are found in different articles".

I'm going to seek a third opinion. QVVERTYVS (hm?) 01:52, 20 December 2013 (UTC)[reply]

Thanks for being bold and creating such a mess.
There's really no need for having a merge discussion if you're going to ignore having the discussion.
Smoke testing in all areas is different than all the others but they are metaphorically linked to the others and there's no reason to split the articles when simply explaining that in the lede is required. Walter Görlitz (talk) 01:57, 20 December 2013 (UTC)[reply]
The "mess" can be undone easily. Just redirect Smoke testing (software) to the appropriate section and revert some of my edits.
I would love to see a reply to my point that this violates WP:DICDEF. We have separate articles for distinct and notable concepts everywhere else. QVVERTYVS (hm?) 02:11, 20 December 2013 (UTC)[reply]
The way I clean messes up is to remove the new mess not by compounding it.
You created the idea that what is needed is a dictionary definition. It's not. A simple discussion of the differences is all that is required. And don't be demanding and ask for your terms and conditions to me met. That's what hostage takers do. Walter Görlitz (talk) 02:16, 20 December 2013 (UTC)[reply]
I think you misread me. I'm saying we should not have a dictionary-like article that conflates various meanings of a term, per Wikipedia policy. All I'm asking is that you engage in discussion about this point; we can disagree all we like about personal preferences for how the smoke testing articles should be structured, but I don't think we're going to get anywhere that way. QVVERTYVS (hm?) 02:41, 20 December 2013 (UTC)[reply]
You're right. I misread that.
It's not dictionary-like to have different yet related topics in one article. It's quite encyclopedic. They're all based on the plumbing metaphor. Walter Görlitz (talk) 02:49, 20 December 2013 (UTC)[reply]
I'm not convinced of that, and there's no reference in the article to a reliable source that states this. The SW use is related to the EE use according to one source; all the rest seems to be an original synthesis. QVVERTYVS (hm?) 11:49, 20 December 2013 (UTC)[reply]
I know you're not convinced it's not dictionary-like. You've made that point clear several times yet I have managed to make it work.
Developsense is the blogging arm of respected testing authors James Bach and Michael Bolton
http://www.developsense.com/blog/2011/11/smoke-testing-vs-sanity-testing/
“Smoke testing” derives from the hardware world; if you create an electronic circuit, power it up, and smoke comes out somewhere, the smoke test has failed.
They also discuss whether smoke testing and sanity testing should be merged. And one of the other most well-respected authors, Cem Kaner, writes about the other issue on the table: should the three separate topics be mergred http://www.testingeducation.org/k04/RegressionExamples.htm Walter Görlitz (talk) 14:43, 20 December 2013 (UTC)[reply]

So now we're going to make a handful of small articles. It makes no sense. The only real outlier is the entertainment entry. Walter Görlitz (talk) 19:30, 20 December 2013 (UTC)[reply]

Split Dispute Resolution Process[edit]

Qwertyus took this issue to WP:DRN (see above). The outcome is repeated below for convenience. Op47 (talk) 10:56, 31 December 2013 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was: Resolved as an agreement was reached between two main parties while one party refused to participate and objected to the DRN process. The agreement between the two primary parties seems to have formed a strong basis for further discussion and renewed consensus on the talk page.

Smoke testing[edit]

Have you discussed this on a talk page?

Yes, I have discussed this issue on a talk page already.

Location of dispute

Users involved

Dispute overview

In my opinion, the article Smoke testing violates WP:DICDEF by merging various meanings of a term into a single article, using OR as the means to glue them together. I twice tried to split the one I care most about from the article, so as to have an article Smoke testing (software) that does not bury this meaning of "smoke testing" deep down in unrelated content, only to have my edits reverted both times.

Have you tried to resolve this previously?

Discussion on the talk page.

How do you think we can help?

I'd like an outsider to judge matters from the viewpoint of Wikipedia policies and conventions: are separate articles warranted, or not?

Summary of dispute by Walter Görlitz[edit]

The editor placed a merge discussion and then removed the section without consensus. The topic does not have enough weight to stand on its own and it doesn't make sense to split the article. Walter Görlitz (talk) 02:14, 20 December 2013 (UTC)[reply]

Summary of dispute by Op47[edit]

Please keep it brief - less than 2000 characters if possible, it helps us help you quicker.

I came to this article because I try to keep the split tag backlog under control. In this case, I found a discussion that had apparantly gone cold. I saw no compelling reason to split the article. My previous experience in these situations is it is best not to split and hence thought the best action would be to remove the tags. Obviously that won't work. There are a number if factors to consider:

1) The lede seems to imply concensus that both the mechanical and electrical use is to be included in the article by concensus.
2) The split tag chosen is probably not the best way to go anyway. We have a number of definitions of smoke test. If the article is to be split up then it should form a disambiguation page and the content of the article be split into the sub pages of the disambiguation page.
3) The elctrical and software use of the term are very small and possibly would not make viable separate articles. WP:IAR needs to be considered.

Op47 (talk) 19:09, 20 December 2013 (UTC)[reply]

Smoke testing[edit]

I'm opening this case for discussion. First I thank all of the parties for their willingness to participate in a moderated discussion of a contentious issue. Secondly, I thank you in advance for keeping this discussion strictly on content and avoiding comments about a contributor or their behavior.
The scope of this case is whether or not one or more of the several meanings associated with the phrase "smoke testing" should be spun off into a stand alone article. The filing party, User:Qwertyus favors this approach, however, User:Op47 and User:Walter Görlitz oppose a split of the article. Is that a fair assessment of the situation so far?--KeithbobTalk 20:50, 21 December 2013 (UTC)[reply]
For the purposes of this discussion, that is approximately true. I think though I am more opposed to Qwertyus' proposed method of splitting than splitting per se. Op47 (talk) 22:42, 21 December 2013 (UTC)[reply]
Thanks User:Op47. Where is the common ground with you and Qwertyus? What method of splitting would you support?--KeithbobTalk 00:09, 22 December 2013 (UTC)[reply]
If the article were to split I would favour a hierarchy along the lines:


Smoke testing -- A disambiguation page
Smoke testing (mechanical) -- describing the use of smoke to test pipes
Smoke testing (electronics) -- looking for smoke on first power up
Smoke testing (software) -- testing of major functions before formal testing
Smoke testing (theatre) -- testing smoke machines


This is how similar situations have been resolved previously. My reservation is that the existing material for the last 3 articles is not well developed and (initially) we may have 3 small and rather silly articles. On the other hand, Qwertyus is correct that on Wikipedia we do tend to have an article per concept rather than per term.
To clarify I will describe my understanding of Qwertius proposal using similar notation:


Smoke testing -- describing the use of smoke to test pipes
Smoke testing (disambiguation) -- A disambiguation page
Smoke testing (electronics) -- looking for smoke on first power up
Smoke testing (software) -- testing of major functions before formal testing
Smoke testing (theatre) -- testing smoke machines


It should be noted that (using the nomenclature of my proposal) Smoke testing (mechanical) and Smoke testing (theatre) are formal recognised processes in those fields, i.e. an engineer in thos fields would say to their bosses "I am going to do a smoke test" and would be understood. Whereas Smoke testing (electronics) is a colloquial term for when equipment unexpectedly fails (at least where I work) and Smoke testing (software) is another way of describing the free play a tester may undertake to provide confidence that some software actually works before undertaking the formal test (again where I work, the formal phase may take several weeks). I am sorry it was long winded, but I do hope it helps. Op47 (talk) 00:47, 22 December 2013 (UTC)[reply]
User:Qwertyus, Op47's proposal allows each concept to have its own article as long as no one concept takes claim for the main term. Is this acceptable to you? Comments? --KeithbobTalk 18:18, 22 December 2013 (UTC)[reply]
I don't even mind promoting the meaning in mechanics to the "main" meaning as it seems to be the oldest, so I'm actually fine with both options that User:Op47 sketches. My main concern is that the other uses are really unrelated to the use in mechanics, with only the electronics and software smoke testing being related to each other according to cited sources (though I would like to have a separate article about software testing to disentangle the category structure and make linking to it easier). I doubt whether "Smoke testing (theatre)" could stand on its own given the limited amount of material, but maybe it can be a standalone entry in a DAB page, without a link? QVVERTYVS (hm?) 17:05, 23 December 2013 (UTC)[reply]

Correct me if I'm wrong but I think Op47 is saying he would object to any of the definitions of Smoke Testing being used as the primary search term. He/she would like a search for the term Smoke Testing to go directly to a disambiguation (dab) page where the reader could choose which meaning they would like to learn about. But if you are OK with either of his suggestions (one of which has the term going directly to the dab page) then I think we have the basis for a compromise. One concern has been that not all of the meanings for Smoke Testing has the notability etc for a stand alone article. However, that is not a problem as dab page links can either direct the reader to a stand alone article or to a specific section of a general article on Smoke Testing. So... those definitions that can support a stand alone article can have one and those that need to remain as part of combination article can do so. Either way they will all be listed on the dab page called Smoke Testing with entries like this:

  • Smoke testing -- A disambiguation page
  • Smoke testing (mechanical) -- describing the use of smoke to test pipes
  • Smoke testing (electronics) -- looking for smoke on first power up
  • Smoke testing (software) -- testing of major functions before formal testing
  • Smoke testing (theatre) -- testing smoke machines

Does this make sense? Is it agreeable? --KeithbobTalk 19:21, 24 December 2013 (UTC)[reply]

A dispute resolution is no place to discuss splitting into ridiculously small articles. The discussion here should not assume support for a split. Walter Görlitz (talk) 21:25, 26 December 2013 (UTC)[reply]
This noticeboard is for the discussion of content disputes in a moderated setting. There are no limitations as to what may or may not be discussed here (as long as its content related). At the same time, agreements or compromises made at noticeboards such as this one are not binding and may be superseded by future consensus on the talk page.--KeithbobTalk 02:06, 27 December 2013 (UTC)[reply]
This discussion is to resolve the dispute not to discuss content. If you apply any content changes from this discussion, you will be starting another dispute because the discussion is in a hidden corner of Wikipedia and those who have an interest in discussing the topic are not involved. Walter Görlitz (talk) 19:02, 28 December 2013 (UTC)[reply]

Re Keithbob's comment on 24 December. Yes you have it correct. My 1st "proposal" is what I am proposing. My 2nd is what I thought Qwertyus was proposing. Clearly I got the wrong end of the stick somewhere. It would appear that Qwertyus and I are in agreement. I suppose we will now have to persuade Walter Görlitz. Your proposal to split the article and yet not have small articles seems ok in principle, I guess we will have to find suitable articles to split to. For info, I am a he. Op47 (talk) 00:33, 28 December 2013 (UTC)[reply]

OK so it appears we have a general agreement between Qwertyus and Op47 regarding splitting the article. I think this could provide a good foundation for gaining further consensus on the talk page. If there is no resolution amongst that group of interested editors, including Walter Gorlitz, then I would suggest you start an RfC on the talk page and ask for input from uninvolved editors to create a wider consensus. I'm glad this DRN filing has created some progress. I'm thinking of closing this case now, unless there are further comments. --KeithbobTalk 01:13, 29 December 2013 (UTC)[reply]


Keithbob then closed the discussion as follows:
Resolved as an agreement was reached between two main parties while one party refused to participate and objected to the DRN process. The agreement between the two primary parties seems to have formed a strong basis for further discussion and renewed consensus on the talk page. KeithbobTalk 23:26, 29 December 2013 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Keithbob misconstrued my involvement. I did not refuse to participate only that the location of the discussion was the wrong place to attempt to achieve an consensus for this unnecessary change. Walter Görlitz (talk) 16:58, 31 December 2013 (UTC)[reply]

Understood. TBH I would have opened an RfC in any case. Please have your say there. Op47 (talk) 18:16, 31 December 2013 (UTC)[reply]

RfC: Split the article and form a disambiguation page[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Should this article be converted into a disambiguation page and split into the following articles:

Smoke testing -- A disambiguation page
Smoke testing (mechanical) -- describing the use of smoke to test pipes
Smoke testing (electronics) -- looking for smoke on first power up
Smoke testing (software) -- testing of major functions before formal testing
Smoke testing (theatre) -- testing smoke machines


Op47 (talk) 10:55, 31 December 2013 (UTC)[reply]

Survey[edit]

Please only place votes in this section. Any discussion in the Threaded discussion section.

  • Support Without necessarily arguing about the precise split, I think a split of that nature would be beneficial. My main reservation is about the current status of the concept of the disambiguation page. The AR attitude to limiting disambiguation pages to lists should be limited to cases where what is wanted is a list and nothing but. (Eg names of people. The user of a list of names of people usually does not need a covering article though in some cases even there, there could be an article on one or more families of that name, thigh that could be a slightly different matter) When there is a topic relevant to separate subsets of which the members or various subsets deserve separate articles, then IMAO what amounts to the disambiguation page should be a disambiguation article, concisely indicating the nature of each article and their interrelationships as well as simply their links. — Preceding unsigned comment added by JonRichfield (talkcontribs)
  • Support with the reservation that Smoke testing (theater) may not have enough content to warrant a separate article, so it might end up as a single entry in the dab page. QVVERTYVS (hm?) 12:26, 3 January 2014 (UTC)[reply]
  • Support splitting conceptually and mechanistically distinct subjects, as illustrated in the proposal. -- Scray (talk) 03:03, 8 January 2014 (UTC)[reply]
  • Oppose, though not entirely. Splitting an article requires all target articles to exhibit notability evidence and have sufficient size. None of these two are the case here. In addition, this proposal involving disambiguation is only appropriate when the subjects are only similar in title. This is not the case either because most of the tests in this article involve using the actual smoke. The only exception is software testing, which I am not against treating it appropriately. Best regards, Codename Lisa (talk) 00:29, 15 January 2014 (UTC)[reply]
  • Oppose. I do not believe that the electronics, software and theater types of smoke testing merit their own articles. -- Dan Griscom (talk) 02:07, 15 January 2014 (UTC)[reply]
  • Support With the same name, but conceptually different, the varieties of smoke testing need disambiguation, whether in a DAB page or in hatnotes. I would not hold this proposal hostage to guesses about notability; let the various articles grow or die on their own. --Mark viking (talk) 00:26, 20 January 2014 (UTC)[reply]

I believe that is concensus to make this page a disambiguation. The concerns about small articles is noted. I'll do my best, but will acknowlege that there will be some tweaking required. Op47 (talk) 20:37, 31 January 2014 (UTC)[reply]

I too agree that consensus has been reached even though I am in opposition to it. Walter Görlitz (talk) 20:50, 31 January 2014 (UTC)[reply]

Threaded discussion[edit]

I'm unsure about the notability of a number of these proposed articles. They perhaps deserve definitions in a dictionary, but is there enough to say about them that is encyclopedic? For instance:

None of these has much depth to them, AFAIK. The only one which might would be the Smoke testing (mechanical), which could deal with supplying smoke, preventing loss of smoke, detecting the leaking smoke, etc.

My preference would be to have this article be explicitly about mechanical smoke testing, where you supply smoke into an enclosed space and then watch for unexpected leaks of smoke. Then add links to Fog machine and Software testing in a header. -- Dan Griscom (talk) 03:30, 9 January 2014 (UTC)[reply]

If a software article is split off, I intend to merge content in from other articles that discuss the concept: candidates include Build verification test, Daily build. QVVERTYVS (hm?) 10:47, 9 January 2014 (UTC)[reply]
I wouldn't choose that, myself. I'd try to end up with a clear, robust, coherent set of articles; this sounds like you'd end up with a fairly random set of information in this new article, much or all of which could be made a coherent part of Software testing.
The same with Smoke testing (theater); this is an extremely specific situation that doesn't merit a lot of discussion, and could be a clear section within Fog machine.
All else being the same, fewer mid-sized articles is better than many tiny articles. I understand that I'm a latecomer to this discussion, albeit invited. If the consensus is clearly otherwise then fine. But please: try not to atomize the WP article space. -- Dan Griscom (talk) 14:13, 9 January 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

An alternative to the above RfC: move non-smoke-related content to existing articles[edit]

It's been a few days with no further comment on the RfC. At the risk of throwing yet more chaos into this process, I'd like to make the preferences I into a concrete proposal:

  • Move all software-related testing information to Software testing#Smoke and sanity testing. (I'd suggest merging Build verification test into the same section, but that's a discussion for another day.)
  • Move all electronics-related smoke testing information elsewhere. I haven't found a suitable destination, but frankly I'd be fine with it going into the bit bucket. Just because it's a common term doesn't mean that it is notable (what encyclopedic information would the article have? "keep a fire extinguisher handy"?)
  • Move all theater smoke testing information into Fog machine, probably as part of a new section on the use of such machines.
  • Add the following header to the remaining Smoke testing article: This article is about the use of smoke in an enclosed area to trace airflow and to detect leaks. For software smoke testing, see Software testing. For testing smoke machines in a theater, see Fog machine.

If there are objections, I'll bow out, as I don't have anything else to offer. Otherwise, I'll make the changes myself in a few weeks. -- Dan Griscom (talk) 03:02, 14 January 2014 (UTC)[reply]

The default time for an RfC is 30 days. It may be that every one who has an opinion has stated their opinion, but we should allow for latecomers, or for someone independent to close early. To my mind, I don't think things have stalled. If you feel strongly that we are going in the wrong direction then the right thing to do is to oppose in the survey section and state why. If there is clear support then no doubt the closing admin will say so. Op47 (talk) 22:51, 14 January 2014 (UTC)[reply]
Thanks: you're right on the money. I'll do as you suggest. (No hurry.) -- Dan Griscom (talk) 02:05, 15 January 2014 (UTC)[reply]