Thursday, October 31, 2013

My thought goes like ....


 My thought goes like ....

Agile! Agile is the solution for reducing the waste, we make in follow-up(s). Sometimes, we over-do follow-up to make sure we are getting the expected result on time. What a waste!
Agile relies on self-driven team. No boss-around from the bosses. The team is responsible for their work completion. This increases sense of ownership...team is well-organized, settled.

But then again, Lean or SCRUM?

Lean and SCRUM are mindset, thought process. This is not a short-term cost reduction program or short term idea of getting customer appreciation. It is the way company operates to create more value to the customer. Lean transformation is to how company changes their business operation from old way of thinking to lean thinking, reduce waste, come to zero waste.

SCRUM starts at the team, lean starts at the process. SCRUM talks about self organizing team. There are specific meetings in SCRUM (Stand-up meeting, retrospective), that automatically lead the team to take ownership of work. Team does the estimation for a work. So, if the work is not completed on time (I am thinking no major blocker), team is answerable. This creates value-system. Team will gradually hate follow-up.
Lean talks about set of engineering practices to reduce waste.



Tuesday, October 29, 2013

What is the biggest challenge in end-to-end testing, from test management point of view?

What is the biggest challenge in end-to-end testing, from test management point of view?

I believe it is co-ordination. I spend most of my time of a day in co-ordination and follow-up. There are multiple teams involved in multi-vendor system. Most of the cases, the team given to me is virtual team. Each team/organization has its own hierarchy.  So, my reach is horizontal, but in case of escalations, where I have to escalate on a person or team, I co-ordinate with management hierarchy. So, in this case, it is vertical.

Over the period of time, now I am proficient in verbal/non verbal communication, people management, escalation management, time management. And I mean it.

But, don't you think, with rigorous follow-up, we waste our time? For example, to get response from a tester on certain task assigned to him before a certain time, say 3 PM IST, I email the tester on time. Then I ping him on my expectation. I wait till 3 PM IST. No response? Again I pinged. The response comes as he was busy on a call/discussion. I give him 30 more mins. I talk to him to make sure I get the task done by 3:30 PM IST. This is a typical scenario.

How we can reduce this? Is it good to escalate to the tester's manager on the first place itself when I realize he failed to respond on time? I am afraid, escalations are becoming part of our life. I know few people, they will work perfect only escalations come, till then they take it easy.

Any out-of-box thinking to reduce the effort spent on follow-up?

Please leave your valuable comments.

Monday, October 28, 2013

Difference between test strategy and test plan


Today one colleague asked me an interesting question!

He asked me - difference between test strategy and test plan.

My answer was simple - test strategy talks more on technical aspect of testing and test plan talks about planning on how you manage the testing activities.

Test strategy can contain following:
1. Services/Program impacted
2. Applications/sub systems impacted and level of impact
3. Test objective
4. Test scope
5. Cross-release dependencies
6. Cross-project dependencies
7. Testing risks and mitigation
8. Test focus area
9. Levels of testing
10. Entry and exit criteria
11. Black box testing OR white box testing
12. Test Data Strategy
13. Test environment set-up
14. Acceptance criteria
15. Revision history

Test plan can contain following:
 1.  RACI chart
 2.  Requirements and plan to manage the requirements including test strategy
 3.  Testing schedule
 4.  Deployment strategy
 5.  Project risks and mitigation plan
 6.  Staffing and training plan
 7. Change management procedures
 8. Progress tracking proceure
 9. Defect tracking procedure
10. Test reporting
11. Revision history

However, few items may get interchanged based on company tailored process/templates, that are part of OPA (Organizational Process Assets).

Everything is hunky-dory? There are whole lot of information hidden behind each item.

What is program? What is RACI chart? What is test focus area? What are risks and what are mitigation plan? How a change is managed in real world? What is OPA?

Your wait begins till my next blog is published! Till then happy reading!

Please feel free to leave your valuable comments/questions.


Sunday, October 27, 2013

My first post was about defining End-to-End (ETE) testing

Well, my first post was about defining End-to-End (ETE) testing.

Next question will be what is the base document for defining ETE test cases?Isn't it?
Name of the base document can be anything, BRD (Business Requirement Document) or SRS (Software Requirement Specification) or JRD (Joint Requirement Document), but the document should contain business requirements (BRs). BRs are requirements collected from  multiple sources, in multiple ways. Sources can be end user who can explain he requirements and the underlying needs, can be sponsor or internal client, can be key stakeholders listed in stakeholder register. BRs can be collection of approved Change Requests (CRs) from multiple past projects or for example, BR can essay an actual required fix of a Severity1 defect found in past project. There is a possibility that this particular project was deployed and went live with some work-around of the defect, after managing "Go" vote from client. 
Requirement gathering techniques are also multiple:
1. Interviews
2. Workshops
3.  Focus groups
4. Brain storming 
5. Survey
6. Observations
7. Prototypes etc.

Normally BRs are written in non-technical language. BR document may contain Customer Service Scenarios (CSS). BRs are broken down into more technical CSSs.  The CSSs cover multiple applications, hence multiple interfaces of many sub-systems.

In short, ETE test cases should be written based on a requirement document that captures complete business requirements (i.e. functionality to be deployed across multiple sub-systems or applications) from start to finish. Since CSSs are more technically written, ETE testers may find it convenient to base their test cases on CSSs.

Please leave your comments/questions. I shall try to answer you all.
 

What is End-to-End testing

End-to-End (ETE) testing is certifying a functionality/business scenario that flows from one system/application to other. It is a functional, integration testing done through multiple inter-related sub-systems. End-to-end testing involves ensuring integrated components/sub systems function as expected.

The entire scenario is tested in various test levels and in two broadly categorized environments- Pre-production environment and post-production environment. Pre-production environment is test environment - platform before code in deployed. Post-production environment is real-world platform where the flow is tested for few days/weeks (within the warranty period), after project is deployed.
In short, ETE testing is not individual application system testing. ETE testing is next test level after system testing. There are external interfaces to be tested. Dependency management and co-ordination among teams become inseparable component of this type of testing.

For example, consider ETE testing of a Telecom Service.
There can be one or multiple ETE flows impacted in a project. In that case, ETE testing can start from Sales/Marketing application(s), can end at billing application(s) or service assurance application(s). The flow may get tested from Sales application->order management application till Network provisioning application OR Sales application->order management application->account creation application till billing application OR Sales application->order management application->Network provisioning application till a service assurance application.

Challenge? Yes. The biggest challenge is- the ETE tester should have knowledge of complete ETE system as well as sub-systems.

Please leave your comments/questions. I shall try to answer you all.

The purpose of End-to-End Testing is to exercise a complete production-like scenario. Along with the software system, it also validates batch/data processing from other upstream/downstream systems.
Read more at http://www.guru99.com/end-to-end-testing.html#wmqEuYwEmSLxobFt.99
The purpose of End-to-End Testing is to exercise a complete production-like scenario. Along with the software system, it also validates batch/data processing from other upstream/downstream systems.
Read more at http://www.guru99.com/end-to-end-testing.html#wmqEuYwEmSLxobFt.99