If you have'nt read part-1 of the story, please read it so that you will get the full picture.
I appreciate the good design in IBM three tiered architecture, but I believed there could be better object oriented ways. The three tiered architecture gave me some good insights on how to maintain reusability, maintainability and the importance of a good design. It actually inspired me towards a different design.
I imagined a page as an object containing three other objects. componets, actions, and verifications. Each of these will have respective page specific items. Test cases are put in a different layer. A simple test case would look like the following. Think of the below as a psuedo code, just for explaining the concept, not a real one.
As I told in the previous post, this was a slack-time task, and though I was doing it with a lot of hope and passion, I was the only one doing it. A lot of code representing a lot of pages need to be complete to cover even smoke testing level. But, if the classes are ready, and API is ready, progress from Smoke Testing level to Medium/Thorough testing would be much quicker. The point is, a lot of coding needs to happen to achieve some minimal real progress. No one in the management realized that this is another development project, which demands a lot of programming skills and resources (people). After almost 1.5 years, I still seriously doubt that they have a good understanding of the load of the task.
After about three months, my supervisor, who is also a very good friend of mine asked a simple question. "Do you think we would be able to make it by the end of the year if we go in this pace". This let me re-think the whole progress and the target I would achieve at the end of the year.
By that time, only one test case was done. I had managed to ramp up another colleague, the one and only resource I had for sharing the work (only if he was free of other tasks). He was struggling to catch up with Java, and not so enthusiastic because the company is not Java based, rather PHP based. When we got into any Java specific issues, none was there to help. Another major risk was the entire product, the web application, was being re-written using symfony framework at that time. So, the product was changing. One traditional rule in Automation is "Not to Automate Against A Changing Product". The product has to be stable, before starting automation. So, by the time I write another ten more test cases, most probably the entire module would have been re-written making the automation code outdated.
Given all the above facts, I decided this is not the way. This prompted me to go for another solution. I'll explain that in the next post.
I appreciate the good design in IBM three tiered architecture, but I believed there could be better object oriented ways. The three tiered architecture gave me some good insights on how to maintain reusability, maintainability and the importance of a good design. It actually inspired me towards a different design.
I imagined a page as an object containing three other objects. componets, actions, and verifications. Each of these will have respective page specific items. Test cases are put in a different layer. A simple test case would look like the following. Think of the below as a psuedo code, just for explaining the concept, not a real one.
Login login = new Login("URL");
login.actions.login(username, password);
if(!login.verifications.verifySuccessfulLogin())
System.out.println("login no successful");
else
System.out.println("Successfully logged in as " + user );I designed this without knowing that there is a similar, but better pattern called pageobject design.
As I told in the previous post, this was a slack-time task, and though I was doing it with a lot of hope and passion, I was the only one doing it. A lot of code representing a lot of pages need to be complete to cover even smoke testing level. But, if the classes are ready, and API is ready, progress from Smoke Testing level to Medium/Thorough testing would be much quicker. The point is, a lot of coding needs to happen to achieve some minimal real progress. No one in the management realized that this is another development project, which demands a lot of programming skills and resources (people). After almost 1.5 years, I still seriously doubt that they have a good understanding of the load of the task.
After about three months, my supervisor, who is also a very good friend of mine asked a simple question. "Do you think we would be able to make it by the end of the year if we go in this pace". This let me re-think the whole progress and the target I would achieve at the end of the year.
By that time, only one test case was done. I had managed to ramp up another colleague, the one and only resource I had for sharing the work (only if he was free of other tasks). He was struggling to catch up with Java, and not so enthusiastic because the company is not Java based, rather PHP based. When we got into any Java specific issues, none was there to help. Another major risk was the entire product, the web application, was being re-written using symfony framework at that time. So, the product was changing. One traditional rule in Automation is "Not to Automate Against A Changing Product". The product has to be stable, before starting automation. So, by the time I write another ten more test cases, most probably the entire module would have been re-written making the automation code outdated.
Given all the above facts, I decided this is not the way. This prompted me to go for another solution. I'll explain that in the next post.
No comments:
Post a Comment