Exploration and Testing (BBC 23Q2)

Judgement requires comparison. You'll have made several comparisons while you worked, judging what you found against what you expected. Consider how those would fit into the following classification:

• external inconsistency (vs an external authority i.e. a spec)
• internal inconsistency (vs another similar thing)
• cultural inconsistency (vs my own expectations)
• absence: something is surprising by its absence
• extra: something is surprising by its presence

If you don't have a hunch about what's going on, you'll build experiments to find out more information. Experiments designed to find out more will typically go in several directions to give you a wider set of clues; if you've seen a crash, you'll play more – and you'll turn on CPU monitors and loging, inspect and reply what you did the first time, keep close track of sequences, data, dependencies and constraints. If you've got a specific behaviour that you're chasing, you'll try to catch it several times with as much sensing as you can muster, and you'll see what variations in situation can lead to the same behaviour, and what similar situations show different behaviours.

If you think you might know what's going on, that's a model. You'll look for evidence to support your model, and should consider looking for evidence that refutes it.

Supporting your model: If you think it's a code bug, looking at the code can give you strong evidence. If you think it's to to with an external dependency, you'll find evidence in changing that dependency. If you think that your experience give you a special perspective, seeking the opinion others who share that perspective gives extra evidence.

Refute your model: You'll consider other plausible models, and build experiments to see whether they might be true. You'll work towards edge-cases in your model, seeing if the behaviour persists when your model indicates that it should not.

We need to develop our judgement – to recognise when something is worth our attention, to make sense of it in context, and to highlight the most important elements.

:Discipline in test design helps us discover information more swiftly or more truthfully.

:Discipline in test recording enables analysis, learning and trustable evidence.

As we develop that judgement, we're building an :aesthetic. Without an aesthetic, it's hard to judge (as you're always seeking external validation of your judgement) and hard to explore well (because you're senses haven't been sharpened).

If your testing has been user-action led, you'll already have a sense of what is right and wrong about (for instance) UIs and user journeys. If you've been involved primarily in code / unit test reviews, you may already have great judgement around what seems good and bad about code, tests and data schemas. Subject-matter experts are used, by testers, for their sense of what's good and bad.

The more novel the thing under test, the more you'll have to work towards a reliable aesthetic.

Repo

Tests

    function doTests() {
        let verbose = false
        log = function () {
            if (verbose) { console.log(...arguments) }
        }
        assert = function () {
            log(...arguments)
            console.assert(...arguments)
        }
        assertTrue = function () {
            assert(arguments[0], ...arguments)
        }
        assertFalse = function () {
            assert(!arguments[0], ...arguments)
        }

        function tryTestReporter() { // unused on purpose
            assert(true, "should not show this message");
            assertTrue(true, "should not show this message");
            assertFalse(false, "should not show this message")
            //assert(false, "should show this message", "...concatenated with this");
        }

        function testValidTime() {
            log("testing validTime")
            var subject = validTime;
            var examplesOfValidTimes = [
                "00:10", "10:20"
            ]

            var examplesOfInvalidTimes = [
                "", "a", "-1", "0:111", "111:00", "00:70"
            ]

            examplesOfValidTimes.forEach(
                (myTime) => {
                    assertTrue((validTime(myTime)), "this should be invalid", myTime)
                }
            )

            examplesOfInvalidTimes.forEach(
                (myTime) => {
                    assertFalse((validTime(myTime)), "this should be invalid", myTime)
                }
            )
        }
        function testGetCircleDashArray() {
            log("testing getCircleDashArray")
            let subject = getCircleDashArray;
            assertTrue(subject(1) === "283 283", "full-scale should report 283 283, and reports: ", subject(1))
            assertTrue(subject(0) === "0 283", "full-scale should report 0 283, and reports: ", subject(0))
        }
        function testCalculateTimeFraction() {
            log("testing calculateTimeFraction")
            let subject = calculateTimeFraction
            //assertTrue(subject(0) === 0, "check 0 at end. reported: ", subject(0)) //FAILS
            assertTrue(subject(TIME_LIMIT) === 1, "check 1 at start. reported: ", subject(TIME_LIMIT))
        }
        function testFormatTime() {
            log("testing formatTime");
            let subject = formatTime;
            assertTrue(subject(63) === "1:03", "check just over a min in secs returns 0-padded. Expected 63 to be 01:03, reported ", subject(63)) // broken test left in...
        }
        log("doing tests")
        testValidTime();
        testGetCircleDashArray();
        testCalculateTimeFraction();
        testFormatTime();
    }