We have been building a SCORM packager and API, customized for our own applications, so we don't have to use tools like Storyline or Lectora to provide content to an LMS.
Our test package seems to work fine on Scorm Cloud and Moodle. So, we are happy, but not 100% sure we are done.
Our question is therefore: is there another method to test our SCORM capability before sending packages to customers?
Short answer: Download the SCORM Conformance Test Suite from ADL (e.g. http://www.adlnet.org/resources/adl-conformance-test-suite-verion-1_2_7?type=software_downloads) and test, test, test.
Long answer: If you don't know where you're going, any road'll take you there. I mean, what are you trying to achieve? If you wanted your content to work in SCORM Cloud and Moodle, you're ok. If you wanted it to work in EVERY LMS, it will never happen, because there are dozens of LMS with poorly implemented SCORM API. If you wanted to legally cover your behind, you should look into your service agreement. What does it say about determining "broken content"? What do you do (legally speaking) if your content works everywhere except your client's LMS?
Ideally, you should determine quality criteria in the agreement, make sure you comply with those and define what happens if your content doesn't work for your client.
adding to Sergey's response: all you can do beyond the conformance test suite and SCORM Cloud is test in as many LMSs as possible. They definitely have quirks. At a minimum, I suggest downloading and installing every major open-source LMS you can find, including Ilias and Sakai. You might also be able to get free trials for commercial LMSs if you contact them directly.
Related
We are building an m-learning solution[IOS and Android compatible] at our company. The product needs to be SCORM compliant. I would like to know whether it should be developed in-house by the developers or other paid options should be pursued? What are other ways of making our product SCORM compliant? We are not rally positive about using SCORM Engine for this due to its high cost solution to our problem here.Any suggestion/help is appreciated.
You can include SCORM within content using a number of open source options available on GitHub.
Getting SCORM in the content (free) is step 1.
Packaging, bundling and deploying is really step 2.
This typically has a close relationship to how Curriculum defines a structure of lessons, modules, units etc. Not knowing exactly how they want to organize this, I can speculate that you may just have a simple "I want to know that the student viewed the content" approach. If you get into a more rich dependency on how the student performs dictating what they see or do next, that requires a much for up front design so you can bridge the design, development, and deployment of your content.
Including SCORM Support in content -
Like mentioned if you search google for my SCOBot project or Pipwerks you'll hit the ground running.
Requires JavaScript friendly developer and some base SCORM knowledge attained thru reading. This could be outsourced.
Knowing the version of SCORM you wish to support can help. Consult the LMS to find out that info.
Far as presenting / creating content; if you are doing this from scratch you'd need a HTML/JS developer or if its more interactive your dipping into WebGL, Canvas or beyond. There are other paid services like iSpring, Captivate and others that offer content creation with SCORM Standards support. They may even take care of the packaging for you (covered below).
Packaging -
This requires a zip (CAM content aggregated model) which includes a imsmanifest.xml file to describe a one to many relationship of a TOC. Again simple is 1, many begins to allow you to group tiers and add objectives and other things increasing complexity but doable.
You can perform creating this package with XML, Zip and specification knowledge. I have a Packaging app on my site and a Mac (free) applescript which can also perform very basic packaging. I am not away of any other free options.
Deployment
Commonly performed thru FTP/FileShare by uploading these CAM (zip) packages. LMS decompresses and reads the manifest. Sometimes you can just copy the raw files up to the LMS thru a media / content server but this greatly depends on the options.
I have recently approached by my co-worker about creating our own SCORM Packager. Honestly I have little clue about SCORM. I have look into Adobe Captivate and also Articulate Presenter. But unfortunately things that we worked here are highly customized. Our shop are half HTML and the other half is Flash.
Here are my questions:
Any suggestions to where I can get better understanding about SCORM (beside http://scorm.com)? I am looking something more hands-on approach.
is there a tool out there that can take our products (either HTML or
Flash) and wrap them into SCORM 1.2 zip compliant file?
Thanks in advance
For your course to be truly integrated with SCORM, you need to modify your ActionScript to report activities/status throughout the life of the course. This can't be achieved with a packaging tool, because it would have no way of knowing how your custom ActionScript is built and where to hook into it.
Adobe Captivate and Articulate Presenter have SCORM integration built in to their ActionScript, but it's under the hood where you can't see it unless you decompile their SWFs. The bits that are public -- the SCORM JavaScript, the manifest, etc. -- are only part of the story.
If you'd like to see a simple example of how to add SCORM code to a Flash file, see http://pipwerks.com/2008/04/27/how-to-add-basic-scorm-code-to-a-flash-movie/
It doesn't cover packaging, though.
To better understanding SCORM, I think you shoud go to the place where it born: http://legacy.adlnet.gov/Technologies/scorm/SCORMSDocuments/Forms/All%20Documents.aspx
ActivePresenter may be a good option.
I actually made a SCORM packager for my work. It's a bit of a process, but I think the best place to start was to study some working examples. You say you're doing SCORM 1.2, here are the reference files that you'll need; it has the CAM manual which tells you how the manifest file should be built. It also includes the SCORM 1.2 test suite you'll need to use to make sure your package conforms to SCORM, and that the content launches and communicates with the API correctly. The Test Suite is a bitch to setup though, and I recommend setting up a windows XP virtual machine image to test with(I used Parallels).
About your second question, I'm sure there is some public Scorm packaging applications out there, but we didn't find any that fit our needs (hence the need to build our own). You may want to look some more before creating your own from scratch; it will be a lengthy process.
I'm writing some SCORM SCOs to be embedded in clients' learning management systems but I currently don't have anything to test them on. It seems foolish (to the point of being unprofessional) to just foist these files upon the clients and to hope they "just work".
Is there a simple framework I can use to test a SCORM SCO package? I realise I could spend all day setting up a whole learning management system but if there's something more simple, I'd be really appreciative.
You will definitely want to check out the SCORM Cloud. They have a trial version you can use.
There's always the Test Suite provided by the publishers of the SCORM specification.
If you're working with SCORM 1.2, I'd recommend the Reload Scorm Player.
Tt's free, very easy to install and you don't need to be a tech guy to make use of it.
http://www.reload.ac.uk/new/scormplayer.html
I have used the tools from http://www.ostyn.com/resdownloads.htm both for testing SCORM 1.2 and SCORM 2004. Basicly just a HTML page that wraps the SCO in an iframe with a nice console to keep track of the communicaton.
http://scormpool.com has scorm proxy player with trace log option. Supports SCORM 1.2 and 2004 4-th edition plus you can download player and run it on you local computer.
We are in search of an automated testing tool for our project. As we are in testing department we prefer a tool which would have less programming in it. Please suggest some tools for us .Till now we are testing our application manually.
Our project is being developed in Java.
Is there any freeware tool that I could use or is it better to go for a paid tool?
Thanks in Advance.
Less programming? You'll need something like JUnit to write unit tests if you want to do serious regression testing, but unit tests require you to write some code
Here's a big list of open-source testing tools, some of them may offer what you want: http://java-source.net/open-source/testing-tools/junit
For example, T2 claims to be a random testing tool. As one, it is fully automatic, but one must keep in mind that the code coverage of random testing is in general very limited. It should be used as a complement to other testing methods. T2 checks for internal errors, run time exceptions, method specifications, and class invariant.
Not sure if you mean a CI tool or not, but we use Hudson at Zappos and it works pretty well.
http://hudson-ci.org/
..and there's also CruiseControl: http://cruisecontrol.sourceforge.net/
If you're not talking about CI, maybe you mean QA testing - in which case you should take a look at something like Selenium (for web apps):
http://seleniumhq.org/
If you're doing GUI testing? I'm not really familiar with that area, but I've heard about WinRunner and Rational:
http://en.wikipedia.org/wiki/HP_WinRunner
http://www-01.ibm.com/software/rational/offerings/quality/
..though neither are really free tools. Something like AutoIT might help you move widgets around, but it lacks the reporting parts:
http://www.autoitscript.com/autoit3/index.shtml
There could be two answer to you question:
Besides Selenium, though it has ample of advantages, I am reading about another tool which uses same API which Selenium use. The only changes in API I have seen so far is it reduces the complexity of functions thus making it more easier and simpler for user who is learning.
The tool is called 'Helium' and it has 50% (and more) less complex functions and code as Selenium has.
The only problem with this tool is it is paid tool for learning purpose and for implementing not-so-big scale project you can use it. But yeah after some time its gonna cost you.
I have implemented some code on Helium. Please let me know , if you face any issue initially or you are thinking to implement it.
Other being, you can use Selenium Builder(http://khyatisehgal.wordpress.com/2014/05/26/selenium-builder-exporting-and-execution/) which is an advanced form of Selenium IDE. It imports your command in different languages and does work more effectively and efficiently as Selenium IDE does(http://khyatisehgal.wordpress.com/2014/05/25/selenium-builder/) . So you can import scripts in Eclipse IDE and just execute them as is.
Please let me know , if you have any doubt in any of the tool.
We're in the initial stages of a large project, and have decided that some form of automated UI testing is likely going to be useful for us, but have not yet sorted out exactly how this is going to work...
The primary goal is to automate a basic install and run-through of the app, so if a developer causes a major breakage (eg: app won't install, network won't connect, window won't display, etc) the testers don't have to waste their time (and get annoyed by) installing and configuring a broken build
A secondary goal is to help testers when dealing with repetitive tasks.
My question is: Who should create these kinds of tests? The implicit assumption in our team has been that the testers will do it, but everything I've read on the net always seems to imply that the developers will create them, as a kind of 'extended unit test'.
Some thoughts:
The developers seem to be in a much better position to do this, given that they know control ID's, classes, etc, and have a much better picture of how the app is working
The testers have the advantage of NOT knowing how the app is working, and hence can produce tests which may be much more useful
I've written some initial scripts using IronRuby and White. This has worked really well, and is powerful enough to do literally anything, but then you need to be able to write code to write the UI tests
All of the automated UI test tools we've tried (TestComplete, etc) seem to be incredibly complex and fragile, and while the testers can use them, it takes them about 100 times longer and they're constantly running into "accidental complexity" caused by the UI test tools.
Our testers can't code, and while they're plenty smart, all I got were funny looks when I suggested that testers could potentially write simple ruby scripts (even though said scripts are about 100x easier to read and write than the mangled mess of buttons and datagrids that seems to be the standard for automated UI test tools).
I'd really appreciate any feedback from others who have tried UI automation in a team of both developers and testers. Who did what, and did it work well? Thanks in advance!
Edit: The application in question is a C# WPF "rich client" application which connects to a server using WCF
Ideally it should really be QA who end up writing the tests. The problem with using a programmatic solution is the learning curve involved in getting the QA people up to speed with using the tool. Developers can certainly help with this learning curve and help the process by mentoring, but it still takes time and is a drag on development.
The alternative is to use a simple GUI tool which backs a language (and data scripts) and enables QA to build scripts visually, delving into the finer details of the language only when really necessary - development can also get involved here also.
The most successful attempts I've seen have definitely been with the latter, but setting this up is the hard part. Selenium has worked well for simple web applications and simple threads through the application. JMeter also (for scripted web conversations for web services) has worked well... Another option which is that of in house built test harness - a simple tool over the top of a scripting language (Groovy, Python, Ruby) that allows QA to put test data into the application either via a GUI or via data files. The data files can be simple properties files, or in more complex cases structured (something like YAML or even Excel) data files. That way they can build the basic smoke tests to start, and later expand that into various scenario driven tests.
Finally... I think rich client apps are way more difficult to test in this way, but it depends on the nature of the language and the tools available to you...
In my experience, testers who can code will switch jobs for a pay raise as developers.
I agree with you on the automated UI testing tools. Every place I've worked that was rich enough to afford WinRunner or LoadRunner couldn't afford the staff to actually use it. The prices may have changed, but back then, these were in the high 5-digit to low 6-digit price tags (think of the price of a starter home). The products were hard to use, and were usually kept uninstalled in a locked cabinet because everyone was afraid of getting in trouble for breaking them.
I worked over 7 years as an application developer before I finally switched to testing and test automation. Testing is much more challenging than coding, and any automation developer who wants to succeed should master testing skills.
Some time ago I put my thoughts on skill matrices in a couple of blog posts.
If interested to discuss:
http://automation-beyond.com/2009/05/28/qa-automation-skill-matrices/
Thanks.
I think having the developers write the tests will be of the most use. That way, you can get "breakage checking" throughout your dev cycle, not just at the end. If you do nightly automated builds, you can catch and fix bugs when they're small, before they grow into huge, mean, man-eating bugs.
What about the testers proposing the tests, and the developers actually writing it ?
I believe at first it largely depends on the tools you use.
Our company currently uses Selenium (We're a Java shop).
The Selenium IDE (which records actions in Firefox) works OK, but developers need to manually correct mistakes it makes against our webapps, so it's not really appropriate for QA to write tests with.
One thing I tried in the past (with some success), was to write library functions as wrappers for Selenium functions. They read as plain english:
selenium.clickButton("Button Text")
...but behind the scenes check for proper layout and tags on the button, has an id etc.
Unfortunately this required a lot of set up to allow easy writing of tests.
I recently became aware of a tool called Twist (from Thoughtworks, built on the Eclipse engine), which is a wrapper for Selenium, allowing plain English style tests to be written. I am hoping to be able to supply this to the testers, who can write simple assertions in plain English!
It automatically creates stubs for new assertions too, so the testers could write the tests, and pass them to developers if they need new code.
I've found the most reasonable option is to have enough specs such that the QA folks can stub out the test, basically figure out what they want to test at each 'screen' or on each component, and stub those out. The stubs should be named such that they're very descriptive as to what they're testing. This also offers a way to crystalize functional requirements. In fact, doing the requirements in this fashion are particularly easy, and help non-technical people really work through the muddy waters of their own though process.
The stubs can be filled in via a combination of QA/dev people. This allows you to CHEAPLY train QA people as to how to write tests, and they typically slurp it up as it furthers their job security.
I think it depends mostly on the skill level of your test team, the tools available, and the team culture with respect to how developers and testers interact with each other. My current situation is that we have a relatively technical test team. All testers are expected to have development skills. In our case, testers write UI Automation. If your test team doesn't have those skills they will not be set up for success. In that case, it may be best for developers to write you UI automation.
Other factors to consider:
What other testing tasks are on the testers' plate?
Who are your customers and what are their expectations related to quality?
What is the skill level of the development team and what is their willingness to take on test automation work?
-Ron