When the product is ready to be handed over to testing team, the testing team needs to ensure completion of certain tasks before it actually starts the testing of code handed over to them by the development team. These important tasks ensure proper understanding of scope of testing, and help in preparing complete coverage of testing by building exhaustive (and relevant) test cases by the testing team. In any case these activities would be happening in all the cases but only need to be crosschecked to make it happen in a formal and structured manner.
These activities are:
Business Flow: Along with customer requirements, testing team needs to understand the real life business flow at customer end so as to align it well with its testing strategy, coverage and completeness.
Business Cases: Real life business cases need to be studied by the testing team for both the scenarios – one, for the current condition where the business might be handling the situation on a legacy system or manually; and secondly, how they would like to see it happening in the newly built application and environment. The simulation of both scenarios is quite important to understand what-is and what-needs-to-be situations.
Taking further on from few of my earlier posts on Project Plan and Project Management –
Here is some more insight on Project Planning:
Any project when goes in its execution phase, gets bundled with a set of assumptions, is a well-known fact. These assumptions vary on the basis of different factors that control a project. So we need to understand how do we tackle a situation where a live situation to go active in a few days/ weeks/ months from now is dependent on certain factors which are hypothetical in nature. There is a conflict already built, if you really notice, between a real and a hypothetical environment where both are banking on each other for making it a success.
It becomes quite important to understand what those hypothetical situations are known as assumptions, and what the basis on which it is being built. A classic example is team sizing which is decided on the basis of scope of work and past experience in handling similar kind of situation. For example it is worked out that the total effort for a particular task of development is say 20 man days and this development work is to finish in 5 days thereby deriving a requirement of 4 persons to be deputed for this particular task. Now important to know is the task itself – whether it is possible to split in 4 equal portions and handover each portion to each of the developer to finish in 4 days each so that one day is kept as a buffer, or the job is sequential where the second person can work only if first has completed the first portion.
How often do you wonder as a non testing member of a project team regarding the basis of categorizing bugs, setting their priority of fixing and their allocation to respective development guys? Logically there has to be a science behind it otherwise the exercise doesn’t make any sense. But above all whosoever takes the onus of prioritization of bugs needs to have some fundamental things in place.
First of all the test lead must have a concrete and complete knowledge of business and the business requirements – on the basis of which the project has been initiated and the product is being built. Based on the business requirements and priorities; and the kind of bugs that have been detected by the testing team; an alignment can be formed on the basis of which these bugs can be sorted out for their severity and priority. There has to be, definitely, a relationship between the severity of bug, and the priority being set for it to get fixed.
Ultimately all bugs have to be fixed by the development team. Then have you had another thought in mind, ever – why severity and priority is set for a bug, if all have to be fixed at the end of the day? Answer is simple – bugs with higher severity and priority shall go to highly expert members of the development team. And also when come back for validation – the same concept is to be applied among testing team members too.
Bug management complies of many of the activities related to bugs. It comprises of bug identification, documentation, reporting, action and closures. Once an initial set of bugs are reported to development team and they report back to testing team as fixed, the testing team needs to revalidate about the proper closure of these bugs. Validation of closure not only should be about the closure of reported bugs but also to ensure that there is no adverse impact on the application functionality and flow due to the fixing of these bugs.
So logically while validating each bug as fixed, there is a need of exhaustive amount of test cases that ensure testing as stated above. There could be cases where the bug identified and reported has been fixed and this fixing in code has put no adverse impact elsewhere. But it may happen otherwise also that the bug has been fixed and it has left an unwanted impact somewhere else in the code that now needs to be identified and fixed. There could be a third scenario where not only the reported bug has been left fixed to its fullest extent but while fixing it a new set of bugs have arisen.
Now, the most important thing: who among the team is focusing on improvising level of coding where the numbers of bugs reduce in every iteration? A special attention on taking a note on every code release is also important – if the severe bugs are getting reduced or not?
Business knowledge is equally important for two major teams working on a product – one, the development team, who has taken the burden of converting some key business processes into automation; and another, the testing team, who takes the onus of making the developed product – bug free – before it is decided to launch for production environment. A tester has in fact multiple roles while testing a product. While the development team has a big document – titled as “Business Requirements” to bank upon while development of the product; the testing team has to be more practical in terms of getting into the shoe of customer – when it comes to testing of product.
An effective testing has to look at product that has come for testing with multiple lenses. It has to ensure complete catering of business and customer needs, it has to ensure excellent usability and reaching at par with the expectations of the end users who are going to run business with the help of this newly developed product. Functionality of a product asks for a big amount of alignment with the real business environment.
An improperly or incompletely understood business requirement would lead to its equivalent development that would lead to wrong business results. Now the onus lies on testing team to find out the gap in developed product and the original business requirements. It might call for a fresh round of repetitive efforts by development team, but it is worth doing it rather than releasing an immature product in production environment.
Most of the time whenever a product has to go to testing team, the whole attention starts going into ensuring complete coverage of product, exhaustive testing, test results, test cases, test strategy, test plan and so on thereby thinking that the whole success of testing lies in adhering to all these factors and their compliance. If for once the focus is diverted to paying more attention to what enhancements need to be done while coding so that the bugs are minimized, probably it will make everybody’s life happier.
The focus on enhancement of coding process, procedures and methodology with only one thing in mind – minimal bugs – could make a big difference – in a permanent manner. Imagine that if the efforts and time in coding remains same but it is done in such a manner that there are minimal bugs in it, it saves a lot for later stages. First of all it starts building an extra level of confidence in all stakeholders the moment they realize that the same time that goes into coding, now saves a higher amount of time of the testing team as the coding has got enhancement and is now near to a bug free mode.
Another important factor is that the efforts required post coding, by testing team in finding bugs, reporting it back to the development team, and then bug fixing by development team; if now starts taking lesser time; it saves a lot of recurring efforts.
Bug Management is something that has not been standardized in a universal manner. Usually its management, reporting pattern, closure and confirmation process varies from organization to organization and there too the complete adherence to the process varies. At places you will find a very structured and elaborated bugs management system with each and every step being followed and managed aesthetically while at other places the bugs reporting itself might not be too structured.
The variance in adherence depends on many factors and culture being followed within an organization. It also depends on efforts being put for enhancement of processes, benchmark and stakeholders’ engagement. It has been found that if a same piece of code is handed over to 5 different testers for an independent testing by each, the reporting mechanism, level of testing, number of bugs etc. would vary in a very random manner. This inconsistency gives rise to a number of flaws and gaps in the process and mechanism.
The same variance would happen in case of the same team of testers is given a different set of products for the purpose of testing. The test coverage and test results would not be consistent unless and until the testing team follows a well-established process of testing that caters to some properly defined processes and procedures in order to maintain a universally acceptable testing mechanism.
It has become as well proven fact that a tester cannot become a good programmer and a programmer cannot be a good tester. It does not mean that a programmer doesn’t know how to test or he doesn’t have the capability to test the code he has written but testing his code as a tester is not possible for a programmer. There are various reasons given on the reason that why a good programmer is not a good tester in one of the earlier posts. One of the main reason is that a writer cannot be a critic of his own writing. Same goes true for a programmer. Programmer loves what he writes and himself would not love to find out fault in what he has created.
Even when there is a testing done by a programmer/ developer after writing his code, the prime thing in his mind remains that the code has been created by him and that is what holds him going into customer’s shoe and looking at the code from customer’s perspective. Whatever a programmer tests in his code is the technicality of the code. Two important things that he misses to map with his code are – one, the business flow; and two, the usability. At many instances I have discussion with developers on what they have written and what business requirement had been. And on such instances most of them argue to accept it as per the code written and express reservations in changing the code as per business requirement, by giving different reasons.
Role of testing team is to look into enhancement of the application built for a customer and making it as near to the scope and reality of business as per the expectations of the customer. If development had been free of errors or bugs, there would never have been a need for a separate dedicated testing team. Testing done by development team would have been sufficiently enough to launch the product, but it never happened. Why it does not happen is a separate story.
As already suggested in one of my previous post here, it is important for testers to follow certain set of guidelines to perform their task of testing as per the expectation of customer and other stakeholders as ultimately it is the product under scrutiny that is going to speak louder than the commitments and promises made to the customer. Because if it is not the testing team that catches the bug in the product then probably no one else before the launch of the product. And a bug encountered at a later stage when the product is launched and is catering to the business needs on a live environment, it would be too late for so many things.
A bug encountered at a later stage once the product is live, it not only hampers the reputation of product and the organization behind it, but also the future prospects of the organization. Documentation, well written processes and adherence to them, regular reviews and finally a sincere feedback plays a major role in keep moving in the right direction during a project.
Bug fixing for development team is as serious affair as a new built, or rather it must be a more serious affair. It is quite phenomenal that no product development has ever been 100% bug free. In fact importance and necessity of testing phase and testers is increasing exponentially. Again a general mistake that is done is that testing team takes it lightly after it has done first time exhaustive testing of the product once it come to them for testing after completion of development. An equal plan, set of test cases and same amount of seriousness is required to testing after bugs have been reported fixed by the development team and the product comes to them for testing of bugs.
It is good to do some iterative development- testing – bug fixing – testing here in order to perform it in a collaborative manner so as to save time and release in time. After a cycle of bug fixing has been done by the development team, the task for testing team become double fold. One – to ensure that the bugs reported have been fixed and two – there has not been a birth of new set of bugs while fixing the first set of bugs.
Reporting, documenting and reviewing is a good mechanism to manage the show during this cycle.
Test strategy, test plan, test schedule, test cases and test scenarios – everything go haywire if test schedule goes for a big deviation thereby disturbing the complete timelines of project. Definitely there should be no shortcuts taken for testing of a product thereby creating leakages that could lead to disaster at a later stage, but also important to allocate sufficient time for testing. Putting pressure on testing to finish it in time or rather before time because development plan got overshoot, is not a justifying phenomenon for product or customer.
There are many instances when testing goes for exceptions. In those cases the final test report submitted to development team must clearly state the deviations taken in the test plan along with appropriate reasons, and anticipated shortfall in coverage of testing. Someone in the Risk Management team must look at this report very carefully and find out the risks arising out of it. A proper mitigation plan needs to be chalked out depending on the risks and the severity arising out of these risks.
At times development team might have a confusion over a bug reported and/or they might not be able to simulate the same bug. Test team’s role becomes important in these cases to explain the same to development team for such reported bugs.
A comprehensive and detailed test report preparation during test phase of a newly developed product as mentioned in an earlier post here, makes a lot of sense in ensuring availability of light at the end of tunnel names as project management. Each phase of a project right since its inception is like a tunnel where at the beginning of your journey of that phase, you are never 100% confident for its timely and accurate closure. After all, projects, for years, have been a great topic of discussion and there is no company in the world that can claim this figure of 100% success in all their projects. There are always a number of hidden and visible threats to a project that could fall in the bucket of anticipated ones, or the ones emerging as a shocking surprise at any moment of time during project management.
Each test case must be given an equal amount of attention and the recording of results of test cases and test scenarios is quite important. All test cases do not result positive and same is true for vice versa. Hence it becomes important to record flaws encountered in the Bug Report in a clear and sensible manner so that least amount of time is spent by development team on understanding the bug and more time goes into fixing of bugs. At times, test team, in an attempt to show bigger count of bugs in their test report (so as to reflect higher amount of efforts gone in testing, which obviously is a misconcept) record multiple bugs for the same error thereby duplicating the reporting of bugs. A thorough inspection of Bugs Report is therefore important before handing it over to development team for fixing of bugs.
It is important to ensure completeness of testing for any new product built based on the customer’s business requirements. These business requirements become the basic source for defining development requirements and subsequently testing requirements. Testing is as important phase of any project as the development. In fact every phase of a project in project management has serious impact on any next phase of the project. Based on business requirements and subsequent logic being built in the application by development team, Test Team prepares test cases to ensure complete coverage of testing of the product. These test cases have to be extensive, exhaustive and meaningful. Test environment, test bed and testing strategy have to be strong enough to ensure meeting of customer needs as per customer’s expectations and not as per development team’s wishes.
Any changes happening in the code during or after completion of testing, which could derive out of various reasons, must ensure retesting and that too in exhaustive manner, without bothering about the change in logic is small or at a large scale. For this purpose it makes a lot of sense that development and testing go hand in hand till the product ripens to its final shape and becomes ready for deployment. Test scenarios have to be properly aligned with the exhaustive test cases built. Equally important is to observe the pass and fail result of each test case. A small gap here could cause a big trouble later.
That is why documentation and recording is necessary. It becomes handy at a later stage too for reference purposes, as and when any need arises to refer to it.
There are many ways to ensure complete coverage of software testing as discussing in my earlier post here. Let us revisit those ways and introspect a little more on the same. A careful inspection and selection of activities is a must to ensure adherence of process, procedures, policies, methodologies and completeness of testing of any new product during its built or after its built. Or it could be equally important for a newer version of an existing built that has already been released to customer(s). First and foremost is to ensure complete understanding of business/ customer requirements and then the business logic built in the product to cater to these needs. A gap in understanding of these requirements and subsequent in slippage in complete coverage of product testing could lead to a big disaster post release of the product not only in terms of money and reputation but also in terms of acquiring new business or keep holding the existing ones.
Documentation here has a bigger role in terms of – first, drafting these requirements in a crisp elaborating manner, and second, getting a sign off from responsible authority from customer. Engagement of quality team right at this stage ensure smooth closure of later stages of the project. While development team meets to discuss these requirements to draft out their development charter, plan and broad level design. The requirement document must be given as an additional copy to testing team so that they find out points of discussion for any clarity required from analysts or customer. It makes sense obviously as it is the testing team that gets into the shoe of customer to see the behavior, flow and functionality built. As a development charter and plan is built, a similar charter and plan is important for testing. Test strategy is an integral part of this. Test Methodology, test schedule and requirement of testing tools needs come out of it that define the scope of testing and building of test cases.
Based on your interest qualification and career goals, there are 8 different certifications offered by PMI. Each certification is an independent entity with no linkages or prerequisites among each other. Check them below:
Project Management Professional (PMP): A well acknowledged and widely recognized certification that is having demand globally can be a great booster for your career in Project Management. Project Managers with this certification have definitely a higher recognition and importance than the others, who don’t have it. It is an excellent opportunity for experienced project managers to acquire this certification to get a clear cut edge over their peers and get their presence felt on a global front. It also provides an altogether different horizon to master project and team management.
Program Management Professional (PgMP): A higher level of certification for the project managers falling in the category of senior project managers (or those aspiring to become senior project manager) who are currently managing multiple teams and multiple projects. Specially designed certification enables senior project management professionals to gain an in-depth insight to manage large and complex projects, in multiples.
Portfolio Management Professional (PfMP)SM: This higher level certification helps in gaining skills in portfolio management and mastery in handling multiple portfolios.
PMI Agile Certified Practitioner (PMI-ACP): This certification is meant for experienced project managers who are following agile methodologies or are at the verge of getting into it so as to manage projects with Agile approach.
PMI Risk Management Professional (PMI-RMP): This is a special certification to build competence in managing risk portfolio in project management by means of assessment, analysis mitigation and closures of risks in a project or multiple projects.
PMI Scheduling Professional (PMI-SP): This is an excellent certification for project managers who need expertise in scheduling & planning of projects.
OPM3 Professional Certification: The certification helps in aligning experience of a project manager with the practical knowledge gained during the journey of project management so as to maturely manage multiple projects.
If you are among software testing professionals, practitioners, consultants, managers, scholars, researchers, students or developers; and are around New York during 11 to 13 August 2014, don’t miss opportunity to attend the 9th Annual Conference on Software Testing, CAST 2014 with a theme of “The Art and Science of Testing”. It is being organized by Association for Software Testing (AST) since 2006. The unique feature of this conference is about its sessions where each of the sessions is run in two flavors – the first half is taken by the speaker who is master in the subject area and the other half is and open session to facilitate attendees for questions, discussions etc.
Some more unique features of CAST sessions is that it is for professional and learners in software testing field and is run by experts and masters in testing field with a sole purpose of improving and optimizing software testing and enhancing its learning to all attendees. The model of this conference is to share in an interactive manner, conduct discussions and run Q&A. It is a time when expert professionals, authors, blogger and other related personalities interact with each other.
CAST 2014 is being co-chaired by Anna Royzman and Keith Klain. The first day is set for Tutorials of full day duration to be conducted by experts in their respective areas. Next 2 days are for interactive sessions.
If you are around Dublin, and belong to software testing community, mark your calendars to attend EuroSTAR Software Testing Conference 2014 during 24th to 27th November 2014 at The Convention Centre, Dublin. The beautiful theme this year is Diversity, Innovation, Leadership. The deadline for submission of application for speakers and active workshops was till 14th February 2014. Notification of Acceptance is on 21st March 2014.
Program is chaired by Paul Gerrard. Paul is associated with EuroSTAR event since 1993 when the first event was organized for the first time in London. Here is the video in which Paul talks about the forthcoming event.
A test strategy is a must to be in place before the team starts testing on a software project. Though the template and components of a test strategy may vary from organization to organization and also from project to project within the same organization, there are certain important aspects and key elements that need to be integral part of a test strategy. The careful insertion of these key elements in your test strategy will definitely ensure higher level of optimization of your time, resources and money spent on the whole exercise.
Testing experts need to expertise in learning the strategic as well as practical approach towards software testing. Keeping a benchmark helps in improvisation in your above approaches. As a single project management methodology does not fit well for all kind of software projects, same is the case in software testing. Your test strategy, test cases and testing methodologies, test estimation and exhaustive risk management would vary depending on these factors.
A clear cut roadmap to drive your software testing is important not only for crisp functioning within the function but it also give a clear insight about the function to management and other stakeholders. For any new testing technology that you plan to introduce to your management must have a business case in place.
Software Test Professionals (STP) Conference is happening this spring during 14 to 17 April 2014 in New Orleans, LA. It is like a must attend conference for all professionals who are connected to testing phenomena, directly or indirectly, for the purpose of getting lot of insight, learning and knowledge on the subject. One of the benefit that you get while attending such a conference is to meet and talk to your peers, seniors and legends in software testing. You get to know lot about what is happening in software testing from the horse’s mouth and this way you understand the new things happening out of your own pond.
Networking done during these conferences with like minded professionals helps you in many ways so as to help you in improvising your career goals, finding out new techniques for testing your apps, discuss about latest tools, ongoing and upcoming trends in testing, existing processes and their optimization, insights in other industries and so on. There are 6 tracks finalized so far with a number of sessions in each track. So depending on the choice of your areas if is important to tick mark which tracks or sessions you would not afford to miss in case you are planning to attend this 4 days conference. The detail of tracks and sessions can be found here.
Coming years are usage of mobile technology in the corporate word – to cater to their desktop/ enterprise apps on mobile platrofrm so as to provide the versatility and freedom to use it anywhere, anytime with least amount of gadgets requirements. In today’s scenario, everyone is using a smartphone that is quite capable of running an application. Most of us are already using many of those applications already on our phones.
Enterprise apps need a little extra attention in terms of development, quality and security. If an enterprise app is required to be made available on mobile phones of the employees it becomes a complex requirement in terms of the deployment looking at the number of variants of the OSes being used in the mobile phones. Mobile application development and deployment is not as simple as a Windows platform Client-Server application or a web based application. Testing becomes a major area in mobile apps development and deployment. Take for example any legacy application running in your organization that needs to be deployed on mobile platform and it has to be available on every employee’s mobile phone irrespective of its operating system. The same enterprise application is now required to be produced in a lighter version so as to support its deployment on mobile phones.
Quality becomes apparently a big task when it comes to testing of the functioning of same app on various versions of phones using various versions of the same and different operating systems. Simply deciding on moving an enterprise app to mobile platform without building up a strong development, deployment, testing and security team within would be a problematic affair.
2014 would be a year to focus more on development and deployment of mobile applications in corporate world all across the globe. Corporate are seeking an absolute confidence in using their enterprise software apps on mobile, at least to cover the core business part. Confidence is definitely required on three major fronts before taking mobile apps to a level of enterprise business – development, quality and security. the way requirements are increasing day by day to build mobile features of the business apps that are running in the organization, it is becoming important to understand the increase in demand for mobile apps developers and testers.
Smartbear conducted a survey among 1000+ developers and testing community to find out the extent of focus on mobile apps on a global arena and came out with following results as stated in the infographic.
Click image to see a larger versionHow Well Do you Know Your HTML5? Test Your Knowledge via SmartBear
Each software built is associated with some stakeholders and audience. The higher is he number of audience, meaning the number of users, the higher is the risk. Risk goes in many variants of two main components – money and reputation. It impacts on financials, business, customers, stock price, sales, revenue and many more factors.
When it comes to a world class leader in manufacturing of vehicles, the stake and risk increases manifold. As per a news item, recently Toyota had to recall almost 2 million newly launched Prius hybrid car from the market due to a bug in the software embedded within the vehicle to perform certain functions. We all know the complete lifecycle of a software. It goes through various phases – requirements, development, deployment, launch etc. In between there are certain stages where quality has a major role to play which impart in depth testing of the product. Testing is critical in many aspects.
Prius is the latest generation of full hybrid electric car produced by Toyota for its mid sized segment customers. It was rated as one of the cleanest vehicles in the United States based on its smog forming emission technology. The latest recall that happened early this week was due to a glitch in the software because of which the gas electric system of the car was automatically getting shutdown. The recall has happened in many countries including Japan, North America, and many places in Europe. Toyota is a company that is heavily dependent on technology for their manufacturing process. Besides having highest level of quality control mechanism in Toyota manufacturing plants that is manged via Software Quality Management (SQM), they use Prince2 and CMMI to a large extent for their software applications used for the development and manufacturing processes.
This post is in continuation to my previous post on the same subject. In last post we discussed about 4 suicidal traits that could close the gates of growth for a project manager. Let us look further at the rest of 5 negative traits which the writer Abhinav Pandey has recommended to follow in his new book 9 Don’ts To Success because the DOs don’t work published by Grapevine India.
The 4 traits discussed in previous post are: Distraction, Mistakes, Fake, and Lies. Here are the rest of traits below:
5. Arrogance: An arrogant project manager will be difficult to adjust in a project. This trait might be useful to follow for an artist or a film actor who is on the peak of his career and can dictate his terms from there but not for a project manager by any means.
6. Risks: This is the only point that I agreed to the author that a project manager must follow. There again, the project manager has to be smart enough to understand the difference between a calculated risk and blind risk. He must be able to assess the risk factor in the risk being taken.
7. Negative Thinking: It will lead to nowhere if a project manager starts following this trait.
8. Flamboyance: This again would be a disastrous trait if a project manager starts following it.
9. Manipulation: Agreed! But not to full extent. This is the second trait in the whole list of 9 recommended by the author. I would say a project manager can be manipulative but has to be careful enough in playing his cards. A positive and sensible note is important in this music played (if at all!) by the project manager.
Thanks to Abhinav Pandey for compiling these 9 traits that we would be discussing below in his new book titled as 9 Don’ts To Success because the DOs don’t work published by Grapevine India. I was wondering after reading this book whether these traits recommended by the author to follow would work for a project manager in his success if he starts following them, and the answer was a big NO that came from within. Let us see why these traits would not work for a 5. project manager in making him more successful in his ventures:
1. Distraction: Would distraction from customer, customer requirements, business needs and project management help a project manager in achieving bigger goals than what he is able to achieve by focusing on these.
2. Mistakes: Which organization will accept a project manager making mistakes too often and that too repeatedly the same mistakes. Probably none. Taking risk is different from making mistakes. Having a watch from various stakeholders on the project, it is something a project manager can never afford.
3. Fake: How a project manager can act fake is not clear. The author opens this chapter with a statement that artificial flowers last longer than the real ones. But then worldwide real ones are preferred over the artificial ones. Moreover “fake” in no sense mean “artificial”.
4. Lies: No point in discussing. If a project manager starts following this trait, that would be suicidal for his career.
Part – 1/2: Next 5 traits discussed in following post…
One absolutely important role of Quality function which is not there in written in their agendas anywhere but which is always done by them is to take all stakeholders in sync and perform a consolidation of product unanimously before letting is QC cleared and okayed for release to customer. Why is it so important for them to engage all stakeholders and win their confidence is very crucial to avoid any confusions and conflicts occurring at a later stage after the product has been released.
Testing criteria must be made very clear and the exceptions highlighting is most important factor stating what is not under the scope of testing. Scope of testing has to sync well with the exact business requirements for which the product has been or is being built to cater to its needs. Getting into the shoe of end user and looking at the product functionality and usage as per his perspective is also very important factor for quality function.
Imagine a scenario when quality is sitting in isolation with no information about what projects are in pipeline at what stage and what is the plan of things coming into their kitty for testing and QC approval. Gone are the days when this used to happen. Quality has to be part of all stages of Project Management now. Right time to allow them to peak inside the door is Business Analysis stage when a team of business analysts is about to sit with the business stalwarts of customer business for finalizing the business requirements and current scenario. A quality gut at this stage if is part of the team can start absorbing the right kind of energy to drive it till the final stages.
Quality guy might have different set of questions in mind that could be raised during analysis stage. If he is not part of this stage and later gets a document of analysis and requirements from BA team, it might be a postmortem and might not simulate the queries from Q perspective that could have arisen during real scenario, provided he be the part of it. Similar kind of scenarios where QC team gets isolated (or is made to do so) is the development phase when developers are discussing, developing and performing unit testing.
A Quality person at this stage equally engaged in all kind of developmental and requirement discussions could act as a boon for the product as the absorption of crux of customer business is already settled in his mind and during final QC testing all this wisdom could become handy.
Projects do get delayed mostly as per their plans due to various reasons. But mostly the major brunt is to be absorbed by testing. Reasons for this could be many but important to learn is to cover the testing team with a shield so that none of this kind of panicking pressures penetrate and create chaos in testing phase. Some of the known factors causing pressure on testing phase are:
1. Wrong Planning: Initial planning if not reviewed on a regular basis is definitely going to cause its impact somewhere.
2. Customer Demand: At times there are factors at customer end that compel them to redefine their timelines of go-live of running project for which the pressure is put on project team. Development takes its own sweet time and so does the testing but usually pressure of such kind fall on QC to squeeze their timelines to roll out testing in a quicker manner.
3. Development: Delay in development completion could squeeze testing phase timelines thereby eating out their calendar dates planned to go for testing.
4. Unplanned Shortfall: Shortages that occur suddenly during running phases cause severe impact depending on the resources or persons that vanish all of a sudden from the scene.
5. Other Unplanned Priorities: A suitable time allocated for testing might get sacrificed for some other unplanned but critical activity that jumps into the team’s pocket.
If you feel that speed produces better results, you are wrong and carrying a misconception in mind. Speed in lack of proper direction and predefined or planned results is always a disaster. One has to be very clear what results are in demand while carrying out testing of a product. That is where a structured and planned testing comes into picture.
At times, in presence of high pressure due to multiple projects running at the same time, each with a timeline to launch, which mostly contains a number of constraints of time and resources; the pressure jumps on to the bottom line to fasten their work and deliver fast. Under pressure, a Test Lead might direct his test team members to perform the testing ‘quickly’ to meet their deadline. This might happen due to various reasons, a wrong planning, a pre-pone launch request from customer, a delay in development, a shortfall in manpower and resources than original plan, another priority eating out the allocated time and so on…
But everyone in the team especially the middle and top line must understand that putting the bottom line under extra pressure will never lead to quick and accurate results. Speed often compromises with the accuracy…
Before talking about procurement of tools to manage quality of a product whether through QC (testing during development, post development and UAT – user acceptance testing), one must thing about the human brain that is going to drive these testing and while running these tools. It becomes important to know the quality factor lying in the brain of each of the member of quality team or testing team. Quality has to come from mind and once that stage is acquired that each brain engaged in testing of a product is a quality thinker and quality doer, it is never attained with the help of market tools for generating test environment, test cases, simulation, load or stress scenarios.
A test team member has to clearly understand that unless Quality does not become a tool for mind, it has no meaning and the member himself loses his own weightage in the scenario. If there are more doubts in the mind of tester regarding product, it is evident that the product testing would not reach to a justifying stage and the testing phase is definitely leading to a bug prone product.
Quality is objective. It is measurable. It can be seen, felt and measured. Teams working on testing of a product know well how to measure the testing effort and quality imbibed in the product. A straight measure of quality in a product is the encounter of bug in the product post its release. Multiple bugs detected by multiple users in live environment is definitely a disaster for the product. A straight question raised in such cases goes on the role of quality testing team and their efforts.
Test cases, test bed, testing efforts is all what counts in the measurement of testing in efforts to produce a bug free product to go live for end user and business environment. It is very important to engage test team members right since the inception stage of a project so as to avoid any confusion at a later stage that will definitely lead to time loss which is a big factor in a project. Projects do get delayed but the intelligence required to manage a project is to ensure delays caused by unnecessary and unwanted activities.
Another very interesting question asked is as below:
When handling multiple projects simultaneously for multiple vendor portfolio, how would you address conflicts if happens between testers/test leads or any two cross-sectional QA leads due to project stress? Also, how should one manage the current critical project deadlines if you are being given an ad-hoc high priority work on top of the existing ones?
Having a scenario of managing ongoing multiple projects simultaneously for multiple vendor portfolio is not something new that is encountered by project managers. Seniority of a project managers comes along with wisdom that comes with experience. Right on day one a project manager does not know how would he handle such kind of situation when his environment and ecosystem demands for heterogeneous deliverables, for heterogeneous stakeholders with heterogeneous list of top priorities and tremendous pressure. Conflicts and clashes becomes frequent occurring events under such circumstances when all teams and team members are under time and delivery pressures. Imagine a real life matching scenario when common resources are being used by two QA leads for two different projects falling under the same project manager and different project managers.
A concrete work plan with deliverables for each project by each member with exact timelines is very important. Only hitch in this kind of condition is the unplanned absence of any critical team member.
An ad-hoc priority on top of existing ones – all with squeezed timelines of delivery is another issue. To handle this it is important that such in-bouncing priorities which are totally unplanned must come through a common route and that route is strong enough to take a call what to compromise in lieu of what. In parallel to this, what is being compromised needs to be informed to the respective stakeholders, which is the responsibility of this common route. Let this common route be Project Manager.
Quality is not a “one department” or “one person” baby in an organization. It is a mission that has to be followed by each and every person of the organization working at any level right from the office boy, pantry boy, helper, up to the top most level. Quality can not speak different languages or having different meanings in a team, project, or the organization. It is a culture. It is a definition of life within the organization.
Quality has to be built on regular basis. It is not like a building of the organization that is built and you start sitting and working inside it. It is a building of indefinite size, indefinite scope but with a clear cut, crisp, measurable and adoptable mandate. It cannot be enforced to anyone. It has to be exemplified and demonstrated by each and every brick in the wall – meaning by each and every person in the organization. Quality in a never ending journey but on a definite path and a definite target to achieve.
If above level is achieved in any organization, there can be no hurdle in its way to reach at the top.
Following was the question I was asked today by a Doctoral Candidate in Educational Technology & eLearning today.
When it comes to leading a huge QA team such as your position, how do you define ‘quality’? Why ‘quality’ matters to you?
(QA professionals are asked by the organization/customers during every project as how they would define quality. Do quality differs in each one’s perspective? Because, not everyone view in the same way. What would be your input on this?)
My answer to this question could lead to many posts. In a summary my answer would be as below that I would be elaborating further in next few posts to come:
1. Quality Is a Mandate for me without which no individual, no process, no business, no product, no project, no function and no organization can survive in today’s competitive world.
2. Quality is Objective and has to be defined in a clear cut measurable manner. It cannot be a subjective manner. It is a tool to draw out best possible positive results to meet expectations and timelines.
3. Quality is a TOOL for Human mind and not a tool to be used by a human mind. It has to be in the blood of a person to live with all the time.
4. Quality is NOT Speed to deliver a product where while delivering it compromises by any means. It has to be a balancing act between Delivery and Awareness of Completeness.
5. Quality cannot happen in Isolation. It is a team work – inter and intra both.
6. Quality is Synchronization and unanimous consolidation.
Would be taking it up further in my next posts.
The list of my top 10 blog posts on Project Management and Quality Assurance are as below:
The link for these posts is: http://itknowledgeexchange.techtarget.com/quality-assurance/
- What is a Testing environment for software testing?
- Twelve essential Steps of Software Testing Life Cycle (STLC)
- 10 Skills to make a perfect Project Manager
- Ten Differences Between Project Manager and Project Leader
- 5 essentials while building test environment for software testing
- Eight Goal Settings for Software Developers
- Eleven Skills For Product Manager To Win Over Any Situation
- Five Excellent Quotes On Quality
- Project Task Prioritization With Eisenhower Matrix
- What Is ETL Testing – An Overview
5 type of projects will be in high demand during 2014 as listed below:
1. Education: Projects based on education delivery in a smarter way will be for asking globally.
2. Retail: Systems to make retail business more comfortable, versatile and widely acceptable.
3. Security & Privacy: Demand will be high in making systems more secured while keeping privacy intact over the internet/ cloud.
4. Health: Global health management systems will be high in demand.
5. Governance: Management of public utilities, systems and facilities in an automated secured manner.
The success of a project is driven by the teams that work on it. Besides various other factors and logistics, it is always the team that matters most because static and non living things do not think and act according to changing environment and conditions but it is the human mind that has an ability to work efficiently even under stressed and constrained conditions. That is why the people factor remains on top always.
For Test Lead top 5 priorities on card for the year 2014 would be:
1. Requirements: Understanding of customer and business requirements beyond what has been documented by the analysts will be very important. It will be good if QC guy gets a chance to walk through the business process of the customer thoroughly.
2. Documentation: Documentation includes a lot and means a lot for QC. Right from test case building, test report, bug closure report and so on.
3. Experience: Testing is one expertise and business knowledge is another. Former comes from learning and education whereas latter comes from experience and wisdom. A tester needs to have both these expertise in a balanced form so as to align both the roads properly.
4. Team: Management of team, allocation of resources and retaining the best of resources is an art that needs to be learnt and managed.
5. Learning: Learning is a process that needs to be built in a structured manner. Learning must come from each project, each success, each failure and so on.
Learning keeps on adding ‘value’ ingredient in the professional life of a project manager. Project manager has to be a quick learner and grasping agent to get the crux of matter so as to adopt enhanced process of managing his projects. Every project brings in a new bouquet of learning. The shortfalls and failures bring in a determination of not repeating the same in next upcoming projects. The successes carry on with a message of maintaining the same in forthcoming projects.
Let us look at the top 5 priorities that would be on cards of a project manager during the year 2014:
1. Requirements: Focus will be there to grab business and customer requirements as crisply and elaborately as possible. Requirements and business processes do not change on daily basis once they get established and optimized. During such changes happening there would be a risk of changes in the requirements but then it has to be handled in a matured manner.
2. Documentation: Documentation has been a consistent pain for project managers at the time of project crunch and hence needs to be managed appropriately.
3. Reviews: Project progress review control mechanism need to be redefined with customer as an active participant in all review meetings where the requirements and progress is to be discussed. The process of project review has to be more transparent for the benefit of all by engaging all stakeholders.
4. Closures: Each closure has to be signed off in a structured manner so as to ensure compliance to customer needs.
5. Teams: It is not difficult to get best of the people but to retain them is. Focus on engaging your team members beyond work prepositions so as to have an emotional tie up with the organization and work.
For generations there is a fundamentally ongoing fight between the product team and the quality team of any project. This is a generic fight for which there has not been a solution found so far. The fight is as below.
Product manager and his team always think that their product is fantastically built as per customer requirement with 100% requirements business needs met while building it. And the product is bug free. They further have a mindset that the product when goes to quality for internal testing on a test bed similar to live environment, the testing team takes extra long time with an intention of overstretching the whole exercise of testing just to maintain their importance intact. According to product team 90% of the bugs are either unnecessarily listed to build the test report long with large number of bug findings or the similar kind of bugs are repeated for the same purpose.
For a successful project, the credit goes to the whole team. But for a project delayed or failed the one man in crisis is the project manager. Whatsoever the reasons may be for this delay/ failure but it is the project manager that has to bear the brunt. Let us look at the topmost reasons that cause project delay or project failure:
1. Change Management: The initial requirements from customer leads to development but as the work progresses, fresh requirements or changes in the existing requirements keep pumping in from customer end. There is no wonder about it to happen and one should take it as a natural phenomenon. After releasing their initial set of requirements, customer think tank keeps pondering over what else could be achieved which lead to these requirements. Critical part is to grab these requirements with a positive note, analyze well and segregate these requirements to two parts – to be added, or to be reverted back to customer with a justification for not adding it.
2. Commitment: For business critical apps development there is a deep rooted commitment required from each section, from each of the stakeholder. If that does not happen, there are chances of missing some important handling in time that could lead to a big disaster if raised at a later stage. It has been seen that if customer key users are not engaged well in time initially during the development phase for clearing off units built have higher risk of facing major setbacks in progress of project.
It is very interesting to note that there is a group of project managers who do not stay in an organization for long. They set a rule not to stay longer than 2 years or so. Or maybe the rule gets imposed on them automatically due to their own pitfalls to enable them to keep surviving in the ecosystem. Let us look at what makes it happen in case of such project managers. The main factors could be their
These guys are not fundamentally strong in their project management skills. They appear to be confident and strong get goers in their talks but not in their walk. They talk high about their past achievements which probably they have never achieved in reality. They are good in ensuring management about their capability in handling any kind of tight situations and tough projects but in actual they have their plans of exit at right moment well in advance.
They will not be able to run projects well and that will apparently start appearing after a short while. They would spend their intelligence not in learning business, processes and procedures; but on how smartly to shift cap to one or the other instead of owning it. Logically at the point of insertion in the beginning itself should raise eyebrows of the management for such candidates who have appeared for candidature with a track record of spending not significant time in their previous organizations.
Keep pace with the Technology: The way technologies are changing at a very fast pace, it will be foolish to stay with your legacy technology running for years whereas the world is adopting newer technologies for the similar kind of projects. There is no doubt that when the existing technology was selected, it would have been a state of the art and latest of the technologies kind of solution. But remember that over a period of time, technologies get faded away in wake of newer, robust and advanced technology entrants.
Remember that development for all business apps start with a prerequisite set of requirements basis which timelines and plans are built and team sizing, resources etc. are set. Once this business requirement is converted to an app, it is released on Test Server, Staging Server and Live Server respectively for QC, UAT and go-live in the same pattern. Gradually when this app is handed over to end users on go-live environment, the app usage starts triggering along with the desired business results chickening out.
But story does not end here. New requirements that either go to changes in existing functionalities or new functionality built keep pouring in there by reshaping the size and environment of your existing app. That is where your awareness towards newer technologies to manage and control any kind of crunch in the existing one, is very critical.
Methodology & Approach: Every project does not fall in a generic project methodology. It is important to understand the type of project before making it enlisted under a particular project methodology. For this, based on the projects undertaken and new upcoming ones, relevant project methodologies to be identified and defined. Right project methodology helps project manager and other teams to ensure following right processes and documentations for each project phase in that methodology. A new project marked in wrong methodology could lead to extreme level of confusion and thus leading to failures.
Issue Management: Issues are integral part of any project arising during any of the phases of a project. Taking issues in a lighter way could lead to losing the right direction of a project and hence getting it derailed from its progress track. A single issue management charter with process driven approach with right & understandable definition of issue, its categorization, its severity and its closure with identification of ‘who’ is responsible for closure of issue, is very important. Any issue, howsoever small, could lead to a big disaster. A regular review is a must.
Communications: Be it project management, team management or issues management; nothing will move in right direction, if inappropriate or incomplete or missing communications happen during a project. Project manager must ensure to graduate each of the team members and team leads on how to handle communications and its importance. Right kind of information, to right people, at right time with right kind of actions required must be a set protocol of communications. For example, if a piece of information is just for the sake of information, or an action is required, along with its criticality, should be the right approach to manage.
Project Management mainly comprises of converting customer requirements and business needs to an application so as to enable customer in running its business in a much smoother and error free environment. It needs to be imbibed of business processes, workflow (if required by customer) and minimization of manual interventions to a maximum extent. Any business process that speaks about business enhancement, improvisation and optimization by transforming it from manual to automation enabled through coding needs to be thrown into a dustbin.
Timelines of a project are mostly defined as per customer guidelines. At times it is important for a customer to get a solution within a stipulated time frame if the app is related to a pre-scheduled launch in a big way and the app is going to play a major role in that particular launch. Usually a project where customer has no say in desired results’ release timelines especially when it is a customer sponsored project, it is definitely a major glitch. Either the requirements are not serious or customer has no intentions to pay for the product later.
CTTR is Customer Time To Release which means the timelines defined by the customer regarding release of product. All project timelines, budgeting and allocations are a total derivative of CTTR.
Budget for any project is allocated right at its initiation phase. Budgeting includes lot of factors but the main factor remains customer defined timelines. Keeping this target defined by customer in mind, a backward calculation is done and accordingly time allocation to each phase is done, team sizing is defined and resource planning is done. After all it is customer that matters the most.
Well, it does not mean that there is a scope of comparison even if this backward calculation is being done. Two prime factors that play a major role in this whole game is quality and finances. Budgeting beyond optimum level and compromising with quality of the product will mar the beauty of product and impact on business badly. When timelines are shorter there is another way of pulling your socks and not letting you beaten down. It requires higher level of skilled task force, error free tools and rich experience to win over in such kind of wars.
If you really want to be a successful project manager you need to acquire following three powerful weapons so as to be a winner all the time whether the conditions are favorable or you are travelling in rough seas. The teams that are formed usually have all mixes of human beings having different styles of working and delivering results in different fashions. Overall momentum is something which need to be maintained all the time to race along the ticking clock. The three important and potent weapons that can help you are as below:
Skills: You need to have high quality project management skills to win your battle. If you are leading a team of unbeatable and brave soldiers but lacking the same in you, would not lead you to a winning situation.
Tools: Whether it is project management tools, bug tracking tools or incident recording tools – you need to assess your needs and acquire these tools accordingly. Overstuffing yourself beyond required commodities will lead to a burden on your head. But vice versa also holds equally good meaning if you are underestimating your needs and go for the battle along with your team with shortage of armory, your defeat is sealed right in the beginning.
Experience: Guys with rich experience under their belt and laurels shining on their shirts are always moral boosters in the teams. Hence it is important to have such guys, at least one in each team to keep overall tempo at high pitch all the time.
It happens at times when you have a mission critical project with tight timelines from customer that increases its stake manifold, for which you place best of your teams comprising of high skills and experience, and on top of it you provide state of the art tools to tackle all kind of situations; and still the timelines are not met and things go out of control. It is always important to go for a deep analysis for such kind of failures to such an extent that the shortfalls are identified with their core reasons; and are sidelined once for all, for all forthcoming similar kind of projects.
It is well said that disciplined approach and hard work pay well in comparison to merely hard work. Well defined processes and procedures play a major role in this. If these are in place, it makes your tasks easier in managing and guiding your teams. Since there is no differentiation among teams and the standard procedures apply to everyone, irrespective of who and what, the same procedures need to be followed.
Growing these skills is as important for immature teams, as is for matured teams to keep nurturing and excelling in these.
PMP is a good source in two aspects. One, it gives you a great insight on how to manage your projects in a more efficient and risk free manner. Second, if you appear for its exam and qualify, you get a universally accepted accreditation that is highly appreciated worldwide. PMP (Project Management Professional ®) offered globally by PMI is a boundary free certification. During your learning towards PMP you learn a lot about project management something that you have never learnt before or come across during any other kind of learning towards project management.
Four takeaways that you can be assured of during your learning of PMP can be listed as below:
1. It provides you a well-organized and highly structured method of managing your projects and related activities. The inbuilt flexibility enables you to design your project management methodologies as per your company’s requirements.
2. You get empowered and leveraged to take full control of your project(s) and mitigate risks anticipated in advance (or those come in the way in an unannounced manner). Your learning gets enhanced to enable you to plan, execute, monitor, control and steer your projects in a professionally organized manner without getting drifted away from best practices being followed across the globe, similar to your industry.
3. You get an enormous amount of knowledge on understanding gravity of documentation required for your kind of projects running in your organization. It helps you in planning and controlling scope, teams, financials, schedules/ timelines, quality, risks and closures in a way so as to assist you in achieving higher level of success in any kind of projects undertaken.
4. You get well equipped with the tools and techniques to monitor the timelines of your project in a proactive manner with an advanced way of getting you informed about any contingencies prone to occur during project lifecycle.
Capturing business requirement is a cumbersome process in many aspects. For some it might become difficult to capture concrete requirements if business is not process oriented and documentation centric. In such conditions there would be as many statements misaligned with each other as many mouths. Each member engaged even in a similar or same process might talk differently regarding the same process which could lead to a big confusion. In such conditions everybody would be eager to speak but nobody to vet the stated requirement.
In certain other conditions, systems in place could be too cumbersome that your timelines for closure of requirements capturing would definitely get shattered. Here, in this case, you would be running after the process owner, who would be rich in process knowledge and practical experience, but he would not be able to give you substantial time to help you in capturing requirements in multiple runs.
Requirement capturing goes useless if there are some ambiguities or misalignment that stops it for sign off. It is important to opinion from everyone who is part of a process in the organization and then a proper alignment needs to be done, if required, by involving top management into it.
Customer requirements never get finalized in one go. It takes multiple meetings and discussions to understand, draft and finalize so that it gets signed off and final nod to move ahead. The discussions that are held in this regard are primarily of four types. As listed below, these four types generally go in the same order but there are instances when in between one type get intermingled with another type. It also happens that during same discussion more than one type of discussion takes place.
One needs to be smart enough to differentiate between the type of discussion and thereby understanding the gravity of matter and level of documentation required to be performed. First type of discussion is General Discussion. Normally all initial discussion would be of this nature. This could also be treated as ice breaking as two different teams from different agencies are sitting across for a serious matter for the first time. This type of discussion would not be very crisp and conclusive.
Second kind of discussion is Scenario based discussion. The team expert in processes and procedures would showcase all possible scenarios so as to provide the other team an insight of the business requirements. Here – documentation needs to be very detailed and accurate so as to capture and understand business scenarios.
Third type of discussion would be Data Details. For a better understanding of scenarios discussed in other meetings, it is further explained with the help of actual business data or sample data simulated so as to build respective scenario.
Fourth kind of discussion would be Process Details where the business process is explained in detail. Important point is to study business process, data details and scenarios so as to find out and get resolved, if any ambiguity or misalignment occurs among the three.
I recently met with a test team with an excellent performance record. For all the applications where it had given a green have a track record of zero major bug encounter post its launch and 100% customer satisfaction with timely sign off. Definitely the credit goes to this test lead and his team. It was a point of curiosity at my end to know what was their process and methodology to give such a tremendous performance.
Their logic was very clear and crisp. The team lead had made a rule that during all customer requirements capturing by business analysis team – one QC member will be part of the team. Customer requirement finalization doc once signed by customer would be shared with testing team. The testing team, on getting customer requirements documents, would immediately start building test cases where on the other hand, requirements have reached to development team for preparing development plan, testing plan and release date.
While the development team is busy with meeting with their timelines, test team members had a clear cut charter of brainstorming and finalization of test cases built on the basis of customer requirements purely.