How to be innovative and how to keep yourself motivated

At work some times it could be possible that you end up working on certain project and may end up performing kinda similar tasks w/very little variations... So would that become monotonous ?

Do you think if it becomes monotonous..you may loose productivity to some extent and to help performing excellent at work, you need your motivation to be boost ?

Well, here is how I keep myself motivated - whether its work or cooking in kitchen. Coming from an Indian background, I almost end up preparing similar kinda breakfast with little variations...my family may get bored with same taste over and over again so I try to add different spices or motivate myself to try creative recipes for the same dish :) Well that truly helps!

I found below an interesting article published which helps self-motivation:
http://business.timesonline.co.uk/tol/business/management/article5883575.ece

JMeter or Selenium - Performance Testing of Web App

Some one recently asked me an interesting question "which tool better for performance testing for given web app - Selenium ? or any other open source ?"

Well here is my take

Find bugs - Static Analysis To Look For Bugs In Java code

Find Bugs - A static analysis tool to find logical error in given code snippet. Basically it helps find bugs in Java code. This comes as an Eclipse plug-in.

There is a way you can integrate Find bugs into the source control you are using for example Perforce.

This should be integrated on each and every development environment of developer's whether Eclipse or IntelliJ. As you go on writing code, this tool will immediately display errors which could cause eventually potential bugs with coding right away. So it saves time of developers handing over code to QA, QA performs testing and reporting back these bugs. Here is published material bu Find Bugs community as it was used @Google for product AdWords:

Published Material:Find Bugs Approach As Published

Methodology - Agile Testing Approach

What does Agile Means:

• Being Agile means creating an environment where change is embraced
• Changes in requirements, system knowledge, and /or organization are considered part of normal software development
• Agile is about focused collaboration between customers and developers
• The main goal is clean code that works, at a minimum investment

Why Agile: Reference: [AgileManifesto01] “Individuals and interactions over processes and tools Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. That is, while there is value in the items on. the right, we value the items on the left more”

 

When does Agile Makes sense:

• Rapidly develop and deliver software that
• meets business needs in the face of an
• unpredictable future
• Ability to change your mind
• Early availability of business value
• Option to cancel at any time yet still have value
• Handle uncertainty
• Visibility to & feedback from the customer 
  

When does Agile makes no sense:

• Uncertain and/or unstable success criteria
• Uncertain and/or unstable requirements
• Immediate access to business expertise
• High value in early release of partial functionality
• Project can be “self-contained”

  When does Less Agility makes sense:

• Knowable, stable project goals and requirements
• Like version 3 of a well-established application
• Customer can't absorb frequent releases
• High effort of data conversion, user training, …
• Team is too large, dispersed, or high turnover
• Poor team dynamics
• Lack of customer representation and/or poor
• customer relationship
• Dependence on external supplier's
• Long-term maintainability is important
• Life- or mission-critical products

There's more than one way to be Agile: 

• Extreme Programming
• Scrum
• Crystal
• Agile Modeling
• Dynamic Systems Development Method
• Feature-Driven Development
• Adaptive Software Development

Is Agile Appropriate:

• §Learning objective
• §Practice evaluating projects to see why they would or
• §wouldn’t be good candidates for agile development
• §Procedure
• §Read the Project Profiles in the Labs section
• §Discuss the projects in your groups
• §What characteristics of the projects make them good
• §candidates to be run as agile projects?
• §What characteristics make them not so good
• §candidates to be agile projects?
• §Extra Credit: Analyze your current project's 
  

Test A Little Code A Little:

• §You don’t need to write all the test cases first
  •1. You have to create of one test that the current code won’t pass
  •2. Write code to pass the test
  •3. Go back to step 1
• §If it is hard to write a test there may be a design issue
• §Each round of test & code includes refactoring of the previous code

Frequent Build and Test:

• §Completely build the product and run it through a series of tests to verify basic operation
• §“Daily build and smoke test”
• §“Continuous integration”
• §Works well with large volume projects
• §Lowering integration risk
• §Exposing big integration errors quickly
• §Tracking project progress
• §Extra effort/overhead

 How Frequent:

• §Not more than a couple of hours between builds
• §Build should take 10 minutes
• §Asynchronous builds most common
• §Check stuff in, the automatic build process
• §notices, sends out email of result
• §Synchronous builds give team a chance to reflect
• §Builds scheduled at certain times for all programmers

Multiple Builds:

• §Different builds accomplish different goals
• §Short, small builds on the test first approach
• §Overnight builds to test full integration
• §Weekly run more complete tests
• §Automation here is key
• §Agile sees this as a worthy area to spend
   

 Test Coverage Criteria:

• §How do I have confidence that my set of test cases is “good enough”?
• §Input and output domain coverage
• §Boundary value testing
• Decision (Branch) coverage

• Agile Testing good for Agile development projects;  can work on conventional projects too.
• Don’t implement Agile testing as a whole, but adapt its most valuable concepts
• Testers should be active members of the team.
• Testers often hesitate to speak up during team meetings, share ideas, interact with developers.
• Agile only works when there is lots of both formal and informal communication within a team.

Ongoing Conversation concept.

§With developers

§With CSRs

§Business Analysts.

Testers and developers are working together.

§Share office

§Testers assigned to help particular developers

§Test plan evolves  through a series of short “drop-in” meetings

§Benefits of pairing with developers:

     - developers gain insight into potential errors

     - testers gain insight into constraints and opportunities.

     - together can advance automated testing.

     - Grey box:  - understand relationship btw parts of the systems. 

                         - understand bugs:  what were the root causes?

                         - what needs to be retested?

                    

Test Status is reported via simple to read charts that answer specific question “What part of code can we stop worrying about?.”

Stand up reports.

Conversation with a customer is as important as with developers.

–Remember that customer are trying to figure out what they need, want and are getting, in large part, by trying out the  working code.

–Get feedback from CSRs -> create tests

–Participate in usability testing

Remember: “ …thinking does not take place inside our heads … Most of our mental activities need external resources.”

 

Keep in mind that sometimes design docs can be flawed.

Documents can’t be an adequate representation of the working code.

View them as:  interesting texts, partly fictional, often useful

Active communication is the key to a successful test plan

First, Waste No Time. Evaluate risky areas and test them first

     -  We gain an understanding of the product we're testing to the point where we can imagine what kinds of problems are more likely to happen and what problems would have more impact if they happened. Then we put most of our effort into testing for those problems. Agile Testing is concerned with uncovering the most important information as soon as possible.

Mission. What's more important? Writing test cases or doing testing?

     -  In Agile Testing we don't start with a task ("write test cases"), we start with a mission. Our mission may be "find important problems fast". If so, then writing test cases may not be the best approach to the test process. If, on the other hand, our mission is "please the FDA auditors", then we not only will have to write test cases, we'll have to write certain kinds of test cases and present them in a specifically approved format.  In our case it’s both.

 

Skills.

      -  Knowing the product lets you perform “out of the box” testing

Exploration.   

     -  Use exploratory testing. We prefer to let the next test we do be influenced by the last test we did. This is a good thing, because we're not imprisoned by pre-conceived notions about what we should test, but let ourselves develop better ideas as we go.

Teaming.   

     -  Agile Testers cheat. That is, they do things that our former elementary school teachers would consider cheating: we figure things out in advance where possible, we borrow other people's work, we use every resource and tool we can find. Example:  Pair testing: two heads, one computer. This idea has proven valuable in the practice of Extreme Programming, and it works for testing just as well. In our experience of normal testing, testers usually work quietly and alone, rather than hunting for bugs like a pack of rapid wolves. Again the message of this presentation is not  to try to adapt Agile testing as a whole, but extract and implement the most useful techniques of Agile testing.

Some of the stuff is being done already.

    -  Testers have stand up meetings

    -  Some Interaction with CSRs (manager, team leads)

What we don’t do yet:

    -  Closer interaction with developers.

    -  Closer interaction with CSRs. (primary testers)

    -  Robust testing, “out-of-the-box” thinking. (for primary testers)

    -  Grey box:  understanding of the system.

    -  Automation:  combine unit tests and our automation tests.

    - Testing in pairs. 

Increase quality of the product.  Find bugs faster.

Get more exposure for QA

Get better understanding of components.

Interact with developers more, which is always good.

Get better understanding of the working code.

Deliver marketable product earlier

 

Automated Testing:Hadnling/Managing ever changing UI - Use of CheckSum

Following post has a bug and an unanswered question - How would you handle dynamically updated web app. I do have some solution in my mind and just need to try it out before throwing as a post. So update soon.... ************

Firstly we need to understand what is Checksum. According to wikipedia:
A checksum or hash sum is a fixed-size datum computed from an arbitrary block of digital data for the purpose of detecting accidental errors that may have been introduced during its transmission or storage.

MD5 generated Checksum for a string is unique. And it will always give same checksum value as long as string does not change. Now selenium requests page we can use get_html_source to get back entire html source as a string. Then we can calculate checksums and we store it as our "html data or test data" and proceed with test.

Next time we run test we again get checksum and compare with the (existing) checksum that was recorded earlier.

Now there will be 2 scenarios ==>
1. Checksum is identical to recorded one which means there is no change in UI
2. Checksum do not match indicating change in UI.

If scenario 2) exists, then we can stop testing that particular page and send a report to QA that UI has changed for that particular page!!! At this point individual QA developers can visually inspect changes and verify by running test script meant for that particular page from there own laptops.

This will ensure that any UI change is taken care of. Sometimes we may get false-positive changes, might be due to some text element or images which don't really affect our test scripts because none of form fields or link ids have changed. Hence local execution of the test by QA will be all that is needed to verify if the GUI has really changed to necessitate script changes or its a non-script breaking changes.

Furthermore --- checksum algorithm and parsing html source to traverse through DOM to find elements - update soon...

Automated Production Testing - Why does it raises eyebrows!

Every company has different rules and revenue impacts about production environment changes depending users input stream and business model.

AdWords is one of the most complex project I have ever worked on. AdWords involves huge complex calculations and collections of data and stats. It has various salient features and has a very heavy duty traffic of zillions ..trillions end users. These zillions..trillions end users are expected to perform various combination of actions and transactions. Testing such an application is in itself a challenge. Above all, even thinking about automating such an application was definitely complex and challenging!!

Certain aspects to take into consideration for automated production testing:

•  

JUnit

As requested posting a blog about Junit

What is Junit ?
Simple framework for writing and running automated tests. Includes useful abstractions for running tests including test cases, text fixtures and test suites.

package junit.samples;


import junit.frameworks.*;
import java.util.Vector;
import junit.extensions.*;


/**
* sample test for java.util.Vector
*/
public class VectorTest extends TestCase {
  protected Vector fEmpty;
  protected Vector fFull;


public VectorTest(String name) {
      super(name);
}
public static void main (String[] args) { 
      junit.textui.TestRunner.run (suite());
}
...
protected void setUp() {
  fEmpty = newVector();
  fFull = new Vector();
  fFull.addElement(new Integer(1));
  fFull.addElement(new Integer(2));
  fFull.addElement(new Integer(3));
}
public static Test suite() {
    return new TestSuite(VectorTest.class);
}
public void testCapacity() {
       int size= fFull.size();
       for (int i=0; i < 100; i++)
          fFull.addElement(new Integer(i));
       assertTrue(fFull.size() == 100+size);
}
public void testClone() {
   Vector clone =  (Vector)fFull.clone();
   assertTrue(clone.size() == fFull.size());
   assertTrue(clone.contains(new Integer(1)));
}
}
...


What is JUnitPerf ?
Collection of JUnit tests decorators used to measure the performance and scalability of functionality contained within existing JUnit tests. When ever performance and scalability requirements are critical, JUnit perf plays an pivotal role.

Supported JUnit test decorators:

Timed tests: Runs a test and measures elapsed time

Load tests: Runs a test with concurrent users and iterations

Threaded tests: Runs a test in separate thread

JUnitEE: This is an extension to Junit. It allows tests to be executed inside an application server. Hence tests run in production environment.

Code Coverage Tools:

Emma - I have used Emma as well as our own version of Clover in my previous company. One can find all information about Emma at emma.sourceforge.net

Clover is commercial, free to open source project. Here is an example image for a cal app: