View on GitHub

Open Live Writer


Click to begin

5.2MB (.exe)

This is how I test

I’ve been asked about testing by someone new, so I thought going through my process would be good.

I’m testing Pull Request #117.

The first thing I did is review the pull request and make sure I know what the new feature is. I review the entire pull request each time I test.

The next thing I did was to write a test plan while I went through it. That test plan has it’s own pull request now and I pull it and go through the checklist as I go.

I make any notes when the program behaves differently then I expected.

Here’s where I get the code to test. I go to the actual pull request – this one is 117, and scroll down to the bottom of the page. You’ll see a green github icon that says “All Checks have passed” On the right is blue there is a “Show all checks”. Click that and you’ll see a AppVeyor build succeeded, and in blue “Details” on the right. Click “Details”.

An AppVeyor page opens, that has information including the application name “OpenLiveWriter”, and a short description. On the right, you will see Console Messages Tests and Artifacts. You’ll need to click on “ARTIFACTS”.

When you do, you’ll see a file name list. You need to download and run the Releases\OpenLiveWriterSetup.exe.

When you run it, you may get some messages from Windows saying that the program might not be safe, ignore them.

OpenLiveWriter should open. The first thing you should do to determine that you have the right version, look for the new feature it should be there.

Since I have already started this test, the first thing I did was to check the issue that was bothering me. It’s resolved so I’ve let a comment for the author. The next thing I’ll do is a full test of the feature.

Finally I’ll go through the app like I normally would to make sure nothing is broken. Using my testplan checklists of course.

I might even though through the entire program and make sure nothing has changed. In fact, I probably will.

Brief overview of GitHub

For those new to GitHub, and I am one, it’s very well documented. First a quick overview of the process.

Open Live Writer has two different repositories (a repository is just a place to store things). One for the program itself and a second one for the documentation. If you are reading this, you are reading documentation.

The code is at and the documentation is

The two best places to learn about Github, is Github itself. Help is at and There is a walkthrough there.

Unfortunately if you are adding to documentation or code, you do have to use both GitHub desktop and Git Shell, again the process for both are very well documented, with a tutorial loaded into Github Desktop.

How to contribute by testing

One of the best ways to contribute is testing. There are test plans and some information in the source, under the directory test plans. Also feel free to check those and update them if you find an issue.

They are basically check lists that go through every function of the software and tell what should happen when you do them, including images. We came up with this on my last programming gig, and they helped everyone.

The programmers then knew what we were expecting and so did QA. I often had QA help me with them so that they would have some ownership.

So what do you test and how?

Each time a developer makes a pull request, you should go through the new functionality and make sure it behaves as expected. Then you should go through the rest of the software making sure that something wasn’t accidently broke.

At least two different people should go through the process, but the more the better. It also helps if someone goes through it that has a fresh eye on the software.

So where do you find the executeable? To do the last build in the pull request, scroll down to the point where you see “All checks have passed”, and click on “Show All Checks”. Click on “Details”, then “Artifacts”, and will see OpenLiveWriteSetup.exe – download that and run it even if you get messages from Windows saying it isn’t safe.

If you do find an error, give the developer as much information as you can. Screenshots, error messages, log files, you name it. The more complete you are, the less time the developer has to spend tracking the error down.

You can also test the nightly build. It will contain everything that has been merged.

You can setup OpenLiveWriter to always run the nightly build: Go to regedit, find the registery key: HKEY_CURRENT_USER\SOFTWARE\OpenLiveWriter\Updates Then you need to create a dword key for CheckForBetaUpdates 1 = beta, 0 = regular.

You can also pull the nightly build manually by going to this link:

Or click on the build button from the readme and then click on latest build, artifacts

Again, if you find a problem you’ll need to raise an issue and give as much information as you can.

Contributing to Documentation

I’ve expanded my contribution. I’ve been posting blog posts to the website. I’ve also
created a tutorial and I will be doing more as we all get more comfortable with the process.
I would also like some help.

The Open Live Writer website is at and is maintained and
hosted with Github and Jekyll.

Jekyll is pretty easy to use once you get the hang of it. I started out by creating
my own Github/Jekyll website. That way I wouldn’t have to worry about screwing anything up.

I installed Jekyll by following the directions on this website:
which creates a web server on your machine so you can see what you have done.

Now my blog posts are in markdown. However, my tutorial is in html, as that is what I
am most comfortable with creating. I’ve taught computer science and web design for several
decades and have created tutorials for both students and adult coworkers, and so that’s
the tool I’m most comforable with. Besides, I could then use Open Live Writer – though I think
markdown is in the plans.

Contributing to Open Live Writer

I have been using the original Live Writer since it came out, and loved it. I was an avid user of the plug-ins too.

As soon as I heard about Open Live Writer, on December 9th, I downloaded it and set up my blogs. Immediately I read the documemtation and saw that they were looking for contributors.

My bachelor’s degree is in computer science, my master’s in education with an emphasis on online learning. Both before and after my teaching career I worked in industry, most recently on a Windows phone app as a contractor. I also write my own software both mobile and web apps when I need to.

I will admit to a huge learning curve with GIT, but I’m getting there. I’ve used SVN before, and have it set up on my own server. While I am not currently comfortable with the code, I’m doing what I am comfortable with – working on documenation and test plans. The developers have been super supportive of my efforts, and one of the reasons I’m writing this, is to urge other people to come on board like me. This is probably one of the most supportive open source projects I’ve seen, and I would love some help.

Those test plans have typos, and may be missing some spots. That’s a really good way to get handle on the whole project and I’ve already even found some problems and helped fix them.

Here are some other things that people can do before they get comfortable with the code: the best is examining any new issues, trying to reproduce them and encourages reporters to be helpful. I’ve even set up blogger and wordpress test blogs to help in that effort.

And of course, if you can code, jump in and do so!