Recipes for Success

There are multiple recipes for success in technology, and like chefs, they vary from place to place and person to person.

What works for one person won't for another, without some adjustments.

In many ways the Local Sourcing movement changed the ways in which cuisine was made, gone in some places were the Special of the Day (to go on a tangent that was often a way for kitchen's to get rid of stock that was getting old) to be replaced with a full seasonal menu.  Just like companies that use different technologies in different ways so the environment is different in what a Developer, Tester, or Manager needs to know in order to stay current or be ready to make the next step.

Recipes handed down in a family are based on a point in time where ingredients were local and available, some at only certain times of year so they were "in Fall we had" or "on this holiday my grandmother made...".  When shipping became more immediate and being able to send produce and meats long distances with a relative amount of freshness so more ingredients became available in wider times.  That removed the specialness of certain things that could only be found at certain times of the year, and how foodies looked only for certain ingredients at certain times because only THEN were they tasty.

Technology evolves but in companies with established practices there are certain things that remain in a specific way with people having to learn how to use that version of a software with another.  Change comes slow, and with new versions of Java, Python, and dare I say Perl (though who even uses that anymore...) at times you need to adjust how software is built and when bringing build recipes current there are adjustments that need to be made.  Some easy, some not.  Some complex, some not.  In the end its the result you want, and like a tasty dish, you want the build to be complete, whole, and workable.

Correlations are fun, and there is more to be done with cooking (a fave of mine) and software, but more on that later.  I have a special dish I need to get ready for....

Keep Moving Forward

 It's hard to keep current, especially with all the options out there, and stay on a single trajectory to both improve oneself and keep progress going on a career path.  It's no longer a single line that moves one up a traditional line of promotions to some sort of mythical Manager or VP or CEO position but often a zig zag of moving between hard and soft skills or between languages and tools that often don't lead to one place.

It's like a continually evolving buffet where tools, languages, processes, and management styles continually update or are reviewed, and reviewed again.  Deciding on what trajectory to take is difficult, especially if as usually happens, one tends to change jobs every couple of years.  Anecdotally people change jobs every 3 to 5 years, the time of the company man has been long gone.  Very few stay on at a company for decades working for one place, many have worked for company after company where they only thing they take with them are skills, knowledge, and experiences.

So what to do?  I take it in three steps on what I want to learn:

1. What am I doing now that I need to improve on?
2. What am I doing next that I need to know more about?
3. What is coming up that I need to understand?

This makes the choices fairly simple for me, as languages evolve and there are those I am using constantly then I want to keep up and improve my coding ability.  Being able to make code more concise, readable, or find new ways to be DRY (Don't Repeat Yourself) are what I look to be able to improve at the moment.  Keep current skills fresh and improved, move up to the next level, and that keeps my toolbox fresh and up to date.

Anything that may be coming up, some new tool, idea, or something the company is using is always a good option.  It's hard to implement things, or use things, you don't understand.  Becoming familiar with the next thing coming is a good way to be prepared, don't wait until it comes.  Take the time to figure out what it is, learn it, then plan for it.  Knowing about the next project makes planning much easier.

Along the same lines there are new projects that may be coming, in companies change doesn't happen in a vacuum.  People know, they are aware and plan for change.  As the Scout motto says - Be Prepared.  Which also works well for personal advancement, being ready for the next change or the next project is the best way to succeed and keep the time working on it down and being ready to jump in and start not only makes one look better, but also starts you on the path to success.

Keep moving forward, but also keep preparing yourself.

Accessibility Testing in Automation

 One of the new items I have been adding into the Automation Frameworks that I support, is the Axe Tool.  This does a check against page source to determine if the HTML structure is compatible with various assistive technologies.  This is something that can be added into a browser, and allows manual testing, but why do things manually if you can automate?

Automate or die!

That's been the mantra, well not die, but it's got to be serious.  After all why do things manually if you don't have it?  So to start we create a UI test to Login and go to a home page like the following (forgoing most of the basic Class setup, which I am assuming you, dear reader, know how to do - if not, just read on and learn what you can!)

@Test(description = "Verify Login Accessibility")
public void testLoginPageAccessibility() {
    logger.info("This is to test the a11y functionality with the AXE library.");
    LoginPage loginPage = new LoginPage(driver);
    try {
        loginPage.goToPage(new URL(getRunTimeConfig().getUrl()));
        User user = getUser(userId);
        logger.info("Checking page for " + user.getUsername());
        loginPage.login(user.getUsername(), password);
        logger.info("Getting the Accessibility Report for the Landing page.");
        getAxeReport(getCurrentMethodName());

The Current Method Name is the loginPage method, that is built upon the WebDriver GET so what is being sent to getAxeReport() is the current page being checked.

So let's look at how it generates the Report:

public void getAxeReport(String testMethodName) {

    logger.info("Checking for accessibility on page: " + driver.getCurrentUrl() + " for " + driver.getTitle());
    org.json.JSONObject responseJson = new AXE.Builder(driver, scriptUrl).setTimeout(180).analyze();
    org.json.JSONArray violations = responseJson.getJSONArray("violations");
    String pageName = driver.getTitle().trim().replaceAll(" +", "");
    String reportName = OUT_DIR + testMethodName + "/" + pageName + ".json";
    String rawViolations = OUT_DIR + testMethodName + "/" + "raw" + pageName + ".json";
    try {
        if (new File(OUT_DIR + testMethodName).mkdirs()) {
            try (Writer file = new OutputStreamWriter(new FileOutputStream(new File(reportName)),
                    StandardCharsets.UTF_8)) {
                file.write(cleanUpAxeJson(violations.toString()));
                logger.info("Successfully wrote Axe Report to File...");
            }
        } else {
            logger.error("failed to create directory");
        }
        if (violations.length() == 0) {
            Assert.assertTrue(true, "No violations found");
        } else {
            logger.debug("Found violations, generating raw report.");
            AXE.writeResults(rawViolations, responseJson);
        }
    } catch (FileNotFoundException e) {
        logger.debug("File Not Found exception: " + e);
    } catch (IOException e) {
        logger.debug("IO Exception: " + e);
    }

}

What's happening is the page URL is being obtained, and using the AXE JavaScript library against the source of the page, collect the results into a file.  From the results most of what we care about are the violations, and as this is all JSON, we just need to parse the JSON tree and save the parts that tell us what is wrong with the page.

Results we save locally so the Report can be stylized, or saved and reviewed later by people who know what violations are really a problem.

Easy peasy.

Looking for the next BIG THING!!

There is always the cool item on the horizon.  The next tool that YOU MUST HAVE!!  Something that your Team cannot do without, or that cool presentation at the conference that took you by the shirt and shook you until you could do nothing else but think about IT!!

It's something all too familiar to many of us.  We want to improve, we want to be current, no one wants to be left behind or fail at being competitive.  A lot of this is psychological, we're human and in some ways the tools, with savvy marketing behind them, know how to get inside your head and get you thinking about them.  It's not a bad thing, but falling for it without knowing is.  Don't just jump into something without checking it out first, spend time looking at those tools and seeing if they will work.  Talk to co-workers, do a POC, and make sure the fit is right.

A warm glove is just as good when made out of different materials, but if you need to use your fingers, a mitten won't work. Check the fit, ensure that what you innovate or enhance meets the needs of the Teams that will use it, and that the Teams have the background to readily accept the change.  Nothing gets a nose out of joint than a tool you are forced to use that doesn't meet all the needs of a Team.

When looking to make improvements I look at the following questions to start.

• Is this a programming language the Team already knows?
• Does the interface merge with the existing without a lot of retraining?
• Can you slip this into the builds and use it without people noticing?  The best updates are those invisible to the Users, they suddenly find their existing functionality works, and they have new options.  WIN!
• Does it fit the culture?  The worst changes require significant retraining.

When working with people, they have emotions, feelings, and wants same as you.  Ensure you meet them and people will accept what you offer, when you give them junk, expect complaints.