I recently observed a website while randomly searching for something related to cooking, cookware etc on Google when I encountered Salamander Cookshop. The site is simple, plain, crisp and to the point; serving its purpose to the fullest. It is a site for online selling of most of the top branded kitchen related items covering almost 173 brands e.g. Fissler, Rosle, Couzon Cuisinox, Silverwood, WMF, Wusthof, Scanpan, Le Pentole and many more. The site is well reputed and has been featured in top media like The Guardian, Good Homes, Daily Mail, itv etc.
In the Kitchen Trolleys section you can find Trolleys and Butchers Blocks of a large variety depending on your choice of wood. I could locate there various product range like – Maple, Ash, Painted stuff, Limewood, Beechwood etc. All this stuff gives you a large flexibility for your modular kitchen.
The next section that I visited was of Cookware Sets where you could find a long range of cookware with huge savings indications tagged on each. The variety coverage is fantastic, product demonstration is absolutely lovely and overall design is superb.
With so much versatility, variety and smooth sailing on the site, who will not like to stop and gaze around as every kitchen needs something or the other to add up any moment of time.
I was wondering to ask my project manager and project management office (PMO) guys to visit the site and learn some techniques that simplify quality and delivery.
Project estimations is not management’s ballgame. It has to come from the person who is actually conversant with in and out of at least a good amount of different type of projects running within the same organization. Project estimation is not simple mathematics. It is not just A + B.
Various components need to be considered while working out project estimations. Few generic constituents would be simple to identify and work out. Few constituents would be quite specific to that particular type of project under consideration.
Ten major constituents of project estimations can be listed down as:
1. Project Physical Cost
2. Project Intellectual Cost
3. Project Cost of Quality (CoQ)
4. Project Buffer Cost
5. Project Overrun Cost
6. Project Commercial Cost
7. Project Sales Cost
8. Project Material Cost
9. Project Inventory Cost
10. Project Indirect Cost
All projects in which management is the sole player in deciding about project estimations have higher chances of failing as compared to projects in which all members engaged with project in any manner have been involved in determining project estimations. When it is management that does project estimations, it is not project estimations, it is rather something like setting targets without having a clarity of what is to be achieved, what is the scope, what are resources and so on.
Management is just like an overseeing agency that has no role in project development, project execution, and project implementation at micro level. Project estimations cannot be so haphazard that variation between project estimations and actual project cost comes out to be substantial huge. Nobody will accept that situation – not even the closest of stakeholders.
Project estimations need to come out from those persons who are actually well conversant with project know-how and behind the scene expenses. Management is works out on project estimations without inviting participation of actual project runners, it would be quite risky. There will be quite high chances of missing the actual rope to the mountain. There are certain costs which are apparently visible off the shelf for any kind of project.
I would like to classify overall project estimations or actual project cost in these parameters – project physical cost, project intellectual cost, project CoQ (cost of quality), project buffer cost, project overrunning cost, project commercial cost, project sales cost, project material cost, project inventory costs – to name few main of those.
Any project has some basic requirements like project committee, stakeholders, sponsors, requirements, initiation, team formation, plan and milestones identification, project development, execution, implementation, handover, and finally project closure. What it means is that each of these basic components of a project play major role in determining success or failure of that project. A lack or shortfall in any of the components impacts on tempo and momentum of project. It can be correlated with a relay race where each player of the team has to be in sync. The weakest player determines the final standing of team after completion of race.
One difference between relay race and project is that in former each player plays his role in sequence whereas in later some tasks go parallel and some are sequential.
Project Plan formation, milestones identification, plan execution, plan monitoring, plan change are all quite critical in any project. Project plan made for the sake of project without a commitment of strict adherence to it means a great level of shortcoming in project committee and teams responsible to execute the project.
There are ways to monitor and control project plan. Some ways lead to post-mortem after any failure or deviation occurs. Other ways lead to a proactive approach where the project committee anticipates a shortcoming well in advance and thereby takes appropriate actions to manage to control the risk at their best hence reducing the risk to near to zero.
A proactive approach always comes with an objective way of monitoring a project. A well matured metrics in place always help in accurate measurement of the situation and this everything in sync and proper rhythm.
A customer is supposed to be quite cooperative and involved throughout the project. A project is supposed to be completed well in time complying with all the requirements specified by customer. Customer requirements specified in the beginning of a project are supposed to be complete and accurate. Team formation is supposed to be so precise that all team members form a perfect team. Project manager is supposed to be well prepared and equipped to take care of project. Management is supposed to support and fulfil their commitment to customer for delivery of product.
All this is possible and happens in reality. More in reality that happens is reverse of this. Customer involvement is not there throughout with availability of right people having precise business knowledge and experience. Projects do not end in time and if they do, some of customer requirements are missed or skipped or are not catered to properly. Customer requirements specified lack completeness, accuracy, and clarity.
Team formation in the beginning of project does not necessarily stay same till end thereby varying perfection. Project managers miss either preparedness or don’t get well equipped. Management feels team and managers are enough to mange delivery of product thereby getting attentive to business functions having higher priority.
It is either win-win or lose-lose situation in a project. Nothing is there in between. If one party loses the game that doesn’t mean the other party wins. If product is not delivered in time, if product is not delivered in complete, if requirements do not match with delivery, if customer is not happy; all these lead to a lose-lose situation.
There is a big difference between mediocre companies and well structured companies working in same set of business. Let us see a set of software development companies. This set contains two types of companies having different project management methodologies. All other types of companies with different ratios of two extremes lie in between these two types of companies.
First type of companies are those which have no methodologies in place. All that works is person dependant as there is no system (or per se well defined system in place). Other type is those having well documented, adhered and audited systems in place to manage all projects they work on.
First type are very dangerous though they exist, survive and sustain. But everything is ad-hoc – the business, the projects, the existence, the survival and their sustenance. Such type have no written or documented procedures, methodologies or systems in place. Since last project they succeeded in had no reported leaks, the next project will follow the same route or process.
Risk level is high in such type of companies. Best thing is, since there is no risk assessment, or audit (internal or external), there is no realization of leaks, holes or lack of process in place.
Such companies may declare project initiation without even formation of proper team, defining of requirements, roadmap, milestones or a project plan in place. Things are done as they come, or as they fail. Actions are taken not on the basis of proactive approach but based on stakeholder’s reports, complaints, system failures, shouts etc.
Having a high level seat in an organization qualifies a person to sponsor a project. Sponsor could be one person, generally one top positions or a groups of persons comprising of top/ middle level of management of one or different organizations. Projects may be self sponsored too wherein there is no customer involvement in that case and the sponsoring organization starts project on their own keeping in mind a good amount of response from market after the development of product.
Teams are formed, priorities and milestones are set and journey begins towards successful completion of project. Conflicts, issues and change management are part of project’s any phase. Most of the issues and conflicts get resolved with the help of standards, procedures and team managers.
Some conflicts and issues go beyond the level of managers and hence seek attention of top or senior management. The best person in that case is the sponsor(s) to address to such requirements. Rather sponsors should be regular in all project review meetings to understand about the progress of project.
Attending project review meetings is one important requisite for sponsors. More important requirement is to be very clear about the path decided and path being taken for the project. Things should not change on their own especially requirements, team composition and milestones. And if change is the demand of time, sponsors should have a clear cut say on it about the necessity and importance of change.
A weak sponsor having no say in the project or taking no interest in project is equally bad as not getting involved in the project.
Project Sponsor(s) are the executives whose dream gets a hope of light of the day when the plan to give a reality shape to this dream is made by forming a team and assigning relevent task to each of the team members. Project sponsors ususally are too senior lot of people ususally CEOs, MDs, CFOs, COOs etc. They have a tendency to conduct a meeting to shout about their dream among other executives and team members, get a high round of applause and a nod to start the project.
The team gets formed, comprising of sub-teams, team head, sub-team heads, team members with each of them having a set of tasks in hand to be performed in stipulated period of time. The dream of sponsors gets traslated into a roadmap with well defined milestones. The product starts taking shape and progress being monitored regularly.
One important factor that can make all this beautiful garden haywired is absence of sponsors from product development or product progress scenario. If sponsor(s) feel or assume that one meeting is enough to pass on the whole crux of their dream to team, they are absolutely wrong. Nobody else can understand the value of dream other than the dreamer. To give it a shape in reality, one need to keep his/her team constantly awake about it.
A CEO of a software company dreamt about a very great product one fine day and decided to give it a shape in reality world with the help of his strongly skilled team. The team spent many days on brainstorming about this new product conceptualization, design and development part.
The team started working on it with a stipulated timeframe in mind. The team motivated by their CEO who was the sole sponsor of this project was able to finish the project well in time. After careful and thorough testing cycle of the product, it was ready for launch in the market.
Efficient sales team started approaching relevant prospective customers to get orders. At few customer places the deal started approaching towards final stages. One of a big customer wanted to meet the CEO of this software company.
CEO of software company met with higher officials of customer company to have a meeting and was able to convince them about conceptualisation, development and logical built of the product. After getting a good praise about all this CEO got stuck on one question raised by customer – What is the business value of this product?
Do we know the answer for our product?
Any human being is a born quality manager and keep demonstrating his quality skills in day to day life by managing everything that comes in way by means of best possible solutions. A child is taught about cleanliness and discipline right from begining to sreamline his daily work. Do we compromise in admitting our child in a substandard school or with the character and quality of teachers they are being taught by?
We do not compromise with the quality of items and commodities purchased. Do we take a chance of compromising with the quality of material used in building of our house? We very well know about the consequences and risks associated with compromising with quality in our routine life.
The same concept applies to software projects too. Quality can not be subdued or sidelined. Risks of failure of any project cannot be nullified or ignored in that case. Quality plays a major role in assuring the success of any project. A programmer or coder if writes a program the same way with same mindset the way he manages his domestic work with high level of quality, there are less chances of passing the code with high level of leakages in it to next level of team that is testers for testing the product.
The way a product is buit with high level of accuracy and least level of quality compromise can be treated as a part of Quality Assurance. A product when given to testing team for finding out bugs falls under quality control. The level of standards followed by testing team to perform testing process will come under quality assurance.
A child is born to get groomed to be responsible for various activities all across his life during his transformation from infant to toddler to teenager to adult to old. At various stages he has to undertake various responsibilites along with a continuous learning process. A stage at any moment in life of attaining a capable position does not hinder or restrain a person for further development.
In fact nobody is perfect hence aspiration to attain a ’near perfection’ state is a never ending process in life. An infant though unable to speak manages well about his signals of what he desires to have at any particular moment. The moment a child starts going to school, he starts managing his balance between home and school, coordination among his peers, learning from his parents and teachers, managing his tasks and disciplines assigned and taught by elders be it teachers in school or family members at home.
Demands in senior school and then in college are quite different as compared to junior school but by that age the child has learnt well to cope up well with them. A new journey starts with a fresh career and a consistent growth chart.
The logical and general skills required to manage any project in life and career already exist in any person inherently. It is only the specialized skills and technical knowledge that is required as an extra edge for a specific project.
Customer Requirements need to be wisely analyzed before committing its fulfilment to customer. Many a times a commitment which has not been properly analyzed and assessed impacts to a large extent on completion of project.
It may also happen that a requirement stated by customer at a later stage may appear to be quite genuine for business purposes and logically need to be covered in product development. Project Team need to properly analyze and though accept the requirement but need to clearly tell the customer management its impact and risk if any.
The requirement raised by customer may already be catered to in the product built for the purpose but not exactly in the manner defined or expected by customer. If the impact analysis draws out a bigger risk of changes to be done at that stage of product to cater to customer requirements as it is, customer management need to be convinced about the functionality and features already present in the product.
It is wise to build a functionality altogether different as a complete sub-product, if requirements need call for that; instead of fiddeling with the main product.
It is unwise to accept all requirements of customer and keep making changes in the product thereby changing its stable stage to unstable one.
It is better therefore to adhere to and adopt some best practices to manage Change Requirements.
Many a times it has been seen that a change in key users or one of the key management person tend to call for changes in the stable running product in the organization, which may turn out to be quite harmful.
Project Manager and Project Management Office need to convince top management of customer in case of some unnecessary requirements raised by one of the influentinal person in the organization who might have joined organization recently so as to impose his/her importance.
Changes once accepted, not only impact on product’s stability or the software environment but also many times has serious effect on performance of the product and its hardware requriements may change.
In fact requirements raised by customer must be mapped properly with their existing business model and its impact on software application running in the organization for that purpose.
An ecosystem to manage change requirements and a standard metrics system thus becomes prime important to manage the show.
A well defined system in place not only helps in streamlining the process but also helps in benchmarking with other systems being followed in other organizations.
Involvement or engagement of customer in formulation of systems is always beneficial for both parties.
These processes once defined must be adhered to and also need to be examined from time to time for the purpose of optimization.
Defining of processes is not difficult if compared to the later part which is adherence of those processes.
Release management is a systematic structured approach of releasing the product to customer. The product journey that starts from requirement gathering from customer, conceptualization, prototyping, coding, testing finally is declared or approved for release.
Testing phase can be termed as equally complex stage during Release Management. Product testing is done in various forms starting from smoke till regression testing.
Test Cases are performed on product and test report is submitted back to development team with an indication of severity of each bug reported. Development team fixes those bugs and product once again undergoes testing for validation and confirmation that no new bugs have evolved while fixing the reported ones. Product now has to undergo one more phase of testing which is termed as UAT or user acceptance testing.
Risk Management and Change Management are two very important components throughout the Release Management of product.
To summarize Release Management, a checklist is always important to maintain and update regularly in order to ensure the successful results throughout this journey.
Requirement Coverage: Requirement gathering and its documentation both need to be crisply and completely covered. Any lack in either of the activity is like a volcano in the making. In fact 88 percent of project failures worldwide are due to wrong or incomplete requirement study.
Team Selection: Development team need to be wisely selected keeping in mind – too many cooks spoil the broth. A mixed level of developers always keep better harmony in the team than having all of same level.
Development Plan: A proper plan with clear cut assigning of responsibilites along with target dates mutually agreed upon has to be in place without which no sailor will move the ship in right direction.
Quality Control: Each step testing is an important factor. Don’t wait for the product to complete first and then start testing. That will be a sheer wastage of time, efforts and resources. A side by side testing draws out better results.
Quality Assurance: Some benchmarking and standard processes need to be in place and to be followed to ensure a quantum control over the situation. Else nobody will be knowing what processes or methodology to be adhered to for ensuring success at every stage of the project.
Stakeholders/ Customer Engagement: Most of the time there is a wide gap between development team and other stakeholders/ managmeent/ customer representatives. This gives a big opportunity to development manager to misguide management about the progress of project or projecting the situation as per his comfort. This does not go healthy for project in a long run.
Software development comprises of various stages and components. As software development is a subset of Project Management; there are many similar components of Software Development Management. Some substantial components of Software Development would be –
• Customer Requirement
• Time Management
• Quality Control
• Quality Assurance
• Task Management
Covering these stages of Software Development Lifecycle following is the listing of some articles/ blogs for the purpose:
An extra mile of testing effort spent at initial level saves lot of efforts at a later stage. Minor hiccups passed over to customer too sometimes create big issues depending on their frequency and volume of occurrence.
Imagine a small fly in the sweet dish being taken by a customer after an n-course meal will create a big havoc for any good restaurant. It is different if customer acts as blind and ignores a small piece of hair found in the meal thinking that his own hair from head might have fallen in the dish while having his meal.
Similarly a user sometimes ignores a minor error encountered while using an application thinking it might have occurred due to lack of knowledge about the usage of product. User might think during initial phases of product usage that probably the problem might have occurred due to his non adherence to proper steps following.
A business comprises of different software. These software applications comprise of two business streams – business critical application and business supporting application. Usually business critical applications cover ERP like main stream application. Business support applications may comprise of legacy applications or side stream applications running standalone or interfaced with mainline business application.
The emphasis on level and type of testing solely depends on the nature of software under the scope of testing. All software cannot be put under the same frame of testing. It all depends on coding structure, interface, web based architecture or similar parameters that define the test strategy of a software product.
Testing during development, and at the end of product built too vary as per norms. The last testing phase prior to product release has to be extensive, elaborative and exhaustive in nature.
Tester is not the part of package of a team going for software product implementation. Probably that is wrong on part of project manager if he decided to send a technical team member along with implementation team with a sanction of development and requirement changes onsite.
Well actually there are two scenarios of catering to changes and development onsite. One way is all changes required are documented well and signed off, sent back to back office support technical team for development with a stipulated timeframe (which is definitely in hours or not more than 2-5 working days). This exercise of development includes testing in a proper manner.
Another scenario though would be less time consuming but more risky as developer(s) are there with implementation team but no tester(s). In this case the development (changes) part will be done instantly and onsite itself but the risk factor or vulnerability is higher as testing (if it has taken place) is done on site and that too by non professional testers. The product may behave ok in this case in first go and pass through UAT too by users. But in reality such extensions of development always have higher chances of carrying hidden bugs that may expose sooner or later thereby reducing trust factor in product.
I have not seen any implementation without a requirement of changes in the product to be implemented. But it all depends on so far well tested product management at this stage – if the changes take place offsite (back office) with same established way of testing (may be by consuming a little extra time); or catering to it onsite by developer (in a shorter time) with no proper testing.
Support comes after project completion. Project lifecycle but must treat support phase as a component of it. Prior to support the major project phases include – project initiation, requirement collection and freezing (though freezing is not actually freezing till the handover and sign off), product development, testing, implementation, pilot, live, sign offs and handover.
After the successful completion of above phases, implementation team leaves customer location in a typical situation.
That is the time when product is totally in hands of end users who start utilizing their product knowledge acquired so far. The practical phase is not that simple as lot of unexpected surprises start happening during this period. Some of the errors encountered by end users actually are not product errors but arise due to wrong or inappropriate usage of product. That is not unnatural. Since the end user start working on product on their own, it is something like a new player playing in his first match, or a person who has learnt driving afresh is driving on road for the first time all alone.
Support team has to be quite patient giving top priority to ‘voice of customer’. Technically and functionally, support team may know that a wrong complaint is being registered, but it becomes their prime role to guide end user about the right usage of product step by step without hurting his feelings or making him realized as wrong.
On the other hand if support team gets a change request in the already running product, at times, due to time crunch, it becomes important to handover the change developed without appropriate testing done by test team. But in the parallel line of action, the changes in product must be handed over to the test team with a stipulated time frame to ensure that the changes are done appropriately.
SDLC-I: Software requirements – This post talks about Software Requirements. Software requirements itself required a standard process or procedure to be followed and can’t be managed in a haphazard manner. The process must start with an initial discussion which may happen from a distance via any good communication media if client is far from vendor. Once the initial discussion gives comfort to both ends – that is – vendor feels comfortable on a broader scale to provide a solution to the customer and – customer feels comfortable that vendor is capable enough with a outline solution ready to cater to his solution.
A next level of meeting is scheduled only after first level of discussion shows some significant positive outcome. This next level of meeting is better result oriented if takes place at customer’s location. This meeting requires substantial time to be spent to gather customer’s business requirements that need to be catered to in the software application to be provided to customer later as an optimum business solution.
During this detailed meeting that is carried out by vendor’s business functional leaders along with customer’s respective business function leaders remains incomplete if the whole discussion regarding business discussion and business requirement is not documented properly.
Along with documentation, vendor team must collect all forms and formats in printed, handwritten or whatever shape with proper mapping and understanding.
Once the requirement is gathered, documented and finalized must be signed by customer business process heads and thereafter by overall business head of the customer to own the responsibility that whatever has been told and documented is what they require to be built in the software.
I think anybody who is in software industry must be familiar with the complete lifecycle of software. Here is a treat of seven blogs in a row on the same very subject of SDLC – that is software development lifecycle.
Here is a segregated list of my blogs on testing mainly for the purpose of people enthusiast in testing, testers, QA, QC, bug management; and software Quality:
The post ‘Twenty ways to ensure complete coverage of software testing’ can be treated as a checklist for ensuring complete coverage of testing of any software. It talks about some basic fundamental but critical and important steps to take care of for the purpose.
Purpose of testing is not only to ensure reporting of bugs in a proper manner, complete coverage of product vertically and horizontally both, and ensuring that critical bugs are taken care of. Test team must also ensure timely reporting back of bugs fixed from the development team so that they can one more go over the complete product to verify that all bugs have been fixed – properly.
Test team while ensuring fixing of bugs through their verification cycle must also ensure that while re-writing or varying the code, development team has not developed any new bugs during the course of their action.
There could be various ways to ensure complete coverage of product, proper identification and reporting of bug; and validation of bugs fixed etc. depending on level, automation, and methodology adopted but checklist can become handy in any case.
Why Software Developers are not Doctors? was another interesting read to understand the satire behind the simple title line. Software developers are quite famous (and that is not in good sense) for writing a code that is never perfect and bug free. That is why any code written by a developer or programmer has to undergo scrutiny under tester’s microscopic eyes to find out the hidden bugs and thereafter fixing them by developer.
Definitely this whole gimmick of identification of bug, its reporting and then fixing by developer takes time. Not only this, when a developer fixes the bugs, the tester has to retest the code to verify the fixing of bug and identify if there is any new bug encountered due to change in code.
Story does not end here. A small change in code at one place of a software product may have its serious and many places impact if not handled properly. That is why the first wish of any developer from himself is to become a bug free coder which is very rare to find.
The satire very well remarks on this particular nature of developer of not writing a bug free software in first go which implies that if a developer had become a doctor, he would definitely be a failure as each of his patient would never have got cured in first go.
Do we mean to say that whatever a doctor prescribes to a patient need to be examined by another person (doctor-tester) before patient starts taking the medicine?
‘How Software Testing Took Birth’ would be an interesting read if you have not read it earlier. Give it a try to this small article that provides and insight to some very basic fundamental reasons about necessity of testing of software.
There would have been a time many years back when there was no concept of testing altogether. The software would have been produced and given on as is where is basis without any guarantee of its behavior or results produced by it.
Gradually a need would have arisen from both ends – customer and vendor to maintain a decorum, sanctity and reputation of software producer and software being produced.
Probablity in early days when software product cocept had started, software development would have been more of an experimental and adventure case rather than a serious business product building concept. And gradually when reliability on software increased, its necessity of providing a neat bug free product also would have arisen.
Each bug in the software costs. The first hidden cost is the developers time that could have gone in a neat code, except goes into embedding a bug in his code. This all happens unnoticingly. No developer intentionaly writes bugful codes. It happens inherently due to a set of fixed development creiteria or pattern in developers. A blog about ”A Linear Approach of Cost Estimation of Bug Fixing for Various Software Projects” focuses on need of estimating or rather evaluating overall cost of a bug right from its insertion to identificaiton to fixing to verification.
When a developer fixes a bug there are some chances of not fixing it completely, or generating another bug while fixing an existing bug. Similarly a tester while testing a software also has a chance of leaving a bug unnoticed, or identifying and reporting a bug wrongly. In either case it it the product and project that suffers most. A tester needs to be extra careful while testing whereas a developers needs to be equally careful while writing code. While verifying a bug fixed reported by development team, the tester need to ensure not only the reported bug fixed but also ensure that no other negative impact has arisen.
For that purpose a tester needs to adopt another approcah discussed in my earlier blog titled – ”Progressive Software Testing Approach by acquiring Soft Skills – Step by Step” in which an emphasis on certain essential soft skills has been highlighted that becomes catalyst to software development and testing process.
When I started blogging on ITKnowledgeExchange.com under the blog title ” Quality Assurance and Project Management” in the middle of the year 2008, I wanted to pour out all my experience on Project Management, Quality Assurance, Quality Control, Team Management and other related subjects.
My foremost pain was and still is the way developers develop a code or write a program. Though all developer are not alike, but one thing consistently I found was the way coding is done, it always leave a scope of bugs. And based on that pain my first blog was titled – “What stops a Good Programmer from being a Good Tester – 8 Reasons”. I wanted to highlight the top disciplines in absence of which a developer always leaves a scope of gaps in his coding.
Then came the next post regarding how a tester should work to get the best out of his scope of work. Some top reasons were discussed in my next post named as – “Knock! Knock! – it is tester here!”.
Tester in his own capacity is helpless as far as product neatness is concerned. To know about what exaclty is required to be tested, a tester requires a good knowledge of business requirements based on which development team has built the product. Testers basic purpose in my opinion is to ensure that there is no gap between the business requirements and the product being delivered, and use comfort in using the product.
There is no doubt that if tester has lesser or equal depth of knowledge as develper about business and product, he is also prone to leave gaps in two ways – either by testing the product wrongly based on wrong business assumptions, or by reporitng the actual business scenario insufficiently to the development team.
Usually it is not the developer’s fault if he build bug in addition to writing code for any application, The seriousness of application may vary from business point of view, the way that application is going to cater to the business management. Even a game code for a gaming company could be as serious as a banking application code for a financial institute.
In both the cases – game or finance – bug can’t be tolerated. First instance to check the bug is the way of acceptance or acknowledgement of bug by project manager, development manager, and management team. High level of acceptance give higher leverage to developer to chip in bugs during code writing. A developer by checking on his some of the qualities may become a good tester of his own code. And if that happens, the developer in turn will always become a better developer.
Second instance of check and control is the leverage given to project team to keep tester far away from product. A tester though needs to knock development team’s door repeatedly for certain set of requirements to perform his duty properly and also to justify his task of testing the product in terms of product release.
Project Team should have a way of measurement of time and money for each of the bug reported. If each bug fixing is measured from its evolution, reporting, fixing and validating cycle, an objective approach can certainly ascertain a value to these efforts.
Every Bug has a cost to fix and for that sake to report too. It takes someone’s time (tester’s) to find out the bug in a software product. It takes another piece of time to write and report it to development team who in turn is responsible to fix the bug.
Fixing of Bug again takes time as developer needs time to understand what wrong has been built or what scrap is to be removed and in its place what useful code is to be written and kept. There are various approaches to calculate the cost involved in this complete cycle.
The bug reporting and removal cycle does not stop with reporting by tester and fixing by developer. The rectified piece of code goes back to tester again to verify and confirm that it has been fixed. Tester has further to investigate and confirm that while fixing of this bug, developer has not created any other bug that impacts application functionality or usability.
An approach known as Linear Approach of Cost Estimation of Bug Fixing for Various Software Projects can help project team in ascertaining the preposition of accepting a leverage of developing bugs in software in place of a neat product.
There are seven instances when a tester need to knock to Project Manager for certain requirements or help from him without which his role as a tester cannot move further. Any lack in those assistance to tester will certainly mean lack in delivery of right product/ bug free product.
For isntance a tester certainly require business requirements document to understand what initally has been asked by business owner to build in the software viz a viz what actually the product has been built by development team.
Around three years back I wrote a post relevant to the same subject I have discucced above primarily talking about the crux of the requirements by a tester to justify his work related to a software project. The article was titled as ”Knock! Knock! – It IS Tester Here!”
There are good programmers and there are good testers. But in 99% of cases good programmers are not good testers and in 100% of cases good testers are not good programmers. Whats exactly would stop a good programmer to be a good tester. Three years back I wrote a post on this titled ”What stops a Good Programmer from being a Good Tester – 8 Reasons.
That was my first post on ITKnowledgeExchange.com. The topic and contents of the article came right from my heart as this pain I was facing for many years during my exprience as a developer in my early years and then later after becoming the head of QA/QC.
The post talks about eight activities if done by a developer can turn him into an as good tester as a developer he or she is.
Success of a project depends on many factors. To name a few would be Team composition, team size, project management methodology, benchmarking, optimization, time management, resource management, monitoring and so on. The list may go endless. Besides all mentioned above, some simple techniques that are easy to adopt and adhere to can change the life of a project manager or for that sake any of the team members who adopt these techniques.
1. Take Lead: Move forward to adopt a tougher task rather than waiting for someone else to grab it and hoping for a simpler task to come into your pocket. Sometimes reverse may happen. And moreover without moving forward you will never be able to bring yourself into limelight.
2. Grow Taller: With each problem and solution, grow your inner strength to handle such situations in a better way in future. Fighting with same situation again and again in same manner is not at all a wise decision. Find out a better solution every time you face a problem.
3. Learn From Mistakes: Who says I work and never make a mistake. Only one person can never make a mistake – who never works. Anyone who works has always a chance to make a mistake. Best thing is to keep learning from your mistakes. Failures and mistakes are the best teachers. Keep one thing intact in mind – never repeat a mistake.
4. Share Onus: You might be smart to handle any situation but in a team never try to take credit alone for any win. Do it only if you want to grow alone and keep all others in team as still as they are. A small piece of appreciation and motivation can do wonders. Try it and see miracles happening.
It is not actually Test Environment Detail Template. It should be termed as Test Environment Template. Let us first understand some terms first as below.
Test Environment: An environment in terms of hardware (server, end user, networking, LAN, WAN), software (client app, browsers, any other) and security environment (firewalls, antivirus, etc.) is decided to be as close to live environment so that no misbehave goes unnoticed during test phase.
Real or Production Environment: A real time scenario when product (software) gets launched at customer site (live environment) after completing all development and testing phases. In this environment, it is the end user that starts working on software in real for business benefits.
A real environment scenario with complete specifications gets frozen right in the beginning of development process (during high level design preferably and may be some part during low level design). Though some changes might occur in the final specs during development or implementation phase but those can’t be major in nature. Otherwise the whole project gets shattered.
A test environment should be as close to live/ production/ real environment in all aspects so that this environment is as good as a simulated environment as it is going to be in reality. Though it may not be possible to create a 100% same environment as it is going to be in live conditions because the same environment may cause a big amount of money and lot of efforts which may practically not be possible.
The template of test environment should be prepared at micro level covering all requirements of live environment with three main sections – hardware, software and security. A parallel column must be there to record deviations and next to that should be a column describing software behaviour and its reasons.
1. Proactive And Intuitive: Alternatively imagine of a team that wakes up only when the water has reached till neck height will take four times of efforts to resolve the same issues. That means a proactive approach is always good with a good flavour of intuitive power. Being proactive and intuitive is worthless unless you have courage to cross the line of silence and inactiveness.
2. Break Silence: Many a times a members keeps mum on a perceived disastrous situation in wake of two fears – one, he will become victim of it; and two, he would get laughed at if situation does not turn out that serious as perceived by him. Nothing will harm even if both probabilities become true. At least it gets shared and evaluated well in advance. Remember that if you understand a problem beforehand and keep silently waiting for someone else to understand and raise the alarm, it may happen. But suppose if it does not happen, it is going to harm the whole team and you are part of the team.
3. Crack Iceberg: The bigger is the iceberg, the higher the disaster it can cause. It is always better to crack it down to smaller pieces. Team must break down a complex problem or situation into simpler parts so as to assign and delegate it in a better way and results start skimming in faster. Someone among the team members must come forward with a courage to demonstrate how to break an iceberg and to share its pieces with everyone rather than few members taking the responsibility of bigger or whole chunk.
Positive of negative traits of a project do not happen on its own. Every act has a reason and every reason has a cause. It is quite important to understand the cause and reason behind any act that occurs during a project lifecycle.
Any deviation from a regular trend must go under investigation be it a positive or negative deviation. An unexpected or unstipulated/ unplanned finish of a task much beyond it was perceived to be definitely requires an introspection and brainstorming so as to understand certain facts behind what is apparently visible:
1. Whether actually the task has finished or is it a misjudgement.
2. What factors made this calculation go wrong.
3. Will it get sustained in future or this deviation was just for this very instance.
4. Can those activities triggering as catalyst to boost completion of task be imbibed permanently in process for similar tasks in future?
5. Has it been a situational benefit or a procedural one?
Such brainstorming will definitely give ample evidences to understand the core logic behind the abnormal activity. Many a times tend to stop finding a reason behind any abnormality beyond certain limit of time or effort. Probably and may be rightly it appears that wasting more time and effort on going into the depth of this issue may not be worthy and justified. It is also assumed that if same situation arises again later in future, more time and effort will be put into it to understand the main cause of it.
Sole purpose of team formation is to manage a tough task collectively and finding out success paths collectively. A team shares success and failures together even if few among all members are responsible for it. Each member of team is supposed to benefit project progress in one way or the other. Otherwise presence of team members in a team is just a formality. Team members have to acquire following specialities so as to be a spearhead of success for their team. Such team members even if are moved from one team to another, remain success generating pillars for their team.
Understanding any complex situation is always complex in nature. it is said that any simple situation can be turned into a complex situation by the way it is understood and handled.
The team should have a capability to understand a situation that is prone to create a complex situation if not addressed to in a timely manner. A proactive approach is quite important for team members to understand the break even point for any problem or situation and manage it well before that point is reached so as to avoid crisis and disaster.
It is said that if a person (or team) has a capability of understanding a problem well in advance before it breaks out, half of the battle is already won. This is because by the time problem actually raises her head, the team is in a good situation of handling it. A team waking on the last alarming bell or first alarming bell always
Best part in a team versus an individual is that a single person will think only with his brain having no discussions, brainstorming, alternatives and different perspectives. A team comprises of different heads, having different ways of thinking and tacking situations. In a group of people a big problem gets small as it gets shared among every member of the team. Such miracle cannot happen when a single person is handling a problem.
But this does not mean that larger teams have more chances of success than small teams. Team size is totally a different ball game depending on the workload and resources available viz-a-viz time available in the pocket to handle the project. Team optimization, resource optimization and time management are different subjects that need to be covered in different details. Currently we are discussing about a group or team and its benefits.
More people are definitely bound to give different ideas for a problem handling and hence optimized ideas can be picked to give a solution. But on the negative side – more heads also mean more chances of conflicts, path crossing, barrier generating and pushing/ pulling. These negative traits of any team if managed smartly can overturn any team into a productive and progressive team.
A team has a power to convert any complex situation arisen during project to a manageable situation. Team can bring any tough situation into comfort zone thereby making bigger achievements easily attainable. It is said that if all team members become compliment to teach other in a team, that team can do wonders at any moment of time. The same project managed under same situations by different teams produce different results.
Imagine that you start your new venture. This venture has no scope of any recruitment in the beginning and there is only a small office with you to start your operations. Gradually there is an ample scope of expansion of business, more office space, recruitment of staff etc. during early stage you are to open your workspace in the morning, clean it, get your desk clean and equipped with water etc. That simply means that with just you in your venture, you are everything, right from peon to managing director. That is simple to say but difficult to perform. But it is not impossible. I have seen many people starting like this and later going beyond their expectations in terms of expansion of business or earning revenues.
If the same attitude is applied in a team then it may bring in a dream team in place. Imagine a project where each team member is required to be equipped to do any task at any moment of time. Imagine about a team where each team member is capable to perform any other member’s task. Count of team members is not for the sake of fulfilment of a gap in terms of quality and requirements but in terms of position only. If that dream world becomes real, it means in absence of any team member nothing gets stuck or delayed in a project.
In absence of a team member another member will take his place and fill the gap. Though this will definitely increase that person’s load but in such scenario where everyone is capable to do any work, the absent team member’s work can be shared in parts by four or five team members instead of putting the complete load on a single person.
A fight between customer and vendor related to requirement keeps going on till the project finish stages starting right from the requirement study phase. Whatsoever methodology or standards you adopt to capture customer requirements, there will always remain a gap between what customer said, what you assumed he said, what you understood and what you built.
But more important is the ways it is covered up by project manager in front of his management. Some of the most prominent reasons he gives to save his neck are:
1. Customer availability: A very common excuse used very frequently whenever there is a point of confusion over customer requirements or lack of information issue arises during a follow up or review meeting is lack of customer availability during the system study phase. Some more relevant excuses would be that the main person concerned about a business process was quite busy/ unavailable/ away and the person deputed in his place had not much knowledge.
2. Customer clarity of business: Same as mentioned in point above. There will be complaints about not getting the right person. The person who was assigned to interact did not have sufficient knowledge. The assigned person was quite new to organization and hence had not much of business knowledge.
3. Customer awareness about technology: Customer has demanded irrelevant things in the application without even knowing about technology and its limitations or power. Customer wants it do be done this way whereas it is quite easy and better to do it that way. These are some dispute points that keep bubbling up at later stages.
4. Customer expecting too much: We started the project with a limited scope but customer keeps adding irrelevant requirements now and then. Customer had initiated a business application but now he expects a full fledged work flow embedded in the application. May be customer would demand proactive/ intelligent part in the application with mobile alerts etc. which was never part of initial discussions.
5. Customer refusing to accept what he told earlier vis a vis what is being delivered: Reasons could be many but a good relationship maintained throughout can force customer to ignore small gaps in the delivery. The same small gaps may erupt as dangerous as Tsunami in case of no good relationships maintained.
Project Manager can never be a quality cop because if he becomes a quality cop, he will never be able to finish his job. For quality manager it is very difficult to become a project manager as having a critic’s mind he will have more than hundred percent chances to have conflicts with customer and his own management over certain issues where he might be forced to compromise but he may not like to. It is very important therefore for a project manager to be a strong stance to manage his project and teams whereas it is better for a quality manager to have a mild or soft stance to keep things going.
Many a times it happens that a bug or defect that gets identified at a later stage after his has crossed quality barrier puts quality team in a tight corner. At such moments it is the QC team that comes under total fire and blame game which is absolutely wrong. To avoid such instances a quality manager will always prefer to keep his tight grip across the product to ensure no leakage remaining unidentified by his team.
It is always better to have heated arguments regarding quality issues between quality head and project head within the building and before the product is launched rather than making a mockery of the whole manager at a later stage in front of customer when those defects or bugs get exposed thereby exploding the situation. Under no circumstances Quality team alone be blamed for defect leakages at a later stage; the whole production team should stand shoulder to shoulder with their quality team under such circumstances.
What happens if a requirement wrongly understood during study phase gets resulted into a mess at a later stage. Minor gaps can always be fixed at any stage of the project. But a requirement if changes 180 degrees after it has been built in the software application and then if customer totally disagrees to accept it, it could lead to a disastrous situation for development team. It could also shatter the whole implementation plan and the overall project plan.
Negative impact on costs and teams is unavoidable in such situations. Though it is the whole project that requires QA/QC engagement but following areas would require QCs engagement most and these are the areas where they are ignored most.
1. Requirement Study: It is not important to have QC persons involved in requirement gathering process. But the moment requirements are finalized and documented well, a copy must go to QC department for them to do two things. One, understand requirements well and start preparing test plan/ test cases. Two, to check any loopholes, ambiguities or shortfalls in requirements or documentation.
2. Development: QC team is usually kep away from development team during development mainly because of three things. One, it is not QCs ball game right now, this court is only meant for developers. Two, what will QC team do to be here till the product is not ready; let product be ready to handover it to QC for testing. Three, the earlier QC is engaged in project, the more problems they will create. So better engage them for the least time.
3. Documentation: This area is usually not given to QC for examination and validation. As a critic they must check all documentation especially the manuals that have to be handed over to customer users.
4. Implementation: QC is not engaged during implementation and that becomes a major cause of project deterioration due to on-site customer requirements not being analyzed properly and admitted to be done thinking that this way will save time whereas this causes delays and problems.
When customer places an order to a vendor for procurement/ development of software application, intention is to get enhancement in business by way of process optimization/ improvement. Of course the finalization of a vendor has gone through a proper scrutiny and analysis process so as to arrive at a conclusion that the finalized vendor is going to cater to the requirement building in application.
Software application must meet with all standard norms of usability, fulfilment, ease, speed, features and results. Let us elaborate these customer expectations as below and try to understand them:
1. Usability: Product must be usable if expressed in simple terms. Why do we use anything in personal life? – To get certain output or result as per expectations. That is what is in business too. These expectations are nothing but a set of requirements (business or personal) meant to be met by the product when used to draw out in form of results. That means there is a deep relationship between any product, user’s expectations and results got by using the product.
2. Fulfilment: Product should meet a factor called completeness. Business requirements, design, ethics and aesthetics are the sub components that lead towards fulfilment.
3. Ease: Product must be easy in terms of understanding, usability and getting results. Screens, reports layout, navigation, terminologies used must be optimally compatible with the local language, management and users.
4. Speed: Working of product should be comfortable enough to cater to business, management and user expectations. Performance of product should be able to enhance overall performance of business, management and users rather than doing it otherwise.
5. Features: Product should have an extra edge over other products in the market to win over customer confidence and get is maintained and sustained for a long period. Product should be capable enough technically to cater to customer’s future requirements with least hiccups.
6. Results: Product above all qualities should be result oriented. Beauty, performance, efficiency, efforts, hard work, technology – all go hay wired if desired results are not produced by the product. Two main factors in case of results are – time and accuracy. Product must be able to produce results timely and accurately.
We have seen many software touching sky heights even with quite a less number of features and functionalities. We have also seen lot many software falling nosedive having bulk of features and functionalities. Is it the difference of simple and complex that makes any product successful or failure? Or is it the combination of some factors that make any product successful.
A simple calculator application can become as big a hit to fetch revenues more than expected by its developing company where as a high investment driven business application say an ERP can lose grounds even if it perfectly at par with other applications in the market.
What makes a product success or failure is a topic on which series of books can be written. Is it the product that creates the name of a company or is it the name of an already well established company that makes a product hit? Can a company sit on its laurels after making a product hit in the market or does it require an organization to be always on its toes to keep its market share intact for years to come.
A good product that fits in market demand today may not be fit tomorrow. Customer expectations keep changing with time depending on change in technology, other products, competition, risks and introspective or innovative ideas.
This is definitely a never ending discussion with more useful points coming with inclusion of more heads in the discussion. Please throw your opinion in comments section.
Customer will always be hesitant in declaring software project as complete by means of talking about more and more to be done in the software. This ‘more’ could be anything like functionality, requirements, confusion, frustration, appearance, performance and what not. Some of these ‘more’ can be addressed to easily if possible to take in objective manner. Sometimes this tactics is intentional arising out of many reasons.
A lot is said about customer – customer is never wrong, always listen to customer, your customer runs your business; and so on; which is not wrong. But there are times when customer may become adamant on some non realistic issue keeping in mind to not release some payment or not issue a project close letter/ certificate. If this is the case, it is happening intentionally on customer front. Basically such a situation should not arrive under any circumstances.
If a proactive approach is maintained, project manager can always foresee things going out of hands. An emergency meeting is required to be called immediately involving all stakeholders including top management members from both sides.
Customer may have a large list of concerns on the table in that meeting. First lesson is listen carefully and attentively. If you do that, you win half the battle. Keep jotting down those points or ask customer for a copy so that while he is sharing those points, you can keep marking your points against each of the issues raised by customer. After the list is completed, start with points where you agree to customer and accept the concern with a commitment to settle it ASAP.
Then start discussion of those points where you disagree to customer – put your contra-points and tell customer since you have agreed to so many points above unconditionally, these valid contra-points must be agreed by customer so as to close all issues.
A tester has to look at a product for testing purposes by getting into different modes (or rather I will say by being different avatars) to ensure his mission got completed successfully in terms of time, efforts and results. Though both – tester and developer work on same product but have different roles to play. Developer, on one hand is builder and admirer of his produce. Tester on the other hand has to ensure whatever was expected to produce has been produced as per the parameters decided. If both work on the basis of parameters then how come what a tester can see in that product is not known to developer or that gets ignored by developer. What differentiates between a tester and developer is the way they look at the product.
A tester needs to work on the product in a different way than developer so as to arrive at a conclusion (not arbitrarily but objectively) that the product meets desired standards and capabilities. How can he do it by being in the same frame of mind? He can’t. To achieve that he has to get into different frames of mind as listed below:
Perception: Tester needs to perceive business scenario in which the product is desired to perform efficiently and perfectly.
Physical: Check your perception existing or getting satisfied in real by way of the software produced.
Intellectual: Check out the business benefits out of what is being desired and getting performed.
Exceptions: Don’t forget to test out the exceptional business scenarios or cases that may be having a rarest of the chance to happen in real.
Customer: Think yourself as an end user to see if you really get satisfied by the way software appears, looks, feels, works, performs, gives output, etc. by logically covering its functioning, behaviour and aesthetics.
It is said that howsoever confidentially you keep information about what you have become, why and how it gets revealed at sometime or the other during your career growth. There are three stages mainly during your career as far as failures and successes are concerned. They may happen in a different order for different persons. One stage is when your failures overpower your successes thereby keeping you in a sublime stage. Second stage is when your successes are higher than your failures and then the failures get masked by successes. Third stage and the most important one is when you start performing without really bothering about the FEAR of failure or OVERWHELMENT of success.
The same three stages appear in any software product also. A stage where product is evolving will see more failures and less success. Gradually with increasing amount of handholding, research and experience; the product starts maturing and reaches a stage when SOME failures get overshadowed by LARGE amount of successes. Between these two stages there comes a crucial stage of ‘keeping hope alive’ or ‘leaving hope’ depending on which the further growth of product gets dropped or carried on.
With the same perspective if the life of a tester or developer is scanned they underpass a similar sort of trajectory. Initially a stage is not fully set for them to demonstrate. Rather it is a period of their acid test and learning. They tend ot make more mistakes though unintentionally while learning about their profession and professional world. Gradually a maturity level comes when they start getting more hits than misses. This is a stage when the performance comprises of more successes than failures as they have already burnt their fingers during the practical learning phase.
It happens in a professional lifespan too when a person out of fear loses hope to survive in their stream, surrenders and walks out silently. Professionals who are able to keep themselves away form this feeling, or are brave enough to fight with such situation are able to cross this barrier to brighten up their career.