A project manager is always surrounded by project priorities falling in financial, logistic, people related, technical, machine related and many more categories. Each category is important and critical for project performance and enhancement. In each category, priorities will be set in different segments. There would be top most priorities, most critical priorities, less critical priorities, and may be sometimes non critical priorities.
So far so good but so many critical, semi critical, non critical and many more kind of priorities revolving around you will not let you work smoothly and perform consistently. The best way is to find out a method with which you are able to tackle all these problems without any hiccups and in an painless manner. How to do that? The best way is to arrange them in a sequential manner. You know very well – an elephant can never be eaten in one go. So is with priorities. Although those all are priorities but can’t be focused upon or taken into hand at the same time. There has to be some way out.
Once you have prioritized your priorities – take top 3, and forget rest of them for a while. Once you have only 3 priorities in front of you instead of a large pool, you will psychologically feel relieved and will be able to focus on all the three. Take first priority, find out the best possible solution, allocate it to the person whom you know will be able to perform it in your prescribed manner, give him a target date and set him free.
Do the same with rest two. And then go to your larger pool, pick top three…
This is a review of C++ Primer, Fifth Edition, by Stanley B. Lippman, Josee Lajoie and Barbara E. Moo, available from Addison-Wesley Professional. A complimentary e-copy was provided for this review.
It is important to understand what additions have been made to this book (and the language itself) as compared to the earlier variants. Since the inception of C++, a huge number of programmers have learned this language and benefited in one way or another. While earlier variants of C++ focused more on extracting machine efficiency, the latest version is all about making enhancements to programmer efficiency.
Some very important changes were incorporated by the C++ Standards Committee in 2011 and there was a major revision in ISO C++ Standards and Guidelines. Primarily, with these changes, the focus is on making C++ more universal so as to enhance its adaptability, reliability and stability. There is also emphasis on making C++ standard libraries more versatile, powerful and safer so as to increase their usability. An important point of these revisions is to ensure that programmers become more capable in writing abstractions and libraries. The C++ Primer covers all the important factors emphasized in the latest ISO C++ standard.
The new features making C++ 11 what it is are very well explained here, and the book serves as a good guide for any programmer. In particular, it covers features like ‘auto’ for type inference, smart pointers, and move-enabled containers, all of which enable a programmer to write their own customized classes without any hassles in an easier and more organized manner.
Any Project has high or low level of encountering gaps during its entire lifecycle. High or low will depend on how strong shield is built around the project to anticipate those gaps in advance and ensure getting them filled as soon as they occur during any phase of the project. There can be different forms of Project Managers for managing these projects. One kind will just burst out the moment a sudden gap is encountered during a project which was not anticipated in advance and will try creating hue and cry out of it.
This first type of Project Manager will just keep cribbing about the gap encountered thus making it more disastrous and deadly than it could actually be. If the focus is not gone on filling the gap that has just emerged out, probably the risk increases and it could cause more disaster if given more time to survive. On the other hand we have a small breed of some intelligent kind of Project Managers. This breed is not too worried about encountering any uninvited gap as they are well aware that these kind of scenarios do occur in project lifecycle. They, would rather, immediately assess different ways of filling the gap that has occurred suddenly and decide about the best of the solution out of those worked out.
And once the best solution is identified, its implementation/ action gets started immediately so as to fill the gap at the earliest and reduce the risk life. The higher is the
In any project prior to its development, during the initiation phase, risk assessment, analysis and mitigation planning is done. PM office, Project team, external stakeholders including the end customer management team members all become the part of this committee to work out and cover all possible areas from where any kind of risks can arise. Once all risks are listed down, their priority or severity is set based on their chances of occurance, gravity of impact on the project and time it would require for its mitigation.
Mitigation of each risk is a cost. Similarly each risk has an impact on project cost also. Hence there is a cost that is getting impacted by means of project delay etc. and there is a cost to overcome or mitigate this kind of delays. If cost of mitigation of a risk is higher than the cost of impact, nobody would like to invest in its mitigation. It is always true that higher is the impact cost, higher is the severity of the risk. And hence higher are the chances of its importance for mitigation.
After all kind of exercises of risk assessment, mitigation planning and management; there is always a hole from where unwanted rats always slide in, unstintingly. And you have no choice other than fighting against it, finding out quick ways to mitigate it and resolve it so that it has least impact on the progress of the running project.
Following parameters may be kept in mind while going for selection of an automating testing tool:
1. Cost: Cost of the tool should be clearly justifiable with the number of projects in hand, foreseen to come in future, cost of projects in hand and those coming in future. There is nothing wrong in looking for open source tools provided you have courage to go in depth of learning and adaptability.
2. Team Size: Large team size of developers vis-à-vis negligible testers is a death trap. You certainly need an automation tool else you will certainly require to increase number of testers.
3. Right Tool Selection: You just can’t go and adopt any tool just for the sake of having an automation tool. There must be criteria of choosing right tool for right kind of product to be tested. All tools do not fit for all platforms.
4. Usability: Team who is going to use that tool must be comfortable in using it. It must be easy to operate, clear in understanding and least cumbersome to operate
5. Recording: An automated tool without recording and playing back provision is useless.
6. Manual Skills: Any kind of automated tool will require manual skills in terms of team member having capability of writing manual scripts to be embedded in the automation tool.
7. GUI: Prefer to have a GUI based tool where things are easier to handle and understand
8. Reusability: The tool should be able to build a library in an intelligent manner where it is easier to pick a script to be reused for similar kind of testing at a later stage on the same of different product.
9. Maintainability: Tool should be up and running for long. It should not die at a shorter length.
10. Community: You never can master a tool, whatsoever you choose. You need a community to share your achievements, pains, feedback, suggestions, and so on.
We all have certain amount of myths within us and sometimes we start loving to live with them. A developer’s job is quite critical in any software development project as this is the guy who is doing all ground level work. Whatever he produces goes to the customer though after passing through testing phase.
Understanding the customer requirement is most critical for a developer even if he is master in coding. All excellent developers do not turn into successful ones dues to this factor. It is not bad living in myths if those are positive ones and have a narrow gap with the reality. The higher is the gap of a myth with reality, more difficult it becomes for others in the team to digest and ultimately if might produce a negative impact for overall project.
If we try finding out 5 myths of a developer that could turn dangerous for his own career could be listed as below:
1. I am supreme and am not bound to produce any bugs in my coding. Once this feeling chips in, developer starts negating any improvement points required for his coding and all bugs though get fixed by him but keeps him working carelessly.
2. Tester is just there to find out faults in my coding. If intentions of a tester are doubted by the developer, then probably he will not be able to take his feedback positively.
3. I must write a code that keeps my team dependent on me. Coding in an unstructured manner is a crime but some developer love doing it.
4. I can steal this code as I am writing it. This is unethical. Whatever a coder is writing, he is being paid for it.
5. Keep provisions of code going haywire with a future timestamp? This is a crime.
This is a video by ProjectManager.com and presented by their Program Direction – Jennifer Whitt, PMP. The topic is – Learn 7 steps to avoid project closing pitfalls and be left holding the project bag. Basically whatever is done in a project is for the successful closure, closure sign off and commercial closures. The whole journey of any project is based on certain pillars to make it stand, run and reach to its destination. First you have a look at the video and then we discuss few points further down the line.
Inputs, Acceptance approvals, documentation may all appear to be quite simple procedures and small activities but in real life these are basically the activities that if not done smoothly choke the progress of any project.
India has achieved its 100th Space mission and it makes India as a strong contender one among the top technically strong nations across the globe. India in fact is a unique example of absorbing so many cultures, so many castes, communities and so many contrasts complementing and supplementing; and making the whole nation as successful in various streams.
The same zeal and fire is required in a project manager who must understand the wider and long term goals without bothering about short term hiccups and criticism. Let us celebrate the day and move in the direction of managing projects with a higher level of responsibility and authority.
Your qualities are unacceptable as long as you don’t vet them yourself. Your value is ignored as long as you do not accept it yourself. The moment you realize your real value, you will wonder, that everyone else also becomes aware about it. Doing ordinary things in ordinary fora but even in ordinary projects you can manage or handle things in extraordinary manner so as to bring it to new achievements or heights. Doing same things in same manner endlessly will make you mechanized, inhuman and brainless entity.
IF you carry your brains with you, you are supposed to do small innovations in all aspects of life. A project will always have a scope of improvement in its various stages. Watch this video completely to understand what I have said above:
People who fear in life does not mean that they fail in all aspects of life. But keeping a fear in mind out of certain failures can hamper your progress, growth and success in a bigger way. It may become a mere showstopper and block all paths of your life intended to take you towards success and growth. People who do not fear in life for failing or making mistakes have higher tendency of doing extraordinary, amazing and out of box.
Every project will be a hit, success and finish in time is a misleading concept. There are issues – bigger or smaller – in any project. Running away from problems or failures will not let you each to your destination. Watch this lovely video of less than 2.5 minutes that will give you some energy to stay away from fear of failures.
A Project manager is supposed to lead some teams namely – development team, implementation team, Business/ Requirement Analysis team, Quality/testing team, Process team, support team and so on… Though these teams will be having their own respective leaders (or managers?) but a real LEADER at the top edge of this triangle is a must. There is a big difference between a leader and a manager. Manager is the one who manages, leader LEADS.
Enjoy this video which is quite inspirational, motivating and will definitely fill some real knowledge on leadership.
Why a project fails? It is quite an interesting subject to ponder upon and introspect if you are a project manager. In real life everyone is a project manager irrespective of what role he plays in professional life. We all have to manage multiple things most of the time and success of what we are trying to manage is very important to progress in personal and professional life for all of us. Now let us look at various roles a project manager has to perform during a project life cycle. Have a look at this lovely video:
The life of a project (project initiation) starts with something known as Feasibility Study. And then life begins to look at resources for everything that is about to happen in the project. Resources for feasibility study, resources for development, resources for deployment, resources for hand-holding, resources for training, resources for post implementation support and so on.
At each step of project you move ahead, or rather make any move, based on certain set of assumptions. Assumption that the team built for the project is perfect. Assumption that projected timelines will have no variance. Assumption that design will perfectly match with what customer is dreaming of, Assumption that this project’s success will pour in many more projects…
This video, which is of less than 5 minutes duration takes you through a complete project, stage by stage, making you part of it.
This is a good piece of video on Youtube titled History of Project Management. It is quite interesting and though provoking kind of video that seriously tries to provide good amount of information on how project management could have begun years back. What made it happen? What could have generated the requirement of project management? What could have been the starting point of project management? How Project Management got evolved?
Was it PERT, IPMA, PMI, PMBoK or was it something else that created the need of its existence? Was it GANTT in 20th century or it had taken birth way back in the days of Giza Pyramids. Probably Giza Pyramids is the best example where one can see well structured and matured project management in place. Have a look at following video and put your ideas right about the subject, in right place.
Just enjoy this funny video and check if this is what mostly happens while managing projects
You will really enjoy this video published on Youtube that very crisply conveys its message on the gap between the communication arising due to different nations having different ascents for speaking even the same language – say English. This is what actually happens on overseas projects. Having a good vocabulary, speaking power or ascent does not do as good as being versatile and smart to grasp your client’s style of communication though talking in the same language.
Have a look at the video below, that is lovely and crisp enough to convey its message about how to convert all your communication during various project phases into effective and result driven communication. This is a small video, not more than 1.20 minutes but is strong enough to convey its message clearly. Have a look:
This is a video I found on Youtube and though it is a promotional video about some company assisting in Project Management, but video has an example showcasing a project management team headed by project manager Zack. He experiences different ups and downs and different kind of people during management of his projects. The video tries to highlight certain magical project management skills required in a project manager so that he is able to manage his project well.
Here it is, enjoy the video:
Hey Guys! While exploring in the ocean of videos called Youtube, I managed to find another good video that was educative, informative, guiding and humorous all at the same time. It is focused on some of the very important aspects of product development or production. Customer requirement is most important aspect of any project – be it production or service oriented. Both ends while understanding customer requirements should be very clear about finalizing business critical issues that are required to be issued in the product or service in question.
Once customer requirement is clear, any outsourcing or in-house development requires some material and resources. It is very clear to get these material and resources in place in time so that the planned development goes as per schedule and resources are well utilized in order to achieve success in developing right product first time. Higher the rework or bugs in the product, higher is the wastage in time and resources and eventually high risk grows in terms of not being able to deliver to customer as per committed datelines.
It becomes very important to streamline and follow processes so that optimization is attained in cycle time, production and defect free delivery. Logically it is not only the project manager of the product manager who drive the project or product but involvement and commitment of each and every member of all teams becomes equally important.
This is a lovely video on TOTAL QUALITY MANAGEMENT (TQM) produced by by Rafael Cravioto Torres. It makes you understand well in a very simple manner on all aspects of TQM, the factors responsible to promote it in any organization and some factors on the other hand that demote it or do not let it happen within the organization.
I was just browsing through some quality related videos on Youtube and found this lovely piece of video having a length of approximately over 10 minutes but is quite interesting to watch patiently and think about how we keep working in our day to day life tasks wasting so much of time. It demonstrates a simple task being done by 6 persons as a team in two different ways and that is what makes a difference in the way we think and perform a task assigned to us.
TQM means Total Quality Management and is having no limitations for optimization of performing any tasks in work area (or personal life) in an optimized and best possible manner. This video was made for TQM training to be imparted to final year students of Edinburgh University. Its purpose was to ensure that the goal of training to students about teamwork, optimized manner of performing tasks, exploring different ways of working on the same problem, redefining process, reducing defects and striving for never ending improvement. This video was directed by Eric and produced by Stuart.
It forces you to introspect on optimizing any process by reviewing the current cycle time and process. Synchronization of Production, Cycle Time, Team Size, Process and Desired Results is very important for optimization of any process to increase results.
The same concept can also be applied in Software development lifecycle where different teams of varying size work on a product that is under development.
Logically it is not Quick Test Professional (QTP) versus Open Source Testing Tools but I would rather say it is a comparison between paid/ costly tools vis a vis open source tools which are supposed to be presumably free of cost tools. There can be a number of differences between the two categories that can be listed down based on technical capabilities of these tools, commercial aspects and overall procurement and support function.
Following differences can be listed:
1. Paid tools are Paid but Free tools are Not Free: Paid tools have a value tag attached to them like QTP has a value imbibed with it and depending on your needs of test automation, the final cost is evaluated by the vendor.
2. You have a visible person in picture working with a particular company authorized to sell that specific paid tool.
3. If you plan to go for a free tool, think twice before you ascertain that if you are quite capable of managing the show on your own – go ahead. But if you need an assistance, you will be wasting a big amount of time in searching for a suitable capable party who can download the tool on your behalf, customize it for you and make it run for you with all kind of support required.
4. Support in real time for paid tools: You have a vendor to whom you have paid for tool, got it deployed at your location and may be bundled training on that tool also in the deal. You will have a well defined support level bundled in the deal to make it a safe deal.
Test Automation has become predominantly and unquestionably a ‘must’do’ entity in project management, especially of larger size and involving higher stakes. Scenarios are changing at a faster pace from legacy, orthodox, out of date waterfall model of testing to ‘quick to attain perfection’ in smaller pieces based agile methodology. Everyone around the globe, engaged in software development, must be aware of some kind or the other testing automation tool.
Even the organizations those are still not using test automation tools, do not indicate that their testing teams do not require any tool, or the test guys are not aware about the existence of automation tools. It merely might be happening in two cases – one, where the test team understands the need but has not been able to make management understand the need and importance of the same; two, management also understands the need and importance but is not able to justify the investment if currently the customer base is low; or product volume turnaround is lesser.
Note that test automation tools will never be able to replace manual testing completely. There is nothing called 100% testing automation. There needs to be manual testing component in all kind of testing, which has its own importance and need for existence. Only thing is that now the test automation and manual testing has to exist in right proportion so as to do full justification with the product testing and thereby producing an ultimate bug free product at the end of the day.
A manual tester might not be the perfect guy to perform automated testing and vice versa.
There is a lot of information that floats and flows between top management and customer management. Even though some of this information might not be directly linked to the project but might impact seriously on the growth and progress of the project thereby marring the tempo and momentum despite all good efforts being put by various project teams engaged in the project. These scenarios generally arise all of a sudden, out of blue, unexpectedly; but there is no point in hiding or overshadowing them.
One classical example of this that has happened in real life is decision of deploying an ERP in the organization, change in top management key members in a short duration, decision of deploying the same ERP put on hold for a couple of months and ultimately reversed. And during all this period when management at both ends were aware about this situation and rising clouds over the fate of ERP, Project teams were not at all informed about the same and hence finally all these efforts went into a dustbin.
Some fool in the top management who knew all these changes happening in the management of customer side, still was hopeful that this project will not get shaken at all inspite of getting such indications from customer end. The project teams especially the development team sensed decline in relevant information flow from customer’s key users who were aware of the final fate of project by that time.
Had top management took a wise decision of putting the same project on hold till things getting clearer from customer end, and deploying teams elsewhere on other project; it would have been better in terms of financial results and performance.
Project manager has to be a versatile and universal kind of entity in an organization rather than limiting him/herself to a particular department or specific focus area. Project Manager has to be visibly an overall scale predicting the progress and health of the project. He has to be informative about all round progress of project even from the corners where relevant activity has ended or is yet to start. It is not that start happens only when it visibly or apparently appears to start, it starts much before that.
Taking all this into consideration, a Project Manager has to act as a radar or high frequency antenna so as to keep capturing relevant information related to project automatically or to a large extent without much of an effort. This can happen only if Project Manager takes care of his/ her important and regularly to be monitored/ reviewed touch points from where all important pieces of information will come through. By joining thread of these various pieces of information, project manager can attain very useful analysis about the progress and health of project.
Thee Critical Touch Points for Project Manager are:
1. Customer: This will be the source of first level of information that will be raw, useful and foundation of product in asking.
2. Management: It is important to understand management goals and vision prior to setting your own goals for any project.
3. Quality: This is the area which needs to be focused upon carefully. The guys should be set free to raise any kind of query related to customer and product that may turn out to be a bigger introspective point for management to look into.
If, for any kind of project, focus on three important areas when put right since the beginning of project; might help in attaining desired results and outcomes in appropriate, timely and within budget targets. The logistics are not mentioned here in terms of their importance as I feel all of them are equally important in order to drive a project successfully. Irrespective of the hierarchy they have been mentioned below, understanding and adherence is more relevant.
Three logistic points of any project management can be listed as:
1. Information flow from Customer: It is very important to keep a continuous information flow from customer end regarding their business requirements, changes required, enhancement perceived, and expectations from the new project in terms of deliverable, value addition in business and processes etc.
2. Customer Requirement flow to all concerned in Project: It is not only development team that is demanding customer requirements to be built in within the product. It is quality, implementation and any other stakeholders for whom this information is a good source of introspection and product logic discussions.
3. Internal flow of documents and information: Code is not a secret entity within any organization engaged in development of a product for a customer. It needs to be shared among various other teams (other than development team) so as to get them the flavor of product in the building process and hence prepare their relevant tasks accordingly. It might become a handy and useful tool for teams like QC, QA, Implementation, Deployment etc. so as to prepare accordingly.
Measure what is measurable and make measurable what is not. ~ Galileo Galilei
A code is always testable. large of small, but each piece of code that is catering to a specific need of the business must be tested thoroughly. A small piece unattended may spoil the whole product.
If we always do what we’ve always done, we will get what we’ve always got. ~ Adam Urbanski
If we keep doing the same thing the same way, we keep getting what we have already got, nothing more nothing less. That is why Change is must, in process, in product, in testing, in development – in everything. Change can get you ‘better than previous’.
“The starting point for improvement is to recognize the need.” – Masaaki Imai
Unless and until you know what is to be changed, you will never be able to get the optimized product. It is something like if you are not able to find a bug in a product, you will never be able to find out the actual defect and hence the improvement that is required in the product.
Like tools, mind also gets rusted if not used regularly.
Failure is only the opportunity to begin again more intelligently. ~Henry Ford
Everything can be improved. ~C. W. Barron
Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. ~Peter F. Drucker
Professionalism means consistency of quality. ~Frank Tyger
It is quality rather than quantity that matters. ~Lucius Annaeus Seneca
Heineken is one of the prime brands in liquor industry and one of the top beers sold across all continents on the globe. The whole credit of success of this Dutch beer brand becoming most popular across the globe goes to its founder Freddy Heineken. Freddy used to be too conscious about the quality of the product rather than focusing on producing in large volumes. He never let his success spoil his quality conscious mind and was always used to get disturbed even for a single quality issue arising anywhere in the globe related to his product. He used to take any bad bottle of Heineken as a personal insult to him. And that is what makes him a great successful businessman.
Philip Crosby gave a different perspective on Quality. He wrote – “Quality is free, but only to those who are willing to pay heavily for it”. Quality is not given and deemed by everyone. Quality has more relationship with conscious rather than anything else.
Mahatma Gandhi always emphasized on the quality of work rather than quantity of work. He wrote once that it is the quality of work that will be easily able to please God rather than the quantity of work. A Programmer if takes a learning from here can go a long way in building bug-free code during his career. Usually programmers are more focused on quantity of work, to demonstrate their capabilities to their seniors. They have a mental blockage in doing work faster and finishing it in of before time and in turn might compromise with the quality of work they produce.
John Ruskin in one of his writings indicated that there is always a scope of compromising with the quality of a product. A product can be picked, compromised with its quality and then can be sold in the market at a cheaper rate. What it really meant was that a compromise in quality, or by making a product little worse, its value can be degraded or lowered and then it can be sold at a lower price in the market. But in software industry, all those companies those tried to follow it, failed and vanished over a period of time.
“Quality is not an act. It is a habit. – Aristotle 384BC-322BC, Greek philosopher and scientist, student of Plato and teacher of Alexander the Great”. This great philosopher, scientist, learner, student, and teacher from Greece knew decades back the secret of quality what even the current era quality gurus are not aware of. Ignorance is a bliss – it is said, but is applicable for fools only.
Quality requires additional sense. Quality comes from heart. Quality has to be in blood, has to be habit rather than acquiring it off and on. A person who becomes a quality analyst, quality control, or quality assurance department has to quality conscious not only in particular projects or products but in all aspects of his/her life.
How many of you guys belong to quality related job and wear quality specialist jacket only at work place?
: It it not good to fail in all your projects and in achieving your goals. But it is inevitable to avoid failures or delays at times. This can happen in any kind of project and at any stage of the project. One bad habit that is counted as good is the ‘Passion of Winning”. Everyone has an urge to win in life. But few are there who are passionate about winning always. There is a good quote I found somewhere whose author is not known. It goes like this: “Good decisions come from wisdom. Wisdom comes from experience. Experience comes from bad decisions. ~ Anonymous”.
This is an excellent quote that fits into all times and eras. We do take decisions in our day to day life, whether in projects or in personal life. All decisions do not go in favor. Sometimes some decisions do large amount of harms that result into project disruption, delays. Wiser men do not let go this opportunity waste. They do learn from the bad decisions taken and their impact on project. This experience if carried forward in further projects and decisions come too handy in going right next time. Such experiences make you wiser one step further every time.
Sounding good or bad, but in my opinion, a software project resembles making love or having sex. There are many similarities that can prove this verbatim. Let us look at the resemblances:
1. Mental preparation: You have to be mentally prepared to achieve your goals and set your milestones. Clear vision and urge to achieve mission is the ultimate goal in your mind in both the cases.
2. Physical Vigor: Without having strength to achieve what you want to achieve, target setting has no meaning. If you assign a bigger task for yourself, you need to be physically prepared for it.
3. Passion: Having both above, and not being passionate about your goals, it is going to hit you badly from both perspectives – yours and the other party.
4. Achievement: Achieving stipulated goals in estimated time is very important. You can’t relax in between even if you want you. Delayed response may end up in no enjoyment during the journey.
5. Respect: Give respect to feeling and requirements of both the parties involved. You just can’t keep on singing a song that is boring to the ears of other party.
Hey guys, this is not a technical video attached here in this post. This is a waterfall in a place called Panchkula near Jammu in India. This waterfall video I have watched n number of times and every nth time I watch it, it strikes me of the situation of quality of software that is still in a sorry state in many of the software organizations. Many software development companies are still scaling quality at a lower mark and find their entry in the picture only at the time of completion of development of product.
Waterfall sometimes reminds me of a well organized development team engaged in a project in which they are supposed to develop a business suited product that is meant to cater to the complete business cycle. The business analyst prepared a well structured thick document signed by all stakeholders to vet that yes, this is what is required to be built in the product. Development team is handed over the document with expert comments of project manager and a timeline stating when the product is supposed to get ready and when it is to be handed over to the testing team. Well so far so good, the document has not gone to testing department. They are not aware about the business requirements of the customer and neither are they aware about the beginning of the development of the product.
One fine morning, Project manager reviewed the product and found it okay to be handed over to testing team for finding out the shortfalls.
Is this the biggest shortfall in itself?
This new book on QTP for Web Testing is a simple, crisp and a must read for all beginners, novice and experts in the field of software testing. I thought of producing and making all testing guys aware about what all experts are saying about this book – “Technology Specific Guide for QTP” written by Aditya Kalra and co-authored by Timothy Rajan Alex.
This is Joe Colantonio – an expert in test automation tools and is helping all testing guys across the globe through his website by providing latest tools, tips and expert advice in this field. And if an expert is praising about this book, it means a lot. According to Joe, the book is a bouquet full of roses for all QTP learners at any level of their expertise or career. As per him the book, if read thoroughly, is bound to make an individual expert in the field of QTP for test automation. Joe, though using QTP since its launch, has had lot to praise for the book, in terms of learning something new from every chapter of the book.
Sivasankar Jayagopal is one of the Senior QA Managers in Adobe Systems and is happy to see the content written in a very organized manner to cover almost everything that QTP potentially is capable of.
Shalaka Dani, Program Director of MindTree shares his idea about this book by confirming that the content has been chosen quite seriously, full of examples and in a very easy to understand manner.
Technical review of this book has been done by Sandeep Laik – published in the beginning of this book. Sandeep is an end to end test engineer for Unilever Project working with MindTree.
Hey Guys, another attempt to present my one of the earliest blogs in a video. If is not very much different in terms of context of the article but listening to a song and reading its lyrics, makes a big difference. I am not sure whether this attempt is good or not, probably you guys would be the right judge to pass on your opinion openly without any hesitation.
Here is the video:
Hi Guys, This is basically the video version of my long back posted article here on IT Knowledge Exchange website. Probably that is one of my earliest blogs and it got quite popular among readers belonging to Project Management, Software Projects, Quality Assurance, Quality Control fields.
Here goes the video that is published on YouTube:
The book is precisely of 200 pages, if you include the last 2 pages meant to jot down notes. It is a well written, well titled, and crisply sequenced book written by Aditya Kalra and Timothy Rajan Alex. Aditya or more popularly known as Ady among his friends, is carrying a little less than 4 years of rich experience in software testing in companies like MindTree, Fidelity and JP Morgan. Currently he is Test Automation Architect in J P Morgan, Bengaluru.
Ady started his career as Test Automation Engineer and very soon climbed the ladder to reach to a height with a new title – Test Automation Architect.
Timothy, co-author of this book, is has a great journey so far in test automation in companies like – Keane, Sapient and Adobe. Currently, he is Automation Tech Lead in Adobe Systems, Bengaluru. Having an excellent experience of over 6.5 years, Timothy is a thorough professional naturally equipped with software testing skills. Starting his career with manual testing, he has excelled in both flavors of testing – manual and automation. By now he has got an expertise in developing any number of variants of automation frameworks – be it open source, or commercial one.
Timothy is as passionate about testing as he is strong in technical skills in software testing. He has mastered and specialized in Web and Windows based applications – JAVA, .NET, SAP, VB – using different tools at different times – HP’s Quick Test Pro Automation tool, Selenium 2.0 (Webdriver), TestNG framework and so on.
1. Change in priorities are always a big hurdle in a project
2. Change is not always good
3. Change does not always brings in good
4. Change is good to avoid at times
5. Change in priorities will boost one project but at the cost of many other ongoing ones
Any project if goes well and ends well keeps drawing stakeholder’s attention during its lifecycle. This attention drawing goes all in positive manner, cheering teams, glorifying moments of milestones’ achievements, project completion etc. It might go other way round also in a way that it does draw everyone’s attention but this time, in a negative manner. Milestones not achieved in time, repeated number of times, teams getting demotivated and demoralized, management losing hopes over completion of project, most of talented people looking out extensively for another job.
If it is later, the situation is not too good for any of the stakeholders. If some of the stakeholders are not getting affected due to these adverse conditions, probably they are holding fake keys in their hands. It is well evident that it is team that makes any project success or failure. A single person may put extra energy or efforts in a project to drive it faster, but a project cannot fail on the whole merely with the wrong intentions of a single person of the team.
There is a big difference between mistaken happened due to ignorance and intentional mistake. A sensible person if makes a mistake ignorantly will learn a big lesson from it and shall never dare to repeat it. Repeated ignorance can be treated as bad or harmful as a big mistake done intentionally to harm project progress in a big manner.
Change in requirements does happen frequently or infrequently depending on the acceptability level of development team. It also depends on how tightly activities are planned and milestones are being monitored. At times there are certain changes that come right in the middle of a project but shake the progress in a big way. It might happen that the changes are inevitable and may nullify all efforts done so far at both ends.
In such a case there will be a fresh start with a valid reason and justification. Such changes are driven by big and usually external forces. Some of such factors are listed below:
1. Economic downturn: A big deal got undone due to certain reasons thereby shaking the anticipated inflow of funds over a period of time in a negative manner will definitely force management to think twice why they should not stop investing big amount in an ongoing project. Why not shrink requirements to save the larger chunk of investments in the project at a later stage when inflow gets stabilized.
2. Political imbalance: It is not about national or international politics. It is about politics that rests within an organization. An imbalance occurring due to any reason may impact the requirements defined for a project to a large extent.
3. Change in top management: This change at the bottom layer of sea and top layer of management usually brings a hidden storm within itself. The changed brain starts impacting existing brain by infusing ideas to mold them in a different direction. An ongoing project could be a classical example of this.
Change in requirements is not an unknown phenomenon in any kind of project. In software development it is rather happens more frequently. The adaptability of asking for such changes from customer end and accepting such changes at vendor end is quite higher and syncs well to such an extent that when a project has overshot budget or planned timeframe – neither of the two get to realize until it becomes too late for both of them.
There could be many positive and negative factors that control demand for changes during an under development project. Some of the top negative factors can be listed below and if these are controlled well during any project; probably success rate of projects will go higher by 50% from current level of failures:
1. Lack of involvement: Requirements have been given at the beginning of project and a sign off of requirements has happened; hence nobody from customer end is required to vet those requirements getting translated into code.
2. Lack of seriousness: At times project gets imposed on customer end users without them taken into confidence and therefore they might not get involved in the project with all kind of seriousness.
3. Lack of Interest: A key user sitting at a high level might have been ignored in past by management and hence just to take revenge; the key user may keep low interest in the project but keeping full care that it does not smell out in the air.
4. Shortage of time: Key users are given this important task of defining and managing business requirements in the project but along with are engaged in many other equally critical activities thereby leaving them with no time to be sincere with the project.
5. Change in strategies: Management at customer end may have change in strategies at their end thereby pushing the ongoing top priority project to a lower one and hence change the prepositions for all involved in the project.
Developers are probably most creative group of people who keep themselves engaged in creating code all the time. Since perfection and human beings are some steps apart in whatsoever is done by human beings, there always is an urge found to strive for perfection. This is what makes them good developers. There are certain pre-requisites to attain that stage, lack of which may behold them to reach to that stage.
Top most reasons that hold good developers to build a bug free code can be listed as below:
1. Tight schedules: Tight schedules as such are not an issue for any good developer. But when it gets clubbed with certain more pulling impacts; the developer gets drifted away from developing extremely good quality of code.
2. Disturbing/ Tense atmosphere: This is what impacts a developer, or for that sake, any creative guy most. The developers need a non disturbing and cool kind of atmosphere around them so that they keep juggling new ideas in their mind and putting them in the code they are building.
3. Frequent interruptions/ Change in priorities: This is something that will disable any person for reaching to his goals. You start for something, change your mind for something else, or are forced to change your current work in hand with some other work; you are never going to attain your goals in life.
4. Lack of Documentation: This is something quite basic in nature but is not being followed for ages. Nobody understands the gravity of documentation and hence least attention is paid to this most important exercise.
5. Change in Requirements: Change in requirements is as disturbing in nature as change in priorities. It is usually done from stakeholder’s end and usually happens due to many reasons like – lack of involvement, lack of seriousness, shortage of time, change in strategies etc.
Whenever any application is used for the first time by a user, there is always a perceived notion in the mind of user on the behavior and functionality of the application. If the application being used for the first time behaves better than the expectations set in user’s mind, the battle is won; otherwise it is lost. Although it is very difficult to satisfy every end user by a single application, there are certain apps which have higher tendency of likelihood by its end user and hence such apps do well across the globe.
It happens in any kind of application whether it is based on client-server architecture or is a web based application. For web based applications some basic information, if is launched, along with the application; will help changing the preconceived notion of user from a wider spectrum to a specific pattern. Such information can be listed as below:
1. Browser Support: The web application, in whichever browser is opened, must clearly state the specific browser(s) on which it has been specifically built and tested.
2. Resolution: an application may play weird if not opened in proper resolution of the system. Hence it is important that the use knows well in advance about the best resolution for the application.
3. Limitations: Every application has certain limitations that are well known to its creators at the time of its launch. It is better to make user aware about such limitations so that he does not remain in dark.
4. Future Plans: If you let your users know about what enhancements you are planning, it will keep your users hooked to the app.
5. Feedback: A must have feature on every app to gather user’s feedback.
It was an astonishing outcome of project manager’s approach when I recently met with a group of project managers managing building of multiple products for multiple customers through multiple development and deployment teams. I started with a survey and as per my feeling most of them failed in that. The survey was focused on deriving findings on their approach, concern, belongingness, bonding; with end users.
It all started with a call from one remote end user who was facing difficulty in using an already launched web application. The screen was to add a new record and had 13 columns to be filled on screen-1 and 7 columns on screen-2. When it was opened by the end user, she could find only 11 columns and despite scrolling down, she was not able to see the rest of columns.
She approached the product manager and this guy remotely did something that she was now able to see the rest of columns. Wonderful though, but next day the same problem occurred to the same user. She approached the project manager this time. The project manager also did some jugglery and set the things right for her.
She could not understand what was wrong and what is being fixed by these two gentlemen that it all becomes ok. It was not at all a comfortable situation for her to work on that application to add any records further facing so many hiccups.
Can you just find out the missing pieces of this puzzle? Try and get back to me to see how many pieces you could find out.
Business applications are moving from client server architecture to web based. The design and usability have become predominantly necessity as strongly as earlier it used to be for navigation. Screen designs need to be dependent on browsers, resolution and focused audience. Microsoft, howsoever popular or widely used has been, still produces unexpected results for which there are no technical reasons. IE8 differs from IE9 and applications working fine on one, do not work well on other, if are not built with depth and knowledge.
Apps built on one browser do not work on others apparently producing lot of misbehaving results. At times there is an incompatible issue that needs to be addressed has to be brought into compatibility mode. Howsoever advancements technology brings in, the issues keep arising in one shape or the other.
Some important factors that need to be taken care of while building a web based product must have following basic factors:
1. Understand web audience well before starting designing of product.
2. Your users are much smarter now as they are not limited to the office boundaries and using only the product hosted on in-house servers.
3. They have understood the strength of web and must have tasted lot number of web based applications before they will start using it.
4. Current day end users are quite tech savvy and well versed with web apps and their strengths.
5. You can’t give illogical or absurd reasons of certain things not happening in the app which are well done in other products on the web. Tools and platform can’t be held responsible for such actions.
Team composition is one of the most critical tasks in any project. It if not the count of people that matters but it is the experience, level and maturity of team members that is to be focused upon while selection of members. Members with more open mind and fewer egos can do well as team members even if they are slightly short in knowledge than other members who have personality otherwise.
The strategy of team composition is highly dependent on the size and nature of project. A large sized complex project would require a higher level of strategy formation as compared to a small sized and simple natured project. Though it would be a misnomer that complex issues do not arise in simple projects, there also it depends on the right formation of team and deployment of strategies. A very small product development project may encounter bigger hiccups if the team composition is not done wisely.
It is better to delay a project for the sake of finding right kind of people rather than just completing the stipulated head count in the team irrespective of the skills and experience matching criteria assigned for the selection of candidates. Inappropriate composition of team members will always delay a project and on the other hand in a delayed project if right kind of people are included in the team, they would be able to cover up the time and milestones achievement backlog.
4. Milestones identification and achievement: Any project definitely needs perfect identification of milestones. Milestones have to be achievable, remarkable and not too distant from each other. Unless you identify quick milestones to project to management that things are moving in right direction, quite visibly; management will lose interest in project and that may start impacting the project and teams involved.
5. Reporting: If you are doing good in a project, you should be smart enough to project it well, timely and accurately, to all stakeholders. The achievements are to be acquired and shared well in time if you want to enjoy them the most, else they may lose their gravity and impact.
So in a nutshell if we see, it is a right nix of all above points that is required to win over all hurdles in a project. Correct requirement gathering not only depends on right process owners to define the business requirements but also require wise guys who understand business criticalities and can read the mind of requirement spellers.
Team that goes for requirement gathering needs to perform some homework in advance before landing into the customer’s location. There are lot of information that can be collected and understood before meeting the customer.
Though it is difficult the assume in advance what kind of problems will percolate during a particular project but more or less all kind of problems faced during a project execution/ deployment/ management can be segregated in five top most reasons or categories. These generic segments/ reasons/ categories will be able to address all issues that are encountered during a project and if these categories are taken care of well in advance in a proactive manner, the chances of failure/ delays in any project get minimized and hence increasing the chances of success.
5 Top reasons can be summarized as below:
1. Customer Requirements: Capturing right requirement first time is an art and a science too. Business Analysts and organizations need to master in this so as to move ahead with crisp directions for development team.
2. Team Sizing: Estimation of right kind of people in team, with right kind of experience and appropriate count of them helps in creating an optimum team size. It could be difficult to do the right sizing well in advance but if customer requirements are documented well, identification of right roles and experience becomes much easier.
3. Team Management: Team management is an uphill task during any project. It is not only the technical aspects than need to be overseen but also the soft side of the personality of each of he individual in the team that need to be addressed to.
Wrong requirement gathering can happen in two ways – 1. The team assigned to collect that information from direct process owners at customer end are incapable to differentiate between picking up right thread and dropping wrong threads so that no confusions arise later. But this is the most critical job and done by least business analysts. And 2. The process owners at customer end are incapable to spell out the right kind of business requirements that need to be built in the new application in question.
This does not mean that the designated process owners are dumb in their roles or knowledge. It is the question of spelling out the right requirement where they might not be expert. Management’s and BA’s role (and experience) comes quite handy in such instances.
Customer needs a tree that needs to have green leaves and bears fruits every season and you documented to build a lemon tree that becomes a cause of failure at the end. Did you ask customer what season should the tree bear the fruit, what should the maximum height and width of tree, what size of fruit will be most suitable for customer, hard or soft fruit required, what are the maximum benefits to be drawn out from the fruit – juice, fibre, extract, sweetness etc.; is very important to capture right in the beginning so as to give maximum clarity to your development team that is well aligned with the customer real requirements.
After all it is the right information that has to flow in building of the application. If it happens RIGHT IN FIRST GO, nothing like it. It becomes win-win for both.