written by: Christie Marsh on March 10th, 2014
At one point or another as a business analyst the time comes where you wonder whether you should get the CBAP® Certification. The certification comes with no professional guarantees. It does not guarantee a level of superiority or a job. The main goal of the certification is personal development and development within the profession of business analysis.
When making this decision, the person that knows best is often you. As a business analyst, you have already developed talents and skills perfect for your career. On a daily basis you combine communication with analysis and take this into the business world. Often you must have the technical knowledge and interaction skills where other people don’t have both. This is why you will realize that whether or not you move up the corporate ladder, you will be a business analyst for life. You will use these skills you have developed in any position, and you know how valuable they are.
Even business analysts don’t completely understand business analysis. There is always more to learn. Taking the CBAP® forces you to expand your knowledge of business analysis and discover the bigger picture of what business analysts do. Not only do you become more aware of business analysis as a whole, but this can also be applied to your own role. The certification shows your fellow business analysts as well as employers that you are a well-rounded professional in your field and that you understand the standards of your position.
Because business analysis can mean so many different things, it is a difficult career to explain. It is important for business analysts to collaborate on this idea and develop an identity. When you become a Certified Business Analysis Professional, you are increasing the awareness of this position and identifying yourself as a business analysis professional.
written by: Kaete Piccirilli on March 6th, 2014
The Software Testing Plan is made up of the Test Strategy (the what, why, when & how) and the Test Logistics. We will go through the Test Strategy document and how you can develop a good one for your Software Testing Process. The Test Strategy Document defines the main goals that need to be achieved and what is needed to be measured to implement the goals. A clearly stated plan determines the scale of the project and allows everyone on the team to incorporate all the activities related to the software testing process.
The first part of developing a good test strategy is Scope and Overview. This step is to determine who should approve, review and use this document as well as define the phases of the project as parallel to the timelines as specified in the test plan.
The second part of developing a good test strategy is Testing Approach. Areas to consider in the approach is distribution of responsibilities among team members and determining who will be the test owners, when to start the testing, the approach and the tools you will use.
The third part of developing a good test strategy is Testing Environment. This means requirements on how to create test data and the backup and restore strategy to ensure that you don’t lose any data when problems are found in the software code.
The fourth part of developing a good test strategy is the Testing Tool. This is where it is stated what testing tools will be used. Always take a look at whether the tool is commercial or an open source tool. An example of a testing tool might be Ranorex.
The fifth part of developing a good test strategy is Release Control. For successful testing execution, make sure the software release management plan has been planned appropriately. It’s important to build a management process to know when a new build should be made available and deployed.
The sixth part of developing a good test strategy is Risk Analysis. Do a review of the project and jot down all the possible related risks to the project. Then build a plan to avoid the risks, as well as a contingency plan should the realization of the risks occur.
Click to continue »
written by: Rob Snowden on March 4th, 2014
I’ve worked at several organizations that had a Project Management Office. Although I see value in what a PMO can provide, one issue I’ve had with them is that often the people in them seem to be permanently in the PMO, and often, no one can remember when some of them have ever been on a project except for the PMO involvement in the project.
I think of my Dad telling me about his experience of being a flight instructor in the Navy. Instructors rotated in and out of squadrons so that instructors had recent experience and credibility with the newer pilots they were mentoring. No one stayed an instructor – it was a temporary assignment like many assignments in the military.
Likewise, the PMO should be staffed by people who rotate in and out of projects, having credibility with the teams they assist, with real world experience in the reality of using the templates and techniques that the PMO espouse. Staffing PMOs with permanently entrenched staff members limits their credibility and their ability to guide people actually in the trenches.
written by: Traci Taylor on February 27th, 2014
The most crucial role in IT today is that of the Business Analyst. Being on the leading edge of technology there are countless opportunities available to business analysts. Business analysts are liaisons between the business community and technical solution providers and ensure that business requirements are addressed before technical solutions are designed and implemented so that the final solution meets business objectives and adds to the bottom line. Requirements are the core of developing IT solutions and it’s up to the business analyst to define, analyze and document requirements in order to show exactly what a system does to meet those business objectives and how it adds to the bottom line.
There are several key roles in defining and managing requirements; core skills a business analyst needs in order to advance to their full potential. The first is the ability to extract requirements. Incomplete or improper requirements lead to project failure. Therefore, the business analyst must be able to determine project’s requirements by extracting them from business policies, current and future users, interaction and research.
The business analyst must also be able to anticipate requirements. Things change very quickly in the IT world and baseline plans are always subject to change. So the business analyst must be able to anticipate requirements needed in the future in order for a successful outcome.
Sometimes it is necessary to constrain requirements. Requirements should focus on core business needs, not users’ personal preferences, outdated processes or nonessential modifications.
They must also be able to organize and translate requirements. Requirements can emanate from various and sometimes conflicting sources and the business analyst must be able to organize them into categories so they can be managed and communicated effectively. The business analyst must also have the ability to use modeling and analysis tools for matching strategic objectives to practical technical solutions.
Click to continue »
written by: Traci Taylor on February 24th, 2014
Agile training from ASPE can help people of all levels gain a competitive advantage through Agile Software Development.
Newly Agile quality assurance and management teams face a number of barriers to overcoming the traditional mind-sets and practices of non-Agile teams. Before deploying Agile practices, there are some frames of mind that need to be totally forgotten.
- Testing Teams Can Only Be Effective if They’re Independent
Testing teams usually prefer to report directly to senior project managers in order to report and escalate technical defects without the potential inhibitions of a technical lead. However, testers are essential to an Agile team with a focus on a quality, shippable product at the end of each sprint.
- You Cannot Manage Testing Without a Separate Test Strategy and Test Plan
Test approach can be documented in release plan and sprint-specific testing activities during spring planning. Although a test plan may not be required, it could be beneficial to have a test strategy at a level higher than the project.
- V-model for Verification and Validation is Not Applicable in an Agile Sprint
When Agile practices are adopted, verification and validation are automatically addressed. For instance:
- Verifying whether INVEST criteria for documenting requirements is followed
- Reviewing visual modeling
- Holding daily stand-up meetings
- Reviewing radiator boards
- Following continuous integration
- Holding focused reviews
Click to continue »
written by: Tom McGraw on February 19th, 2014
ASPE does not endorse or train on any specific tool in our publicly offered, open-enrollment Agile courses. As is the case for many of our other training topics, we take the agnostic approach, teaching you the skills versus knowledge of a tool.
For example, in many of our Agile courses, you will write user stories, utilize Agile planning, determine story points, dependencies, and more, all with pen and paper, flipcharts, index cards, etc. Because we do not use a specific software tool in the classroom, what you learn will be applicable to any Agile environment. The skills we teach to effectively implement Agile could in turn be applied to whichever software product your team/organization chooses to use to manage their Agile projects.
written by: Tom McGraw on February 17th, 2014
Increasingly, we have seen individuals increase their marketability significantly by attaining certifications in several areas. Commonly, an individual could have a variety of certifications such as PMP, CBAP or ACP, which all require continuing education.
For the three certifications above, PMP, CBAP, and ACP, the individual needs to accumulate 60, 60 and 30 contact hours every three years, respectively. Here are some pieces of advice for this group of multi-certified professionals:
- The most important piece of advice I can provide to this group is to consider professional development opportunities that can satisfy multiple recertification requirements. It is becoming more common that SDLC courses are approved to offer contact hours to a variety of governing bodies. As you can imagine in a world of overlapping roles and professionals wearing ‘many hats’, there could be great benefit for a Project Manager attending Business Analyst class, or a Business Analyst attending a Project Management class. PMI and IIBA, the governing bodies of PMP, ACP, and CBAP also recognize this by awarding contact hours to classes that are not directly tied to their bodies of knowledge. Examples of courses that carry contact hours for all three include Certified Scrum Master Workshop, Collaborating and Communicating Agile Requirements, Hands-On User Stories Authoring and Elaboration and Business Analysis in Agile Projects.
- In addition, there is a misconception that all (or at least the majority of contact hours) must be received by paying for them – this is absolutely not the case. Other avenues to receive free or low cost contact hours include free professional development web seminars, local PMI/IIBA chapter events, volunteering at your local chapter, and even claiming hours you work on the job as a project manager!
- There have been many, many times over my years working for ASPE, where we have had an individual contact us still needing ALL of their contact hours for a recertification date coming up very soon. In almost every instance, our staff of Training Advisors will work with you to develop a plan to receive them in time for recertification. With that said, waiting to the last possible second will result in shortchanging yourself the more valuable professional growth you could have received over the three year period. Proper planning could help you align your own deficiencies with the most appropriate class, putting you at a much better place with your certification, and possibly even more importantly, the skills to help you move ahead at your job.