Monday Aug 17, 2009
Wednesday Aug 12, 2009
By John Morrison on Aug 12, 2009
Monday Oct 08, 2007
By John Morrison on Oct 08, 2007
Without much ado, lets dive right in.
The Test Architect (TA) role is a senior position in the organization and is treated on par with equivalent Management positions in terms of rewards, recognition, visibility and influence. However, one basic factor that distinguishes a TA from a Manager is the absence of direct-responsibility for managing people. While Management tends to have people management as a core feature of the job, the TA does not directly manage people. However, this in no way lets the TA off the hook, so to speak, from influencing, mentoring, coaching and providing direction to members of the Testing Organization - all very important responsibilities of the TA.
The Test Architect -
- provides Technical Leadership and Strategic Direction to the Testing Organization (TO)
- is responsible for Test Strategy formulation
- helps Formulate & Develop effective Test Architecture per organizational needs
- is Technically responsible for all the Testing performed by the TO
- is the foremost Technical Authority and is responsible for the overall Quality of deliverables across all parameters, both functional and non-functional including performance, security, usability, etc.
- is expected to pro-actively analyze current processes and practices and suggest/ drive improvements. Also, defines processes as needed
- has wide-reaching scope, impact and influence extending beyond the confines of the TO and spans across the entire product organization
- is the counter part to the development architect
- is involved in driving organization-wide Quality Process initiatives and their implementation to ensure Quality of deliverables
- maintains a “big and complete” picture view of the product, its dependencies, organizational goals, technology arena, etc. and helps guide & direct the functioning of the TO appropriately
- influences the product organization's future direction, strategy and planning
- collaborates effectively & on an on-going basis with all constituents involved in product development & release activity including development, testing, technical publications, marketing, program management and other entities to ensure execution & deliverables per plan
- is involved in customer engagements and provides customer facing organizations with necessary technical product support in making presentations, demos, pocs, etc. Also, receives and analyzes existing customer feedback to identify gaps as well as work with deployment / sustaining organizations as needed. Customer engagement activity also spans alpha / beta trial opportunities and acts as a liaison with customers and partners while ensuring Test strategy is aligned appropriately
- helps with Test plan development
- is responsible for design & development of the TO's Test Automation framework / harness and any in-house tools required. Where tools do not fully meet requirements of the TO, the TA writes code / develops components that can extend available tools or even design & develop tools as needed
- is involved in understanding Business requirements and works with the development architect to translate requirements into solution architecture designs. Reviews requirements and seeks clarity as required, participates in product design reviews and works with the development architect and development team to make any design improvements and refinement as needed. Also helps incorporate Testability requirements into design
- Analyzes competitive products and technologies and makes appropriate suggestions (may use demos, pocs) to influence product / technology direction
- has overall product knowledge and is able to guide both junior and senior team members
- influences Technical direction and use of technologies after making necessary evaluations
- involved in hiring activities for the TO and mentoring of TO team members
- pro-actively seeks to make continuous improvements to Test coverage, execution and automation
- is results oriented and has a high degree of accountability, commitment and responsibility. The expectation is that involving a TA in a project is a guarantee of obtaining positive outcomes
- participates in test planning for all products handled by the TO and owns the test artifacts such as test specs, code, etc.
- Growth upwards from a TA level is towards a more senior role with wider scope of activity & influence across the organization. Needless to state the obvious, there is considerable enhancement in responsibilities and charter as progress is made upwards on the growth path
- Extensive Technical skills covering Product, Technologies and Competitive knowledge. Sound knowledge of domain / areas being handled is essential. Its not sufficient to be a specialist in any one area or technology and requires a wide and fairly deep understanding of a gamut of technologies and tools
- Knowledge of current industry wide Quality & Test processes and practices, Tools and techniques
- Ability to work with teams. This point cannot be emphasized enough since at this level, the last thing that would be acceptable is silo behavior or merely trying to be an individual star performer. Being able to get the team to perform at an outstanding level is absolutely essential here. The “ability to influence” despite not having direct reporting relationships is very key. In this position, a high EQ is as much a necessity as a high IQ. The ability to collaborate and co-operate is important
- Excellent communication skills – within and outside of the TO, across teams, with customers – both horizontally and vertically, is important. Effective negotiation skills are very important too.
- Another facet that is extremely important is an excellent working relationship with the Manager. No i don't say this because i'm viewed as being on the Management side ! The fact is to be a successful TA, requires working in tandem and close co-operation with Management, keeping Management abreast and updated of developments, seeking and providing inputs and feedback, regular reporting, etc. is very important. This attribute cannot be stressed enough
- Ability to focus and prioritize is important. Understanding the distinction between the urgent and the important and effectively prioritizing tasks is key
- Needs to focus on the explicit & implicit customer / user needs
- Self-management is a key attribute expected of a TA. Being able to work without the need for follow-up or “too much” management is important. The TA should be self-motivated and a self-starter. No, this does not absolve the Manager of the responsibilities of managing the TA as needed !, but a TA should require very little following up to get things done. The expectation is when a TA is assigned to a product, project or specific area, positive & agreed upon results are guaranteed almost always
- Ability to motivate self and others is important. Also, vital is being able to set a good example for the other members of the TO to follow
- Ability to set goals is also key. In many instances, the TA will need to define and set goals including stretch-goals as appropriate
- Patience and a touch of humility is valuable, especially in all dealings with team members. This is especially true when trying to mentor or guide other team members, the ability to articulate in ways that are understood by the listener at their level is necessary while also possessing good listening skills. The humility to acknowledge need for continuous learning and to undertake a program of learning to constantly update skills and keep abreast of current developments in the industry is vital
- Ability to strategize and look ahead and at the big picture
- A great deal of maturity, accountability, high degree of integrity, highest levels of pro-active behavior, ability to take initiative and professional behavior is naturally expected of a TA
- Sound Project Management abilities is important
- Software Analysis & Design knowledge/experience is needed while also having a solid background in Software Quality & Testing. Must have hands-on experience having performed both functional and non-functional testing and be able to review requirements, design and even code as needed
Signing-off this post with a short quote, "Successful people don't do great things, they only do small things in a great way."
Monday Sep 03, 2007
By John Morrison on Sep 03, 2007
We look at a list of methodologies used in the process of designing test cases. The obvious questions that folks new to / not too familiar with testing tend to ask is ... why Test Case Design and why all of these methodologies ?
The answer to the why is based on a fundamental premise of Software Testing i.e. "Complete" or "100%" testing is not possible.
Yep, sounds a little negative to the uninitiated, but thats the fact. The derivative of the above statement implies that "all" Testing is incomplete, although the degree of incompleteness varies. In reality, testing is performed within various limitations and boundaries defined by variables such as resources, time, cost, etc.
Given these constraints, Testers need to come up with a set of Test Cases that has the highest probability of unearthing the greatest number of defects. This is where Test Case Design plays a significant role.
In this post, we'll keep things short and only take a really quick, very high-level view of the methodologies. These cover both Black and White box techniques. Here they are ...
1) Equivalence Partitioning
2) Boundary Value Analysis (BVA)
3) Cause-Effect Graph / Decision Table
4) Error Guessing
5) Statement Coverage
6) Decision Coverage
7) Condition Coverage
8) Combination of Decision & Condition Coverage
9) Multiple Condition Coverage
We'll look at some of the above in upcoming posts. For now, if you are really keen to deep dive, Googling might be a good idea or better still grab a book on Software Testing and let the concepts soak in. One other thing since we are on this subject of Test Case Design ... while it sure is important to test to check if the program does what its supposed to do, its also very important to test to check if the program does what its not supposed to be doing ...
| Slashdot It! | Submit to del.icio.us