Development2014 - Day 1 highlights

I was very fortunate to attend and present at Development2014 in Millbrea on Monday, May 5, 2014.

Gateway Analytics Network did a great job setting it up and I learned alot.

I learned about Kanban, Parc business updates and strategy, and Scaled Agile. Amazing stuff.

iOS Mobile application tutorial using the Screen Design Pattern

Hello everyone!

Just in time for #development2014 Conference, here is a great learning opportunity for anyone wanting to learn how to do automated testing using Appium and the Screen Design pattern.

http://sqaevangelist.com/mobiletestingexample.html

Try it out and let me know if you need any help.

Happy Testing!

I am going to be presenting at Gateway Analytics Network Development 2014 Conference

http://www.gatewayanalyticsnetwork.com/images/Events/D105/brochure.pdf

Please come and join this very important conference for the benefit of every single person in your company. Attend and learn, take it to the next level!

Constantly remind the team that your intent and feedback as a QA resource is always to represent the customer and push for great product experience

If you really want to be an elite QA person, part of achieving this goal will be your willingness and non-stop effort to provide feedback to whatever parts of the company are introducing risk to product features, timely delivery, and user experience.

These main attributes will separate you from QA resources that are, what I like to call, "button pushers" or "test automation monkeys" and prove the real value of your expertise to the product and the team.

It is not an easy thing to do.

One of the major reasons that it's not easy is because most QA teams work for an engineering organization on the company's org chart and any honest and constructive, critical feedback will always be discouraged. It can be considered a conflict of interest. We still do live in the world, unfortunately, of office politics. Any good intention and truthfulness exposing activities within the company that are genuinely negatively affecting the product and user experience will normally not be taken and perceived with true intention from the QA person, or perhaps because traditionally the development team doesn't respect the QA team because of their lack of technical skills.

It's unfortunate, but true, in a majority of traditional product development teams.

Do not let the potential of friction with development or product teams discourage you from expressing your very well-informed opinions. If you have data showing high bug counts and can show risk at certain points in the development cycle, then it is almost impossible for anyone to have a rebuttal to your recommendations.

Data drives decisions. And as the rock star QA person, you have all the data you need to prove your points because you know the product and user experience better than anyone else in the company.

Smart teams, and smart team members, will respect your opinions and want to make the necessary incremental changes that you recommend.

And most of all, eventually, if they are honest with themselves, those team members will realize that your feedback is entirely given with intent of best possible product quality and excellent user experience. Your feedback is intended for better product experience of the customer.

Embrace the friction and make the product better.

I'm a Professional SQA Engineer, so please don't consider me a SWET

Although I am very truly grateful and appreciative when I get emails from recruiters wanting to interview me for the newly minted job title of Software Engineer In Test (SWET) job requisition at their company, searched on from my LinkedIn profile or other resume job posting in the recent past, I always immediately delete the email.

Why?

Because I am not a SWET.

I gave up being a software engineer in 2008 after 25 years of being a paid code monkey. I transitioned from being a software engineer and architect several years ago, because I wanted to make a positive and dramatic impact on User Experience (UX) and overall software quality as a Quality Assurance Engineer.

I have software development and object-oriented design skills in several languages.

I have been a Motorola 68010 Applesoft and assembly programmer since 1983.

I started programming in Java in 1994. I was a software engineer and architect in 1996 when the only way you could create a functional website with dynamic web pages was with either Active Server Pages (ASP - Windows) and CGI Perl (Unix) and I developed functional websites with Java Servlets and JSP in 1998 when the spec first was released to the public. Before EJB. Before AOP. Before SOA. Which, of course, I was also a developer and Architect during those times.

In recent years, I have been a leader and architect in developing software with the purpose for rapidly automation software testing.

However, consider this: I am a Software Quality Assurance professional and my deep background in software development has NOTHING to do with my qualifications as a SQA Engineer, and doing testing at the very highest level.

Why? Because my passion has always been for the best and most enjoyable user experience and best possible software delivered to......

Why? Because I identify potential process and team friction points and bring them to attention, because I realize those have much potential impact on software quality for.....

Why? I realize that a chosen software development process by may not be the working out for the best at that particular time in the evolution phase of the company, and that any chaos and missed product development deadlines will always negatively affect.... 

Why? Because if I can get automated tests working non-stop and seeing positive and consistently good test results (100% pass rate) then I feel more confident that all this effort benefits....

Why? Because everything I do during the workday, every decision I make to prioritize the many tasks I have to perform, I always keep one thing in mind.....

The customer.

The end user.

The person who deserves the best product experience and needs it to positively impact their lives and want to use it everyday, because it benefits them and makes their life better. From a personal/consumer usage perspective. From an enterprise/for pay product perspective.

Your customer deserves the very best every single day. Your job as a Quality Assurance Engineer is to do everything you can to make that happen.

Pushing buttons on a mobile device and writing automated tests and providing reports on test pass/fail results don't impact on software quality, but YOU can if you choose to.

Using automated tests to test features only, or testing overall User Experience, Features, and Performance?

Since the pre-mobile application days of automated web app tests using Selenium, I have observed so many automated testers worrying about setting timeout on server response of the web app being tested, so that they can instruct Selenium to wait X number of seconds for response time of the browser to finish loading the content of the page such that features can be without a disruption from any delay in response from the backend.

My feeling always has been: why?

Selenium has the ability for the automated test code to wait until the entire content of the page has been loaded for any amount of time: using ajax or not.

But isn't testing a web/mobile app also wanting to test features + user experience + performance (which includes backend response times and component/page loading )?

If the automated tester wants to test features only, set a very generous timeout from the response to allow any potential performance issues to load to the remote client (web/mobile) to finish before testing and interacting with the page/screen.

Again, I ask: why?

Instead of using allowing a timeout before failing a test, why not just set a timeout before page/screen validation of what you think is an acceptable server response/page/screen load time before validating the page/screen that is acceptable for UX?

This will give the QA team insight of not just the product features that are working, but also working within an acceptable user experience and backend server performance response. Setting your own UX standards and acceptance criteria in the automated test code can provide a valuable insight into more aspects than features. I can tell you that I have found so many performance and UX related bugs with this testing strategy.

Appium WebElement assignment strategies for testing mobile apps

Almost on a daily basis, I am adding to our very solid and robust automated testing framework for my company's android and iOS mobile apps.

We use Appium to interact with the iOS (ViewController) and Android (Activity) mobile application screens.

Appium is the absolute best (and only product) that everyone should be using to write automated tests and interact with their company's mobile applications.

Using the Screen Object design pattern, where the complexity of screen object components are encapsulated, there are 2 basic ways to do this: By using xpath or by lookup by element type and assigning the element to the value (or name attribute value) that is seen by Appium during iteration of web elements (Webdriver API objects) of a particular type.

In this case, let's say that the login screen has a username/password set of components and that they are of type "text" as seen by Appium (using Java programming).

1) Strategy of looking up components by expected xpath locators that Appium will find on the screen:

public class LoginScreen extends BaseScreen {

    private final static String USERNAMEXPATH = "//linear/form/text[1]";
.
.
.
    public void enterUsername(String username) throws Exception {

        try { (getWebElementAtLocation(USERNAMEXPATH)).sendKeys(driver, username); }
        catch(Exception e) { throw e; }

    }

} 

In the base class there would be this method:

protected WebElement getWebElementAtLocation(WebDriver driver, String xpath) throws Exception {

        

        try { return driver.findElement(By.xpath(xpath)); }

        catch(Exception e) { throw e; }

        

    }

or, 2) Strategy of looking up and assigning by an element type and value (or attribute value, such as "name" value)

public class LoginScreen extends BaseScreen {

    private WebElement usernameField = null;
.
.
.
    public void enterUsername(WebDriver driver, String username) throws Exception {

          try {  

             if(this.usernameField == null) this.usernameField = getWebElementFromTextElementsValue(driver, "username"));

             this.username.sendKeys(username); 
        
        }
        catch(Exception e) { throw e; }

    }

} 

In a base class there would be this method:

public class BaseScreen {

.
.
.
    protected WebElement
getWebElementFromTextElementsValue(WebDriver driver, String value) throws Exception {

        try { 
   
              List<WebElement> elements = driver.findElements(By.tagName("text"));

            

              for (WebElement element:elements) {

                

                String data = element.getAttribute("name").trim();

                

                if((data == null) || (data.trim().length() == 0)) continue; // blank, so ignore

                   

                if(data.contains(text))return element;

                    

            }

            

            // if we get here, we could not find the element so throw an exception

            throw new Exception("Could not find text element in any screen element matching type: text and text value: " + value);

        }
        catch(Exception e) { throw e; }

}

The advantages of using strategy #1 are: providing Appium/WebDriver with the exact lookup xpath, which results if faster returning of the screen element for interaction. The disadvantages are: using this method may possibly make the maintenance of this class more "brittle" if the xpath for the element changes with screen updates/redesigns.

The advantages of using strategy #2 are: elements are looked up with attribute values (name or value attributes), and xpath location is not an issue. Assuming the getText() or getAttribute("name") will lookup the correct element regardless of any new components added to the screen. The disadvantage is that lookup might take a little longer since we are instructing Appium to iterate and check the values of the attributes of all components of the type "text" before returning the one we want. It may perhaps slow down the test execution.

Summary: If you have screens to test on your mobile app that don't change very much, use the xpath lookup strategy (#1). If the screen has alot of changing formats/design, use the web element lookup strategy (#2) to avoid less maintenance in needing the Inspector to find the updated xpath locator and thus update of the code.