Reflection-Visualization

(Email as Service)

Shaik Paswan

Challenge & Selection

I lead End to End Software testing for large projects for one the major banks.  Like any team across software

development and testing industry, my team is constantly challenged with handling larger testing work scope

with limited team size, late change requests and lots of overheads when project is not running as per plan (late

software build delivery, infrastructure setup delays etc.)

Having gone through this course, I decided to come up with some innovation discussion with team that would

help our customers, projects stakeholders and my team as well.  We wanted to innovate something apart from

our normal KPI s of automation functional testing in applications we are involved in.

We decided Visualization as tool to come up with innovation where the project is not going through the plan

(overall status as Red and Amber). The objective was to do something better that will help customers, project

stakeholders and improve productivity within the team especially during the tough times.

Insight & Approach (What Is)

As a starting point we picked all the lessons learnt documentation where the team faced quite number of

challenges in completing the milestone within last one year. Rather than looking at specific incidents

pinpointing to certain flaws, the next objective was understanding common trends common unidentified pain

areas can be nailed down especially during the tight patch of critical delivery timelines.

A series of calls were scheduled with project stakeholders. The team divided into groups consisting of 2-3

members was given task to come up pain areas within themselves and project community.

After series on call, floating several sticky notes, few critical observations were made after series of calls  

1. The frequency of adhoc communication (emails & Teleconferencing) with project stakeholders

increased drastically as the project deviated further from the original plan. The majority of  communication was involving asking similar same set of status metrics – how much we have  completed, how many more to complete, key blockers and their action owners etc.

2. Triggering the automaton regression testing and sharing the respective result involved someone

to be at desk. By regression testing, I mean testing existing functionality just to ensure developer  has not broken something else while fixing a specific bug. This activity is required to iterated  large number of times at different inconvenient time zones especially for projects where large  number of bugs or critical bugs are discovered.

3. Many Business Analysts and Designers while reviewing specific testing details  needs to logon

to Defect ( code bug) management tool manually or need to dig up lots of emails if they needs  to find specific result of bug,

Insight & Approach - Continued (What If & What Wows)

The team has as such good experience of skills on automation of testing functionalities on software  applications they were working on. While learning through the pain areas, the idea emerged to  automate the communication areas so that 

1. They are less involved in adhoc communication and focus more on pain areas   2. The stakeholders gets the details instantly rather being dependent on the team  3. The productivity of team will be less impacted when Senior Management is looking for adhoc

details.

The team then thought of building the framework where they could automate 

1. Providing details of progress (right from High Level to Micro Level)   2. Trigger automation testing by development team   3. Provide adhoc specific details of testing.

After series to several brainstorming sessions, the approach was taken to use “email” as source of  automation. This idea was picked to ensure 

1. Automating this task should not involve any human interaction apart from triggering email   2. Stakeholders of various kinds (technical/non-technical )  could use this framework rather than

thinking of training on any automation tool

An example of what above means is, whenever required to run regression testing after bug fix, any  person within project just needs to do is send email to testing team and he/she  should get response  back with details. The received email on any of the testing team desktop should trigger automation  work in required work. The technical feasibility was studied and checked carefully across other teams  and we also got a framework to build what we were thinking of.

Prototype (What Wows)  

Rather than jumping directly making ‘cool stuff’ we decided to test our idea with Business Project  Manager, Designer and Development Lead.  We initially gave a walk through about the framework we  want to build and its advantages.

Later they were asked trigger email with certain keywords in the subject to one of my team member  who had a sample response already prepared and responded with 2 minutes delay.  The overall  approach really worked out well with feedback of what details they were seeking in automated way  and review system.

As a team we got a brilliant feedback to come up with this initiative and approach.  One of the few  compliments from Senior Management came up for the team as “This team is one of the most pro-active  and highly committed team seeking continuous improvement“.

My team has completed built of first frame work now which is covering regression testing and final  stage of internal testing before rolling out to project.

Conclusion

On several projects of various kinds, human pain areas may mostly not get documented. It is only the

systematic implementation of Design Thinking Methodology can improve business substantially or

even bring in disruptive innovation that remains key challenge for large organizations.


Reflection - Visualization ( Email as Service ) Shaik Paswan Challenge & Selection I lead End to End Software testing for large projects for one the major banks . Like any team across software development and testing industry , my team is constantly challenged with handling larger testing work scope with limited team size , late change requests and lots of overheads when project is not running as per plan ( late software build delivery , infrastructure setup delays etc . ) Having gone through this course , I decided to come up with some innovation discussion with team that would help our customers , projects stakeholders and my team as well . We wanted to innovate something apart from our normal KPI s of automation functional testing in applications we are involved in . We decided Visualization as tool to come up with innovation where the project is not going through the plan ( overall status as Red and Amber ) . The objective was to do something better that will help customers , project stakeholders and improve productivity within the team especially during the tough times . Insight & Approach ( What Is ) As a starting point we picked all the lessons learnt documentation where the team faced quite number of challenges in completing the milestone within last one year . Rather than looking at specific incidents pinpointing to certain flaws , the next objective was understanding common trends common unidentified pain areas can be nailed down especially during the tight patch of critical delivery timelines . A series of calls were scheduled with project stakeholders . The team divided into groups consisting of 2 - 3 members was given task to come up pain areas within themselves and project community . After series on call , floating several sticky notes , few critical observations were made after series of calls  1 . The frequency of adhoc communication ( emails & Teleconferencing ) with project stakeholders increased drastically as the project deviated further from the original plan . The majority of communication was involving asking similar same set of status metrics – how much we have completed , how many more to complete , key blockers and their action owners etc . 2 . Triggering the automaton regression testing and sharing the respective result involved someone to be at desk . By regression testing , I mean testing existing functionality just to ensure developer has not broken something else while fixing a specific bug . This activity is required to iterated large number of times at different inconvenient time zones especially for projects where large number of bugs or critical bugs are discovered . 3 . Many Business Analysts and Designers while reviewing specific testing details needs to logon to Defect ( code bug ) management tool manually or need to dig up lots of emails if they needs to find specific result of bug , Insight & Approach - Continued ( What If & What Wows ) The team has as such good experience of skills on automation of testing functionalities on software applications they were working on . While learning through the pain areas , the idea emerged to automate the communication areas so that  1 . They are less involved in adhoc communication and focus more on pain areas 2 . The stakeholders gets the details instantly rather being dependent on the team 3 . The productivity of team will be less impacted when Senior Management is looking for adhoc details . The team then thought of building the framework where they could automate  1 . Providing details of progress ( right from High Level to Micro Level ) 2 . Trigger automation testing by development team 3 . Provide adhoc specific details of testing . After series to several brainstorming sessions , the approach was taken to use “ email ” as source of automation . This idea was picked to ensure  1 . Automating this task should not involve any human interaction apart from triggering email 2 . Stakeholders of various kinds ( technical / non - technical ) could use this framework rather than thinking of training on any automation tool An example of what above means is , whenever required to run regression testing after bug fix , any person within project just needs to do is send email to testing team and he / she should get response back with details . The received email on any of the testing team desktop should trigger automation work in required work . The technical feasibility was studied and checked carefully across other teams and we also got a framework to build what we were thinking of . Prototype ( What Wows )  Rather than jumping directly making ‘ cool stuff ’ we decided to test our idea with Business Project Manager , Designer and Development Lead . We initially gave a walk through about the framework we want to build and its advantages . Later they were asked trigger email with certain keywords in the subject to one of my team member who had a sample response already prepared and responded with 2 minutes delay . The overall approach really worked out well with feedback of what details they were seeking in automated way and review system . As a team we got a brilliant feedback to come up with this initiative and approach . One of the few compliments from Senior Management came up for the team as “ This team is one of the most pro - active and highly committed team seeking continuous improvement “ . My team has completed built of first frame work now which is covering regression testing and final stage of internal testing before rolling out to project . Conclusion On several projects of various kinds , human pain areas may mostly not get documented . It is only the systematic implementation of Design Thinking Methodology can improve business substantially or even bring in disruptive innovation that remains key challenge for large organizations .