? QA Design Gurus: 2016

Aug 11, 2016

Building a Robust Test Automation Scripts Using Telerik Test Studio/Test Framework- Best Practice



In today’s web world, where elements/controls in the web application changing on daily basis, it is very hard to change corresponding automation scripts to make it run on changed web application. Hence, developing robust automation scripts should always be the first priority. One key step towards robustness in Telerik Test Studio automation script is, be cautious while using any method or property in the scripts. Just think, in which class method/property defined? and are we using same class object to call that method/properly? I hope, answer for those questions gives better idea on what you are doing and what you need to do.

I would always suggest not to use narrowed wrapper class until it really require. Let’s take few common scenarios.


Scenario1:  Verifying inner text of an element. 
 Assume, Element in the DOM:
<span id="dash_heading"> Dashboard page of eval user </span> 
One way to get the inner text is (Script_1):
HtmlSpan Dash_Heading = ActiveBrowser.Find.ById<HtmlSpan>("dash_heading");
string Text = Dash_Heading.InnerText;
Another way is (Script_2):
HtmlContainerControl Dash_Heading1 = ActiveBrowser.Find.ById<HtmlContainerControl>("dash_heading");
string Text1 = Dash_Heading1.InnerText;
Both are the correct and gives inner text of “dash_heading” element. Here Script_1 fails if developer changes element type from span to div but not Script_2. Reason behind is “HtmlContainerControl” is base class for both “HtmlDiv” and “HtmlSpan” classes and property “InnerText” is defined in “HtmlContainerControl” not in “HtmlDiv” or “HtmlSpan” classes. So if your requirement is to get innerText go with Script_2 not with Script_1 to make your script robust.
Scenario2: Verifying whether button is disabled or not?
Assume, Element in the DOM:
<button id="btn">Submit </ button > 
One way to verify is (Script_3):
HtmlButton Button_Ele = ActiveBrowser.Find.ById<HtmlButton>("btn");
Assert.isTrue(Button_Ele. IsEnabled);
Another way is (Script_4):
HtmlControl Button_Ele = ActiveBrowser.Find.ById<HtmlControl>("btn");
Assert.IsTrue(Button_Ele.IsEnabled);
Above both (Script_3&4) are the correct to assert whether button is disabled or not. Here in Script_3 we are using derived wrapper class to get the IsEnabled property value where as in Script_4 we are using base wrapper class in which IsEnabled property defined. Hence, Script_3 fails if developer changes element type from “HtmlButton” to any of “HtmlInputButton” or “HtmlInputSubmit” but not Script_4.So if your requirement is to check whether button enabled or disabled, I suggest to go with Script_4 not with Script_3.

Scenario3: Click on Element/Control.
Assume, Element in the DOM:
<button id="ele1">OK</ button > 
One way to click on the element is (Script_5):
HtmlButton OK_Ele = ActiveBrowser.Find.ById<HtmlButton>("ele1");
OK_Ele.Click();
Another way is (Script_6):
HtmlControl OK_Ele = ActiveBrowser.Find.ById<HtmlControl>("ele1");
OK_Ele.Click();
Both scripts click on ele1 element but script_6 will pass even though element type changes from button to div/submit/Image etc.in future but not Script_5. The reason is, Click() is the method defined in HtmlControl class and this class is base class for entire HTML wrapper classes. It will be good to use Script_6 instead of script_5 to make your code robust.
Click Here to read more about HTML Control Element Wrappers Suite.
 

Jun 8, 2016

Who are You? I am proud to say I am a Software Test Engineer.

When I introduce myself as a tester either to a known person or to an unknown, many people asked me why not a developer? Or so many said oh testing in a sarcastic way which used to make me feel that it is not at all a Job :(
Also, they will refer some X person passed out in XXXX year from other streams (ex: Pharmacy, Agriculture etc.) who could not get into their field due to several reasons. Recently they completed learning some YY testing tool and want to join Quality Assurance team. J
I will just say them that testing is just not learning a tool and entering into the field. It is an art and person should be passionate enough to do that work.

A few myths behind their question/feelings can be any of these
1. Tester does not require skills to get into software field
2. Tester’s job is not an innovative work
3. Testers will not get an opportunity to code.
etc.

But I strongly oppose all of these.
Testers Job is very very innovative. The more we think the more complicated scenarios we can get to test.
I personally feel that only skills that a best QA engineer should have are innovative thinking and coding skills.


In Olden days, even in Companies, there were occurrences where QA is given least significance.
Earlier it was so because Developer used to write the specification and QA job is to derive test cases out of the specification and do Manual Testing. Automate only if they can.
Though the Product or service is developed by Developers, it does not mean that only developers are required to take care of everything. I can strongly say that Developers may not be able to test as an end user due to their development perception.They can think of the scenarios on how to test the written code but they may not think many cases which cover the whole product.

But after the Agile adoption,
  1. QA is now getting an opportunity to participate from feature planning itself which helps in thinking the scenarios based on customer perspective.
  2. Apart from normal functional testing, QA is now responsible for doing Non-Functional testing like Security, Performance, Resiliency Testing etc.
  3. QA is targeting to automate the feature completely to reduce repeated manual testing.

So now the software testing job is the very responsible and critical job.

As mentioned earlier, tester’s job is not just executing manual scenarios but has lot many things to perform. I have listed a few responsibilities of a tester below.
  • Should think like a customer and write cases (Very Innovative and critical task)
  • Developing Automation for the test scenarios (Need coding skills)
  • Maintaining the automation framework
  • Enhancing existing automation framework
  • Triaging the automation results
  • Write New test cases for new features and maintain existing Test cases.
  • Regular Regression Testing
  • Perform Integration Testing
  • Continuous Integration to find the issues when the product runs continuously.
  • Should be capable enough in debugging the customer issues.
  • Develop Test Strategy
  • Develop Quality Profile
  • Perform Non-Functional testing (like Security, Performance, load, Resiliency, i18N etc.)



I do most of these things and I am really proud to say I AM SOFTWARE QA Engineer rather than just a Software Engineer. :)

May 16, 2016

Test Driven Development

Testing is the process of evaluating a system/software with the intent to find whether it satisfies the specified requirements or not without any gaps or errors. As most of you know, testers are doing manual as well automation testing to check the software functionality. Can we do something to get more quality in the product while the software is in development process? yes, we can do using TDD.
What is TDD? TDD stands for Test Driven Development. Test-driven development (TDD) is a development technique where we first write a test before we write functional code and use the same test in different stages in development process.
Test-driven development is not about pure development and it is about developing the tests before developing the tests and providing more quality in such a way that there will be no critical issues in the product or software before giving the product to QA team for testing. These unit tests are extremely useful for the product.

TDD life-cycle.

1.     Write the test
2.     Run the test (test does not pass as there is no implementation code)
3.     Write the implementation code to make the test pass
4.     Run all tests, if all the tests are passed then developer can say that the code has met all requirements.
5.     Change the code to remove duplication and to improve the design
6.     Repeat the cycle




Outcome/Result of TDD:
1.     Both testers and developers can work more collaboratively.
2.     Test engineers will get in-depth functionality of a software.
3.     There will be no critical issues in the product.
4.     Improves the Software quality.
5.     TDD provides an assurance that the code works as design/intended.


May 15, 2016

Practical Experience: Taking Stance On Test Automation

Practical Experience: Taking Stance on Test Automation
It was a year and half ago that I was a bystander of an argument that has repeated itself a dozen times since. Which combination of programming language and supporting tool was better for automation system all across: Java with Sahi or C# with Telerik Test Studio. Each side blew-up weighty arguments: what is easier to do in each language, what language has better libraries, which tool has more flexibility, etc.
Who is right?
It is difficult to settle the argument entirely based on technology characteristics. Because, each language/tool has few aspects where it is better than the other. It is equally hard to judge which attribute is more important to be able to make a decision.
It is an Organizational Decision!
Now, it requires context-switching where we lose some time recalling/adapting to details of the language. It is very important for one to realize and scope the time that it requires for the engineer’s transition and that it requires to maintain existing automation. When the code is not written in the language the engineer prefers, the development and maintenance becomes as likely as not.
How to strategize for test automation in new Language?
Plan to achieve small success and grow. It is not possible to try automating the whole regression suit. Instead, try things, make mistakes and design even better approaches. This process never ends but at a certain point in time you achieve reasonably stronger point of view of the capabilities of the language or the tool. It helps drafting next generation of frameworks that sustain (as they should) over the life time of the product-under-test.
Automation is full time effort, not a side-line. Sometimes automation is extremely underestimated. Again, by starting small and growing, estimating the work can be gauged.

What if even after evaluating the new tool, there isn’t any clear choice? At this point the choice does not matter. The important thing is that we do choose one because the delay may be costlier if you made the wrong decision. Get the team to back whatever the outcome is, follow through with supporting that language.

Security Testing

Internet usage has been increased and became more important in our daily lives. There are many web applications which are hosted and accessed via internet/intranet. And being important and accessed mostly, security has been a concern for many enterprises and people.

Whenever a product or web application is given to the QA team, in most of the organizations only the functionality part of the product/application is being tested. Many a times Security aspect of the product is neglected or given less importance by QA. QA should be taking the lead or responsibility of testing the security aspects of the product too, as QA knows the product very well. Even if developers follow good coding standards, knowingly or unknowingly flaws can be introduced at time in the development lifecycle. Undetected flaws can turn into security vulnerabilities at runtime and it is always a good practice to do security testing, as no web application is totally secured.


Being a QA, if you are into security testing well and good but if you do not, you do not have to worry about it, there are quite a few automated tools which can find security bugs in the product/application but it is always good to have knowledge on different kinds of security issues.

Top Vulnerabilities
OWSAP, a free and open software security community has come up with top 10 vulnerabilities which can be found here (https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet) and SANS over here (https://www.sans.org/top25-software-errors/archive/2010)
There are 2 techniques/analysis
  • Static Analysis
  • Dynamic Analysis


Static Analysis
Static analysis is a technique which allows us to find bugs without executing the program. A static code analysis will automatically check the source code for compliance with a predefined set of rules or best practices. Static analysis tools are fast and efficient at finding code defects and inconsistencies. This technique is programming language dependent. So the tool should support the programming language in which your product/application is built on.
A static code analysis tool can help with your code review process by
  • detecting areas in the code that need to be refactored and simplified
  • finding areas of the code that may need more testing or deeper review
  • identifying design issues such as Cyclomatic Complexity and helping reduce the code complexity improve maintainability
  • identifying potential software quality issues before the code moves to production
  • memory leaks, buffer overflows, and even concurrency issues

(http://www.codeexcellence.com/2012/05/what-is-static-analysis-and-why-is-it-important-to-software-testing/)

Here is a list of tools available for applications build on different languages

Language or framework                                Static tools
C or C++                                           Splint, VisualCodeGrepper
Java™ technology                            FindBugs, LAPSE+, VisualCodeGrepper
JavaScript                                         JSLint, JSHint
Python                                              pylint, PyChecker
PHP                                                  RIPS
Ruby on Rails                                  Brakeman, codesake_dawn

Dynamic Analysis
Dynamic Analysis is a technique which allows us to find the bugs while the application running. For dynamic analysis to be efficient the application must be executed with different tests which covers every part of the application. Dynamic analysis does not have access to source code and it detects vulnerabilities by performing attacks. Analysis is not dependent on any programming language.
Dynamic analysis is more useful in finding runtime errors, memory leakage errors, SQL Injection, Cross site scripting, etc.

Both analysis is to be performed as part of security testing.
Few web vulnerability scanners available are IBM Appscan, Burp Suite, Zed Attack Proxy, etc.